Test scopes
- Unit test - an isolated test around a single 'unit' of code, although that can be anything from a method to a class to a series of (related) classes.
- Component test - same as a unit test
- Isolated test - a test that doesn't do any I/O, i.e. the Ports have been filled with in-memory Adapters
- Integration test - a test that interacts with deployed instances of the code and related services, possiby with some Test Doubles (mocked/faked/stubbed etc).
- End to End test - a test that entirely interacts with deployed instances using public interfaces
- Test-per-class - a convention that there should be one unit test for each class
Uses of tests
- Development test - a test that was created to aid the process of development (not necessarily TDD)
- Acceptance test - a test that demonstrates an acceptance criteria is fulfilled.
- Regression test - a test that ensures existing features are working. Actually all acceptance tests
- Smoke test - run after releasem, verifies a major feature is working, typically an end to end test
Descriptive styles
- Behavioural test (BDD terminology)
- a test that is described in terms of a terms of desired behavior of the unit
- not to be confused with Mockist tests
- typically human (product owner/qa) readable
- should not become obsolete when an implementation is altered (although may require refactoring)
- Classicaly described test
- Requirement is expressed using the developers own words and understanding of the requirements
- Descriptive method names are often used
- often meaning of code is expressed using code constructs
- refactoring of codebase can cloud the meaning (e.g. a method name may be renamed to match the code inside it more closely, loosing the original expression of the requirement)
Development processes
- Spike & stabilise - where code is developed and tests written after the fact
- TDD - a development process where tests are written before writing code0
- BDD - a development process where behavioural tests are written before writing code, ideally with input from PO/QA
- ATDD (acceptance test driven development) - a bit like BDD, where agreed acceptance criteria, typically written using Gherkin (Given, When, Then) are used to drive the implementation
- Gherkin - a syntax for writing human readable tests (Given, When, Then).
Properties of tests
- Fast tests - tests that don't use disk/network calls, or do so sparingly
- Slow tests - tests that talk to disk/network/browser and so run slowly
- Coupled tests
- tests that are bound to a particular implementation of a feature
- often break or become obsolete when a feature is refactored
- Expendable test (AKA throwaway)
- a test which is not tied to an acceptance criteria
- often related to the particular way that the code has been implemented
- can be deleted if it the implementation is refactored or changed so it is no longer relevant
- Poorly describerd test - in which it isn't clear what the test is doing or why
Verification approaches
- Interaction based test (AKA Mockist test)
- in which a test functions by verifying execution of methods of the components involved
- some places call them behavioural tests, but shouldn't
- often tightly coupled to implementation
- State based test (AKA Stateist, classicist)
- in which a test functions by verifying values that are set as the result of a test
Test code constructs
- Test double - a component used in a unit test which acts in stead of a real component e.g.
- Stub. A custom implementation which returns canned responses
- Mock. An object with programmable responses and can have its responses recorded
- Fake. lightweight implementation of the component. e.g. a repo that uses a hashtable under the hood
- Cake - something you deserve for reading this far.