Where to write tests for a Frontend/Backend application?

Question

I want to write a web application with a simple Frontend-Backend(REST API) architecture. It's not clear to me where and how to write tests.

Frontend: should I write tests mocking API responses and testing only UX/UI? Backend: should I write here API call testing and eventually more fine grained unit testing on classes?

But in this way I'm afraid that Frontend testing is not aware of real API response (because it's mocking independently from the backend). On the other side if I don't mock API response and use real response from backend, how can the Frontend client prepare the DB to get the data he wants?

It seems to me that I need 3 kind of testing types: - UX/UI testing: the Frontend is working with a set of mock responses - API testing: the API is giving the correct answers given a set of data - Integration testing: The Frontend is working by calling really the backend with a set of data (generated by who?).

There are framework or tools to make this as painless as possible? It seems to me very complicated (if API spec changes I must rewrite a lot of tests)

any suggestion welcome

Answer 1

Well, you are basically right. There are 3 types of tests in this scenario: backend logic, frontend behaviour and integration. Let's split it:

Backend tests

You are testing mainly the business logic of the application. However, you must test the entire application stack: domain, application layer, infrastructure, presentation (API). These layers require both unit testing and integration testing, plus some pure black box testing from user's perspective. But this is a complex problem on this own. The full answer would be extremely long. If you are interested in some techniques regarding testing applications in general - please start another thread.

Frontend behaviour

Here you test if frontend app uses API the right way. You mock the backend layer and write mostly unit tests. Now, as you noticed - there can be some problems regarding real API contract. However, there are ways to mitigate that kind of problems. First, a link to one of these solutions: https://github.com/spring-cloud/spring-cloud-contract. Now, some explanation. The idea is simple: the API contract is driven by consumer. In your case, that would be the frontend app. Frontend team cooperate with backend team to create a sensible API, meeting all of client's needs. Frontend tests are therefore guaranteed to use the "real API". When client tests change - the contract changes, so the backend must refactor to new requirements.

As a side note - you don't really need to use any concrete framework. You can follow the same methodology if you apply some discipline to your team. Just remember - the consumer defines the contract first.

Integration tests

To make sure everything works, you need also some integration e2e testing. You set up a real test instance of your backend app. Then, you perform integration tests using the real server instead of fake mockup responses. However, you don't need (and should not) duplicate the same tests from other layers. You want to test if everything is integrated properly. Therefore, you don't test any real logic. You just choose some happy paths, maybe some failure scenarios and perform these tests from user's perspective. So, you assume nothing about the state of the backend app and simulate user interaction. Something like this: add new product, modify product, fetch updated product or check single authentication point. That kind of tests - not really testing any business logic, but only if real API test server communicates properly with frontend app.