The development team I am currently in have been working to improve the test coverage across all projects.
This will ensure that we can be more confident that our new features haven’t broken old ones. But, sometimes this happens anyway. So with tests in place, if things are broken we get fast feedback in order to fix the issue and make sure it doesn’t happen again.
We use different types of tests across the projects, according to the following:
- What we are trying to test
- Who is intended to be able to interpret these results
What are Integration Tests?
Integration tests check small sections of your product and it’s interaction with external tools or systems e.g. databases or external APIs.
These types of tests are written for the integration testing level of your product.
What are Acceptance Tests?
Acceptance tests give feedback to the state of a system in from a user’s perspective.
Depending on the scope of the test, this will determine the amount of feedback you get regarding the state of your system.
Acceptance tests can be written for the integration or system/end-to-end testing level of your product.
What’s The Difference Between These Two Tests?
The biggest difference between integration and acceptance tests are the language used to write the tests.
Acceptance tests are very business focused meaning that the name of the test and it’s result should be very easy to understand, even by someone that’s not part of the development team.
These tests ensure that more of the team can help monitor the quality levels of the product and that it keeps improving. Or, when things break, they can read the results and understand where the issue lies or at least which team might be able to resolve the issue.
Where Should Acceptance Tests Go?
Acceptance tests wrap around the functionality being tested. This makes the results easier to interpret and able to be used at whatever level your team wishes. It all depends on who you want to be able to read the results. You may want the integration level to be written with acceptance tests so that product owners can ensure that their acceptance criteria for each feature is being met. As this level, it will also highlight if the development is on track because these tests are at a lower level than tests in the UAT level (the level that stakeholders are usually invited to view the product). This gives the product owner an early insight into the progress of the team and the features development.
However, putting these tests at the integration level doesn’t mean that you can’t put them also within the UAT level covering your UI tests. They may take longer to write as they need to be more readable than your usual method name of [UnitOfWork]_[Scenario]_[ExpectedBehaviour], but in the long run, it’ll be more beneficial to you and your team.
For more information, you can read this blog post by Jonas Bandi.
