I spotted this great question by @philippa in the wild and thought it was worthy to post here:
How do you decide what to include in acceptance tests where unit tests have been written against the code that forms the APIs? Should we reduce acceptance tests if part of the API is covered in the unit tests? Iām of the mindset we should not duplicate tests between the 2 layers
How do you think about this testing challenge?
Isnāt acceptance testing something users do? To see if the software solves their problem sufficiently. If they accept the software.
While unit tests typically done by developers to have some safety at that level.
In my 15 years as tester I have never done acceptance tests.
Maybe I have a very different definition of acceptance tests compared to Philippa?
By and large I can go with what the Wikipedia and the ISTQB are stating about this: Acceptance testing - Wikipedia
ā¦ testing with respect to user needs, requirements, and business processes conducted to determine whether a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether to accept the system.
@philippa What is your definition and how does comes that you do that while you also somehow have to care for unit tests?
@sebastian_solidwork Im fascinated to know ā¦ if you have never done acceptance testing, what sort of testing do you do? The definition you have quoted there surely is one major part of what needs to be tested - does it meet the acceptance criteria? does it meet the requirement? does it meet the users need? does it actually work as expected?
Coming back to my question though: This stemmed from something that was said to me the other day. I was stating that when testing an API, I would want to know what unit tests had been carried out so that I could then decide on how much testing was really needed at my layer of testing (thinking test pyramid layers). Someone then said to me that they didnt feel it mattered how much test coverage there was in unit test layer cos that is just testing the code, but the acceptance testing (his term for testing the API) would need to cover all the same things cos it was a different type of testing.
My question is therefore really to find out more about how people decide what is duplication and what is unique when deciding on the test coverage for the API test layer over the Unit test layer.
One important part of the quote to me is:
āā¦to enable the user, customers or other authorized entity to determine whether to accept the system.ā
I also test the product to meet acceptance criteria and requirements.
But mostly to find problems and to inform others (developers and product managers) about the state of the product (and to decide on the further development). I find out the actual quality and by that to help to improve it.
I also try to empathize with the user as good as I can.
But finally Iām not the users. Iām not the one who signed a contract with my company (or be one of the authorized entities).
Only this people can say to which degree they find our product sufficient.
I test to inform about and (by that maybe) improve the quality of the product.
I do not test to accept a product.
At least not most times of my job.
I do acceptance testing when I evaluate a new product for usage.
Maybe our situations are very different from each other.
What you wrote in the quote is my daily business, but I do not call it acceptance testing.
For who are you testing that they maybe accept a product?
The unit layer is nearly on the lowest level of a product and looks at components very isolated (I intentionally did not used āclassā or āmethodā as even some unit tests can cover multiple classes or methods).
On a unit layer you can not say if there are problems if you combine multiple components. Its effect is very local.
On API level (and higher) you can find out more about how the systems behaves as whole. Most/all parts put together.
Also I know the unit layer to most times work on in an IDE or an Continuous Integration server. Right next to the written code.
Without a dedicated test environment (include the lack of a real database). No installer etc.
Experiences might vary here, I seldom found much duplication between unit and API layer.
Honestly speaking I seldom see the unit automation. That is developer stuff I do not care much for (I trust my actual ones to be good here).
And I still find a lot of bugs.
Complexity is beast.
Further questions?
As I say ā¦ this was not my terminology. And in actual fact my focus within my role is very different from this conversation, but it was just something i was interested in given it was something that was said to me.
The discussion that took place was all about how an API tester would know how much testing of the API was enough vs too much or too little. I suggested you would want to take the amount of unit testing into account ā¦ the rest of it is as per my last message and was something that was said to me cos the other person believed that it didnt matter how much unit testing was done, as you still needed to completely cover the whole API in what he termed as āacceptance testingā, but what I would term as API and Integration testing.
Iām very sorry. 
The first paragraph of your previous comment caught my attention and I then read the rest veeeeeeeery briefly.
Maybe my second lengthy answer told it already to you:
I would give as similar answer. Just altered in some details.
I would not say āneed to cover all the same thingsā. āsame thingsā might be right by something code coverage.
But by testing on API layer you can test some things (more easily) which are hard to do on unit layer.
e.g. combining multiple calls and get a reasonable final result. By API you can test/check processes.
APIs are not just good for testing the API itself, but also for testing the whole system BY the API.
I hope this is more helpful. 
Some experiences of āacceptance testāā¦
Big telephone/cellphone systems in the 90ās being responsible for one subsystem among 10ās of others being delivered to customer like 1 yr after our deliverance - System test on the level above doing their stuff, sending us bugs, none whatsoever knowledge of what they did
Developing new products that is maybe to be sold to a customer in the future - Getting hold of a market guy and forcing him or her to watch a demo.
Nice projects with a customer (quite few during 30 ys) - setting up an acceptance test system, writing scripts and urging the customer representative to do happy test. Quite seldom on API level, almost always E2E with the customer using the customer interface.
So, when it comes to what do we test outside of unit tests it really depends on a couple factors, technique used in unit testing, what the API does, and whatās the risk/impact to the user.
There is testing the function of a thing and testing the behavior of a thing. And that depends on how the test is built. If a Unit test is utilizing a lot of Mocks to simulate/force specific returns outside the purview of the Unit weāre testing. I would probably opt to test some of those things from the user perspective. Since weāre mocking potentially tons of data and workflows.
If weāre testing the behavior of a unit. Then weād match it more closely with the userās expected journey (preferably with a QA as oversight to ensure different approaches) utilizing less mocks and more real-world components. Awesome, but then it begs the next questionā¦
What does this API do? Is it stateless and only handle āsimpleā calculations. I send data, the API massages the data and returns something. Or does this API reach out to other APIs to aggregate all the data needed to complete its task? If itās the latter AND weāre using mocks. Then I would include it as Acceptance Test Criteria. However, if our API is the former and weāre not relying on heavy mocks then it moves onto the next question.
Whatās the risk to the end-user experience? If itās a high risk to the user, definitely still have some acceptance tests around the desired user workflow. If itās a lower risk, and the team/business is comfortable moving on, then I wouldnāt include them.
Generally, if we follow the testing pyramid and have a variety of unit tests and integration tests, we generally will catch roughly 90% of defects before itās deployed. The acceptance test criteria can then be used to inform what unit/integration tests are needed to be written.