Types of testing

Jan 5, 2014 testing

Test driven development has benefits:

  • Moves us towards having a comprehensive set of tests
  • Drives testable design
  • By creating more testable code we're indirectly creating more maintainable code
  • Eliminates fear of regression and fear of change and encourages change and rewrites towards a clean and testable architecture

The whole purpose of testing is to gain Confidence around your system. Ensuring there are tests give you the confidence that
you haven't broken anything and gives you the assurance to fall back on.

How do you know when you've got the right level of testing?

It's all to do with confidence. If you can go to sleep at night knowing you have provided enough coverage then you are at the right level.
If you have a banking application or service, you will have more testing, all the edge cases covered.
If it's a small ecommerce website, at a startup, it's likely you'll have less time to dedicate to super thorough testing, but enough to ensure decent quality, with edge cases left to be discovered and improved upon with fast-follow improvements.

There are a variety of tests:

Some are based on what they are testing:

  1. Unit tests
  2. Integration tests
  3. Component tests
  4. Service tests
  5. UI tests

Some are based on why they are being tested

  1. Functional tests
  2. Acceptance tests
  3. Smoke tests
  4. Exploratory tests

Others are based on how they are tested

  1. Automated tests

  2. Semi-automated tests

  3. Manual tests

  4. The testing pyramid

![/2024/test-automation-pyramid.png "Test Automation Pyramid"]

Ideally you want end-to-end tests that run within a few seconds but that isn't possible with todays hardware and the complex use case, edge cases and spin up time of modern stacks. Execution time will always increase when we add more test cases too.

The balance comes between unit tests which are immediate feedback, then service tests which combine those units together, then UI tests (and acceptance) tests driven from the front-end or API levels.

An acceptance test verfies the functionality of the system overall. They're often written in business language such as Given, When, Then. They contain the criteria for completelness. They're doing as manual or coded UI tests but are very brittle and are often a sticking point.

Instead of running against a full stack when doing acceptance testing you can bring this closer to the application. Instead of driving from the UI or handlers, you talk directly to the services (that handle the commands and queries) and mock out the edges (databases and third party services).

![/2024/before-after-test-architecture.drawio.png]

Sources