Test scopes

 - Unit test - an isolated test around a single unit via it's public interface (often a class, or a series of related classes)
 - Component test - a test that verifies multiple units of source code are working 
 - 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 mocked items
 - End to End test - a test that entirely interacts with deployed instances
 
Uses of tests

 - Development test - a test that was created to aid the process of development (not necessarily TDD)
 - Acceptance test - a test that needs to pass in order to determine a new feature is complete
 - Regression test - a test that ensures existing features are working
 - 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)
-  Non-behavioural test
   - a test where is it not clear to a reader what the test is doing in terms of the systems feature set
   - often meaning of code is expressed using code constructs
   - often refactoring of codebase will cloud the meaning


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

- 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 part of the acceptance/regression pack, typically a development test
  - can be deleted if it becomes hard to maintain or slow
- 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.