Finding the Right Balance between End to End and Unit Tests

Any application should be associated with test suites to validate its functionality, stability, security, and performance. There are many types of tests, each covers specific aspects of the application. And so, when you are testing your app, you should make sure that you have a good balance of various tests. But people often favour some sort of tests over others, and they overuse it. Usually, this type of testing is end-to-end testing.

End-to-end testing is a practice where you simulate what a real user scenario looks like from start to finish, tests all layers of the application at once. It is best suited to make sure buttons, forms, links, changes, and generally entire workflows function without problems. End-to-end includes testing the communication between components such as the database, network, APIs, etc., and executing your code in a diversity of browsers. But if you overuse end-to-end testing, you are Inverting the Testing Pyramid, planning to cover most cases with end-to-end tests, or even worse, use only the end-to-end test is the biggest mistake you could ever do in software testing. end-to-end is often the most brittle and takes the longest time in test case development and in test execution.

Testing Strategy

As a result, you need to set your test strategy. One way of doing this is to use the Testing Pyramid. Whether you are starting a new software development project or working on an existing one, quality experts recommend having a test strategy in place.

So, you want to start to put in tests for your project. but do not know where to start? This is where a Test Strategy comes in. In this strategy, it is preferable to employ the Testing Pyramid to help you define and categorize different testing levels.

A testing pyramid is where you group software tests into buckets of different granularity. It also gives an idea of how many tests we should have in each of these groups.

J.B. Rainsberger Once said a metaphor in an interview which I like how it applies to testing:

“You can throw paint against the wall and eventually you might get most of the wall, but until you go up to the wall with a brush, you’ll never get the corners.”

This metaphor illustrates perfectly how choosing the right testing strategy is the same as choosing a brush for painting a wall. Would you use a fine-point brush for the entire wall? Of course not. That would take too long, and the result would probably not look very even or appealing. Would you use a roller brush to paint and rehabilitating everything in a historic ceiling that has Inscriptions painted long ago? Impossible. There are various brushes for different use cases and the same thing applies to tests.

Selecting Proper Test Level Live Example

End-to-end testing tests all layers of the application simultaneously; it is best suited to make sure the entire workflows function as expected & operate in harmony including buttons, forms, links, added features, changes. Unit testing validates code blocks: variable A is the input; variable B should be the output. Unit testing efficiently validates on the business logic including the functions or calculations that provide resulting data—a numerical value, a string text, etc.

Now let us give an example to show you how you can put the test pyramid concept into practice and select the proper test level for a specific requirement, suppose we have a checkout feature, that could be tested using various test cases.

End-To-End will perfectly fit for testing the core functionality and the entire workflow:

• Customer making a successful purchase.
• Customer making a failed purchase and an error is displayed.

But off-course those tests are not enough to guarantee to cover all the possible scenarios and data variations, so suppose we have further business possibilities under the hood that could be tested using low-level tests as Unit Tests:

• The customer’s delivery address is not the same as the billing address.
• The customer wants to pay using a card.
• The customer wants to pay using cash on delivery.
• The customer’s card was declined.
• The customer’s card has expired.
• The customer did not enter mandatory fields in the address form.
• The customer did not enter mandatory fields in the card information form.

And the list goes on. And yes, there will be duplicate test coverage to some extent, and again this is a trade-off, but it is important to cover all user flows to make sure that everything will behave correctly.

Conclusion

Creating tests is crucial for any application. If you follow a solid test strategy that includes the right balance between various tests, then your tests will improve your application’s overall quality and will also be fairly easy to write and maintain. You should only use end-to-end tests, like any other tests, but in the ways, they are meant to be employed. They are created to replicate real user scenarios. But in the end, remember that most bugs should be caught as close to the root as possible.