Tests that validate business value are tests that add business value
Looks familiar? No, I’m not referring to the last time you bought DIY furniture, assembled it following instructions in the manual, and it didn’t turn out as you had “quite” expected it to. How about any similar experience when it comes to software?
The ways we develop, test and ship software keep evolving but the importance of testing cannot be understated. With the scale of software and speed of delivering software nowadays, automated tests are indispensable. There are many automated testing methods such as unit tests, component tests, integration tests, API tests, end-to-end (E2E) tests, and browser automation. Irrespective of which method you use one thing is clear: if we don’t validate that the software we deliver integrates properly to deliver the intended business value, just like in the GIF we end up with a software product that is useless to the end user. This is why it’s important to write tests that validate business value.
In this article, I will elaborate on the value of writing integration tests for you and your team from the point of view of backend development. Your team or project may not need to limit yourselves to integration testing if your team has dedicated automation engineers, you work on a matured product, or your team has enough lead time or team capacity to write unit tests.
Integration tests for smaller teams and newer projects
Often in early-stage teams and projects I worked on the need for automated tests arose after some level of project maturity had been achieved and the need for stability started to take more significance. A common question that came up in such contexts was what type of tests do we start writing? As I mentioned earlier, there are several automated test methods. It could even be overwhelming to decide which methods you should choose, do you start writing all tests at once or do you start off with one method and work your way towards others, using these methods how do you ensure you achieve the goals and objectives of writing automated tests in the first place?
The test pyramid (simplified in the diagram above) is a good representation that helps teams with make these decisions. You could approach writing tests from the top-down or bottom-up. However, I believe integration tests (or service tests) can be a good starting point. It serves as a good middle ground between extremes like unit tests and browser automation (for web applications), and in cases where writing unit tests is perceived as time-consuming. In smaller teams, there may not be enough capacity to dedicate to writing extensive unit tests for every component or fully end-to-end tests with browser automation. In such situations, starting with integration tests can be pragmatic.
Integration tests and Quick(er) ROI
When you begin with integration tests, you get immediate results and confidence that your software works as expected when parts of it integrate together because the value of writing integration tests is more tangible. That in turn also helps motivate you and your team to write more integration tests and even adopt other methods of automated tests over time.
Don’t get me wrong, unit tests are great! Unit tests are essential for validating the building blocks of code, ensuring that individual components work as expected. I will write a separate article on Unit tests and Test-driven development (TDD) in future. However, in my opinion, unit tests really shine when they are used with TDD and used to drive the software design, rather than validate working features. They might not always directly translate into tangible business value, whether it’s business value for customers of your software product, or the software development entity you work in and the effort you and your team put into writing unit tests.
On the other hand, integration tests validate vertical slices or even entire features of software. This means they are much closer to the business value we deliver and help ensure that the software functions as a cohesive whole. Consider an e-commerce website, where you might write unit tests to validate that a function correctly calculates the total cost of items in a cart. With integration tests, you can go a step further and ensure that the total cost of items in a cart gets updated properly as users add and remove items from the cart, or that when placing orders, the system integrates properly with an external payment gateway to register a transaction and capture successful payment. This holistic validation is what businesses care about.
Therefore, integration tests offer a quicker return on investment (ROI) on writing tests. This kind of pragmatic decision-making that makes effective use of limited capacity can make or break startups or early-stage projects.
Adapting to changing requirements
In projects where requirements and design are highly likely to change writing unit tests can be challenging as the codebase undergoes frequent changes. Your team can get bogged down in writing unit tests that may quickly become outdated. Every change in the codebase could make your team rewrite several unit tests, causing a maintenance nightmare.
Integration tests are better suited for this scenario. They encapsulate broader functionality and are less sensitive to implementation details and your code structure. When requirements change, you can adjust your integration tests accordingly, ensuring that the core functionality remains intact. This adaptability helps your team to keep adding tests to cover more feature slices while maintaining focus on delivering business value, even in the face of shifting project requirements.
Real-world Assurance with Test Fixtures
Integration tests, especially when combined with test fixtures, bring us closer to simulating how our software works in a deployed environment or in production. Test fixtures provide a controlled environment for running integration tests, including setting up databases, server configurations, and external services to mimic the system in a deployed environment. This real-world simulation is invaluable because it helps identify issues that might not be apparent in unit tests using mocks and spies. Integration tests can catch gaps and issues in data interactions, network dependencies, and overall system behaviour. This level of assurance gives you and your team greater confidence that the features will work as expected when they are integrated with those other components and deployed to production.
Bonus point: if your codebase doesn’t have Dependency Injection or Inversion of Control (IoC), you might find it hard to write unit tests since you do not have an IoC container to inject mock dependencies or stubs into unit tests. In such cases, you could start off by introducing Dependency injection and test fixtures from boundary layers of your backend service in your integration tests. Over time, as you introduce Dependency injection into inner layers of the codebase (e.g. service layer, repository layer, etc.) you can introduce unit tests.
Conclusion
To summarize, integration tests play a crucial role in validating the business value of your software. It provides a quick return on investment in writing automated tests by focusing on vertical slices or entire features, making it an ideal choice for smaller teams, newer projects, and situations where requirements are subject to rapid and drastic changes. When combined with test fixtures, they offer a level of assurance that brings your software closer to real-world scenarios, ensuring that your software works as expected when it integrates with other parts of the system and delivers the intended business value. So, the next time you consider writing automated tests, especially in backend services, consider integration tests. Write integration tests to validate business value so your tests add business value to your team, project and software product!
If you enjoyed this article, please follow me on Medium for future blog posts and follow me on Twitter at https://twitter.com/@ihanblogstech for other content that I share and comment on.
