Is acceptance testing only at E2E level?

Is acceptance testing only at E2E level?

Can our unit tests also be acceptance tests?

Case 1. Web App: Suppose a company is making web apps (e.g. eCommerce stores). USERS are generally people – for example CUSTOMERS. Acceptance tests may involve verification that the user can do certain operations on the UI, see the data on UI, etc.

Case 2 – REST API: Suppose that a company is in the business of selling the REST API as a product, or proovided to other teams within the organization. The USER is the DEVELOPER who’s calling the API. So the acceptance test may verify that the endpoints behave as expected.

Case 3 – Library: Suppose a company is making a library which is re-used internally within the organization or is sold externally. In this case the USER is the DEVELOPER who is using the library.

Now users have certain needs that they want to express, what do they want to achieve by using the system (whether the system is a Web App, REST API, Library, etc.). They have use cases that they want to satisfy. The purpose of ACCEPTANCE TESTS is to verify that those USE CASES work as expected. If the use cases don’t work, then why did we even build the system?

When we think of acceptance testing, we mainly think about it from the e2e perspective, i.e. the whole system has to be wired up, so that the user is using the REAL system. This means, we’re connected to real databases, real email providers, real payment gateways…

But what’s the feedback loop for such an e2e acceptance test? 1 day? 1 week? 1 month? 

Well, however long it takes…

Hmmm… That’s an undefined answer.

How can something with a really long feedback loop be used to drive development on a minute-by-minute basis?

If we see acceptance tests as just e2e tests which verify use cases, and if we see unit tests as verifying classes and interactions, then we have to wait a long while until we get feedback if we satisfied the acceptance criteria.

But what if we could bring down acceptance tests into shorter feedback loops… into minute-by-minute feedback loops? We can do that if our system could express use cases in a way that it is independent of external systems.

We can test use cases at the unit level – so this means we’re emulating acceptance testing at the unit level… It means we can do continuous acceptance testing! We don’t have to wait for the end of the sprint.

After getting assurance from acceptance testing at the unit level (where any external dependencies are replaced by test doubles), we will have less stress when it comes to e2e acceptance testing (whereby we use the real external dependencies but no changes in our logic).

It enables us to use acceptance criteria in our minute-by-minute development.

With Classicist TDD and Hexagonal Architecture, we unit test our use cases using acceptance criteria.