Section 18.1. Principles of Test Design


18.1. Principles of Test Design

In this chapter, we draw on three main principles of test design.

  1. Tests are for communicating ideas.

  2. Tests will change along with the business and the needs for the software.

  3. Tests are automated to quickly show when we're done and to avoid errors from being introduced and going unnoticed.

Because a test is for communicating ideas, it needs to

  • Express business rules clearly, in the language of the businessperson

  • Be to the point and to avoid unnecessary detail

  • Be organized well, both internally and in relation to other tests

  • Focus on (part of) a single business rule

  • Evolve as understanding of that business rule evolves

  • Help evolution of such understanding

A set of tests needs to be comprehensive.

Because a test will change as the business and the software requirements change, it needs to

  • Avoid overcommitment to details that are not essential to the specific business rule

  • Be expressed in a nonredundant manner so that it's easier to change while keeping it consistent with related tests

  • Focus on only one business issue, so that it is less vulnerable to change

Because a test is automated, it

  • Needs to be independent of other tests, so that it can be run as a part of a test suite, in any order

  • Needs to be self-sufficient, so that it can be run by itself

  • Cannot sometimes pass and sometimes fail, depending on data or timing or other aspects outside the control of the test

See [MSA03] for a good introduction to test automation in the context of agile software development.

In the following sections, we discuss various approaches to the design of Fit tests. We also discuss various poor test designs, called smells, and what we can do about them. The idea of smells as a sign of trouble is a wonderful metaphor coined by Massimo Arnoldi and made popular by Martin Fowler et al. in [Fow99]. Smells are "indications that there is trouble that can be solved by refactoring" [Fow99, p. 75]. For our purposes, a refactoring of a Fit test or table is a change to the contents or structure of that table to improve the expressiveness or some other characteristic of that test.

As we see throughout this chapter, some smells are major and need to be dealt with as soon as possible. Other smells are minor and are simply an indication that something may need to be reconsidered.



    Fit for Developing Software. Framework for Integrated Tests
    Fit for Developing Software: Framework for Integrated Tests
    ISBN: 0321269349
    EAN: 2147483647
    Year: 2005
    Pages: 331

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net