At Hubba, our business needs are always evolving and the development speed needs to catch up with it. One of the ways to keep the team moving forward without breaking everything is End-to-end Testing (E2E).
Having a full test suite with E2E tests allows us to move quickly. It allows developers to push code without the worry of breaking things.It enables releases with extra confidence.And, it catches errors that are missed with manual regression.
What is E2E Testing?
End-to-end testing is where you test your whole application performance from start to finish. It involves assuring that all the integrated pieces of an application function and work together as expected.
End-to-end tests simulate real user scenarios, essentially testing how a real user would use the application.
An example for Hubba’s case would be an E2E test case for a user sign up.
The test would involve:
Opening Hubba in a browser and searching for certain elements
Then performing a set of clicks and keyboard types
Then ensuring that a user is successfully created
Why Should You Care?
At Hubba, we strongly believe in test automation. We currently write unit tests, and integration tests for our code.
These tests are used to:
specify our system
prevent bugs and regression
for continuous integration
Furthermore, these tests run as frequently as possible to provide feedback and to ensure that our system remains clean.
The motivation for an additional layer of E2E tests lies in the benefits of having a fully automated test suite. These benefits include increasing developer velocity, as well as those previously mentioned.
E2E tests allow us to cover sections of the application that unit tests and integration tests don’t cover. This is because unit tests and integration tests only take a small piece of the application and assess that piece in isolation.
Even if these pieces work well by themselves, you don’t necessarily know if they’ll work together as a whole. Thus, having a suite of end-to-end tests on top of unit and integration tests allows us to test our entire application.
The faster code fails, the less bugs we find in QA, the faster our QA cycles are –Edward Robinson