How to avoid API tests duplicating Unit tests

Question

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?

Answer 1

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.

Answer 2

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.