1

How to deal with the overlap between unit tests for API endpoints (presumably written by the developers) and automated API tests (written by testers)?

The authorship of the tests is of secondary importance.

What I want to achieve is not to have duplicate tests. For example, if a dev writes a batch of unit tests for the new endpoint, there is no need for testers to write the same tests in another framework.

One of the strategies that come to mind is to allow testers access to unit test code so they see what was already been covered by tests. And for the other cases, testers should write new test cases or return the ticket back to the dev until all relevant test cases have been covered.

What are the other things to keep in mind?

1
  • could you add example of an overlapping use case ? unit and API are two different things , how are you having the same test scope for both these levels ?
    – PDHide
    Jul 7 at 20:11
5

The tests serve different purposes. Overlap is good.

The 'overlap' of higher order tests (such as API) and Unit tests should be high. In fact 100% would be good.

Unit tests mock and stub all dependencies. API tests do not. API tests may involve calling many units via the initial call. A unit test should test only one unit. Unit tests are involved in TDD as the code is being written. API tests are often at a higher functional level, part of BDD tests, etc.

The same is true for UI tests btw. One high level test that goes through multiple screens may call several API's which in turn call hundreds of individual units of code, each of which has unit tests. This add to us calling it a pyramid.

Another fun challenge for tests is that as they grow... you need tests for them. The tests that is. For example, finding orphan or duplicate page object identifiers, created as part of testing, is part of testing the tests.

to allow testers access to unit test code so they see what was already been covered by tests. And for the other cases, testers should write new test cases or return the ticket back to the dev until all relevant test cases have been covered.

Indeed tests are documentation. They help communicate both high level functionality (API, integration, UI tests) and low level implementation (unit tests) so they can help both groups. Devs can check the actual functionality being desired (or changed and also not broken). Testers can dig into bugs and edge cases and know why they are happening (and find more). The oft stated independence of the two groups can be handy and indeed a different mindset is very helpful but I've also found more communication is also a good approach. Both (independence and communication) are possible when both groups specialize in the value they add.

As for the 'real world' balance. As usual, that depends. one thousand users or 100 million? 1 developer or 15 ? Budget of $10,000 or budget of $$60,000,000, timespan of this week or next year, criticality of Mars Mission vs automatic birdfeeder program, etc.

4
  • p.s. API tests can actually have stubs for testing them without dependencies but that's more detail than I want to go into here. Jul 1 at 23:47
  • p.p.s UI tests can also remove dependencies with proxy servers, fake servers, etc. Jul 2 at 10:51
  • Thanks. I get that some overlap should be a good thing. But doesn't a 100% overlap mean we are testing the same thing twice?
    – Mate Mrše
    Jul 2 at 12:06
  • @MateMrše it may help if you define 'thing'. It's not as easy as it seems :) The same block of code? The same functionality? In any construction you test components and then you test them when combined together. Software is nice in that you can actually test as quite higher levels, unlike bridges say. tacoma-narrows not withstanding of course. Unit tests test internal functionality given fixed inputs. Integrated tests look to see how different parts work with each other when inputs and conditions are less predictable. Jul 2 at 21:56
1

Unless doing BDD, you'll find the Devs write unit tests and QA to writes functional tests as a typical test pyramid pattern.

A unit test will basically feed inputs to your different functions. "Can I send mock data through this method without it blowing up?" This is done in frameworks like xUnit and gives you "code coverage" reports.

A functional test is when you call those methods (indirectly) through the API layer (or even a web/mobile layer on top of that). "Will I get the expected Output by giving the system some input(s)". This is done with tools like PostMan or Selenium.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.