Skip to content

Instantly share code, notes, and snippets.

@mcintyre321
Last active September 24, 2020 15:03
Show Gist options
  • Save mcintyre321/08b086153f17471b08ba to your computer and use it in GitHub Desktop.
Save mcintyre321/08b086153f17471b08ba to your computer and use it in GitHub Desktop.
Testing glossary

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

Development methodologies

  • 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).
  • inside-out tests - where you start tests anywhere, often testing internal types and classes
  • outside-in tests - where you only test via the public interface of the system under test

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment