Integration Testing: Devs and QAs

In the previous articles, we breached the border between integration and unit tests, which introduces a tricky question: how to effectively organize collaboration between devs and QAs. Here is my take on that:

1. [DEV] Create Controller Method
2. [DEV] Create <CONTROLLER_NAME>TestsBase<T> class
3. [DEV] Create Waf<CONTROLLER_NAME>Tests: ControllerTestsBase<T>
4. [DEV] Implement the controller method
5. [DEV] Implement a test in <CONTROLLER_NAME>TestsBase<T>
6. [DEV] Submit a merge request
7. [DEV] Merge the request and move Jira issue to "ready for testing"
8. [CI/CD] Automatically run WAF tests
9. [QA] Create Http<CONTROLLER_NAME>Tests: <CONTROLLER_NAME>TestsBase<T>
10. [QA] Add missing configs to make the test work in both classes
11. [QA] Submit a merge request
12. [DEV or/and QA] Merge the request
13. [CI/CD] Automatically deploy to the test env
14. [CI/CD] Automatically run http tests
15. [QA] Do manual testing if needed
16. [QA] Resolve Jira issue

As you can see on the BPMN diagram, developers are responsible for the implementation and web-application-factory-based (WAF) tests, while QAs are responsible for testing: both automated using real HTTP calls to real environments. For me, this approach makes more sense than any other one, and that’s why:

• The flow encourages test-driven development. WAF tests are great substitutes for traditional unit tests: they are fast, isolated from external dependencies, and still provide code coverage statistics.
• The flow encourages collaboration, teamwork, and shared code ownership between developers and QAs. This is very in the spirit of DevOps.
• The flow favors the black-box approach over the white-box approach. White-box tests tend to be more fragile because they don’t respect encapsulation.
• All team members do things that they can do best: developers have more experience with coding than QAs. It’s not arrogance or something, they just do coding on a regular basis. QAs in turn, are more concerned about test datasets and scenarios. Most likely, the QA team will be happy to get some help with coding so they can focus on quality.

A note about test data

Preparing and cleaning up the test data might be tedious, error-prone, and time-consuming. Property-based testing technique introduces another approach that focuses on fixing system properties, rather than input/output combinations. Sometimes this approach is worth considering.

Consider the following code:

[Fact]
public async Task LoadMany_GetById_CanFetchAllProductsFromGetAll()
{
  var res = await ControllerClient
    .SendAsync(c => c.Get())
    .LoadMany(
      p => ControllerClient.SendAsync(c => c.Get(p.Id)),
      p => p.Id);

   res.Should().AllSatisfy(x =>
   {
     x.Value.Details.Should().NotBeNull();
     x.Value.Details?.Id.Should().Be(x.Key);
   });
}   

It checks that every id returned from GET /products can be provided as a parameter to GET /products/{id} and that /products/{id} returns the expected product data. No data setup is needed, albeit two endpoints are checked with great coverage %.