<aside> ℹ️ This is meant to be a blueprint. Although it was conceived in the context of an early-stage startup, a small team with no prior testing in place and existing, production-ready code, it can definitely be applied to instances other than this. Simply adjust to your specific situation.

</aside>

General decisions

  1. Start with (narrow) **Integration¹** and Acceptance Testing at first.
    1. We’ll use real databases, preferably in-memory, as docker containers (via supabase start or GH Action service containers) or via SQLite.
      1. We can read the SQL files from the /supabase folder to create the database exactly as expected, whether as part of the service container creation or with JS test setups.
        • Suggested tools
      2. If not possible, we’ll connect to the develop database (not optimal because it would fail if migrations were needed until branching is supported in Supabase free projects)
    2. We’ll mock all the external APIs, simulating their returns (will require Contract Testing in the future).
      • Suggested tools
    3. (Acceptance) We’ll simulate the HTTP calls to our server with various inputs, only checking the expected output fulfills expectations
      • Suggested tools
  2. Additionally we’ll add Unit Testing, which will test Domain and Application layers only.
    1. Infrastructure, by definition, requires external services and is usually not worth unit testing due to excessive mocking for all its Domain and Application dependencies. We’d rather test with as close-to-real situations and data as possible.
      1. We could, at best, test what the resulting DTOs, SQL queries and calls produced by our code are, as well as how it handles different inputs, but not the response those DTOs and calls would elicit from the external dependencies (without mocking them). Therefore this may simply not be worth focusing on.
  3. We’ll also add other forms of testing in the future:
    1. **Contract Testing²** to ensure correctness of our Integration Tests.
      • Suggested tools
    2. Load testing can be performed on a staging environment to test robustness and scalability
      • Suggested tools
  4. We’ll use the vocabulary stipulated by Martin Fowler in TestDouble³.
  5. No metrics chosen for the time being.
  6. We’ll follow a “Given, When, Then”⁴ (AKA “Arrange, Act, Assert”) structure for our tests.
  7. We may consider following Behaviour-Driven Development⁵ (BDD) - providing testable expected behaviours in the task itself whenever possible.
    1. Gherkin syntax⁶ seems like the obvious choice for this, but more research is required.

A great example of how we’ll approach this is in Netflix’s Blog:

Ready for changes with Hexagonal Architecture

References