This is a beginner’s guide to getting started with end-to-end (E2E) testing. It is intended to be read as a high level overview of best practices, as there are already plenty of great and detailed tutorials on various frameworks “out there” on the Internet. This guide uses Cypress as the example testing framework (just because it’s the one I use the most), but the same methodology as described here can be applied using any framework.
End-to-end (E2E) testing is a powerful tool for automated quality assurance. Ideally you want to be able to catch potential errors and bugs already on the unit testing level, but doing so can sometimes be both time-consuming and difficult. Unit testing also relies heavily on mocking out dependencies by nature, so we cannot necessarily guarantee the same behaviour as in our live application. E2E tests are on the other hand often very straightforward to set up and write, and enables us to construct very realistic testing scenarios.
In this post I will describe a number of best practices I find useful to keep in mind when writing tests. It is intended to act as a complement to my previous post, A successful testing strategy.
Code coverage “100% code coverage tells you nothing, but less than 100% code coverage tells you something.” – Unknown
Aiming for covering 100% of your code with tests is probably not realistic and perhaps not very useful neither.
Today we will a closer look at the classic testing pyramid and see how we can transform that into a concrete strategy for how to write your tests. While the terminology I use is not exactly the same as the one used by Mike Cohn when he first described the testing pyramid in his book Succeeding with Agile, the core concepts remain the same – a strong foundation of unit tests, complemented with a sufficient number of component tests (which are similar to Cohn’s service tests) and sprinkled with a few end-to-end tests (which are called UI tests by Cohn) as a last line of defense.
In this post I am going to give you an overview of different approaches to use when unit testing your backend code and database calls.
Background In my current project, we have a backend written in Go and a PostgreSQL database. We have for a long time been writing unit tests for the backend to be able to guarantee that the code is working as intended. In order to not have to rely on a database connection and be dependent on the state of the data in that database, we chose to mock away all database calls using a tool called go-sqlmock in the unit tests.