TestFoodPyramid

Last edit July 7, 2008

AutomatedTesting helps a software project by connecting user needs to code abilities. ExecutableSpecifications come in several forms, corresponding to aspects of the project lifecycle. The foundation of all testing is the DeveloperTest, commonly called the UnitTest. Most tests in a project should be written via TestDrivenDevelopment, as developers add code abilities.

Developers put these abilities together with FunctionalTests, merge a program end-to-end with IntegrationTests, and prevent old problems from coming back with RegressionTesting.

At the higher levels, a team should write AcceptanceTests and CustomerTests, using a FrameworkForIntegratedTesting. They should use a DomainSpecificLanguage to represent requirements as a kind of LiterateProgramming. These tests match features that user populations expect.

At the highest level, tests represent the program's quality to the marketplace. LoadTesting, MutationTesting, and SoftwareMetrics exploit the project's test batch to rate its health and lay odds on its success.

Each line of code gets constraints from a stack of testage, up to the peak.

"SezWho?" - Matthew Heusser

Hmmm... The text above suggestes that DeveloperTesting is UnitTesting. But then goes on to say that Developers also do FunctionalTests and IntegrationTests -- so DeveloperTesting is NOT limited to UnitTesting. -- Jeff Grigg

The failure of a "Unit level test" implicates only one unit. You only need to search one unit to find the bug. That's a QA concept; Developers doing TestDrivenDevelopment don't care which unit failed, so long as most of their tests truly are unit-level, and so long as they can also search their most recent edit. Or revert it!

So...

All those definitions freely overlap. A given test could be a member of almost all of them.
CategoryTesting