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 FunctionalTest
s, merge a program end-to-end with IntegrationTest
s, and prevent old problems from coming back with RegressionTesting
At the higher levels, a team should write AcceptanceTest
s and CustomerTest
s, using a FrameworkForIntegratedTest
ing. 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
, 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.
?" - Matthew Heusser
The text above suggestes that DeveloperTest
ing is UnitTest
But then goes on to say that Developers also do FunctionalTest
s and IntegrationTest
limited to UnitTest
-- 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!
All those definitions freely overlap. A given test could be a member of almost all of them.