1. Testing
    1. Unit Test
    2. Integration Test
    3. Contract Test
    4. End-to-End Test
    5. Load Test
    6. Snapshot Test
    7. Reference

Testing

Unit Test

The purpose of unit test is to validate that each unit of the software code performs as expected. A unit may be an individual function, method, procedure, module, or object. Unit testing is done during the development of an application by the developers. If proper unit testing is done in early development, then it saves time and money in the maintenance phase.

Unit Test

Integration Test

Integration tests determine if independently developed units of software work correctly when they are connected to each other. It was performed by activating many modules and running higher level tests against all of them to ensure they operated together.

Integration Test

Contract Test

One of the most common cases of using a test double is when you are communicating with an external service. Typically, such services are being maintained by a different team, they may be subject to slow, and unreliable networks, and maybe unreliable themselves. The test double is indeed not an accurate representation of the external service, e.g. what happens if the external service changes its contract?

Contract Test

A contract change may break a production application, triggering an emergency fix and an urgent conversation with the supplier team. A good way to deal with this is to continue to run your own tests against the double, but in addition to periodically run a separate set of contract tests. These check that all the calls against your test doubles return the same results as a call to the external service would. A failure in any of these contract tests implies you need to update your test doubles, and probably your code to take into account the service contract change.

End-to-End Test

E2E tests are smoke test with a very limited range of paths tested that validates entire software from starting to the end along with its integration with external services.

Load Test

Load Test is a non-functional software test in which the performance of software application is tested under a specific expected load. It determines how the software application behaves while being accessed by multiple users simultaneously. The goal of Load Testing is to improve performance bottlenecks and to ensure stability and smooth functioning of software application before deployment.

Snapshot Test

Snapshot tests ensure your serializable output (e.g. React tree) does not change unexpectedly. On test runs, we will compare the output with the previous snapshot, the test will fail if they do not match: either the change is unexpected, or the snapshot needs to be updated because of the new version of the code.

Snapshots identify unexpected interface changes within your application – whether that interface is an API response, UI, logs, or error messages.

  • False positive/false negative result in CI: The snapshot should be committed alongside code changes, so CI will run the test with update to date snapshots, and it should be reviewed as part of your code review process. It can also provide a lot of additional context during code review in which reviewers can study your changes better.
  • Snapshots take a lot of time to review: We should ensure our snapshots are readable by keeping them focused, short.
  • Snapshot tests fail unexpectedly: Tests should be deterministic, running the same tests multiple times on a component that has not changed should produce the same results every time.
  • Meaning of each snapshot: Give descriptive names for each snapshot. This makes it easier for reviewers to verify the snapshots during the code review.
  • Lot of unit tests: The aim of snapshot testing is not to replace existing unit tests, but in some scenarios, snapshot testing can potentially remove the need for unit testing for a particular set of functionalities (e.g. rendering of React components).

Reference