http://assertxpath.rubyforge.org/test_food_pyramid.png

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 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, 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 DeveloperTest''''''ing is UnitTest''''''ing.
But then goes on to say that Developers also do FunctionalTest''''''s and IntegrationTest''''''s --
so DeveloperTesting is '''''NOT''''' limited to UnitTest''''''ing.
-- 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...

* DeveloperTest - tests not written by customers
* UnitTest - (casually) tests addressing units
* IntegrationTest - written by developers, usually within the UnitTest rig
* AcceptanceTest - apparently typically written in a DomainSpecificLanguage, such as a BehaviorDrivenDevelopment system
* CustomerTest - criteria written by the CustomerTeam

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