What type of test is that?

Tests help you ensure your code works, but they come in several shapes and sizes. Here are the four key ones I use, and how to spot the difference.

Unit tests

AKA: TDD, fast tests, “tests” Usually written by: Developers Time to run one: few ms Time to run suite: few secs - 3m Component under test: one or more related classes/types usually in the same module. Success: You have hundreds of quick running tests that cover 80% of application code. Tests are not tied to the implementation and each breakage only fails one test Common Indicators of problems: tests are slow or brittle and developers ignore test results

Integration tests

AKA: Mufti component or multi system tests, database tests, tests with a stub, system tests, Usually written by: Developers Time to run one: no more than a few seconds Time to run suite: 1-5m Success: The interaction between each component in the system has a handful of reliable integration tests that only cover the interaction between them. Common Indicators of problems: Tests rely on data that is not setup by the framework. Tests are brittle. Tests require special manual intervention or are hard to run. Lots of server config on system under test before they can be run

Smoke tests

AKA: Post deployment tests, “is it up” test, status page, health check Usually written by: Developers, Deployers, Operations Time to run one: up to 2 seconds Time to run suite: 1-20 seconds Success: Running automatically after deployment a handful of tests quickly validate the deployment succeeded and all the components are up and running. Common Indicators of problems: They take ages or something failed during deployment without a corresponding test failure.

Acceptance tests

AKA: BDD tests, Automation tests, End to end tests, Selenium/Webdriver/UI tests, subcutaneous tests, Gherkin tests, cucumber tests, Regression tests, Business value tests Usually written by; Developers, testers, analysts and end users often in collaboration with others Time to run one: a few seconds Time to run suite: usually too long. Ideally less than 20 minutes Success: Each key feature of the application has a non code based test description that can be run as an automated test. The test validates business value and when all tests pass you are certain no regression has been introduced. Common Indicators of problems: The tests are considered slow and take hours lowering their usefulness. Sometimes they break for no reason and people talk about deleting them all or starting again.