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.