backend-application | Public clone of https

This question is a duplicate of Where to write tests for a Frontend/Backend application?, but I wanna get more info if possible.

So, assume that you're writing a new API route /get_something. Now, you ideally wanna test this endpoint to make sure it's working.

Let's consider that this endpoint is a real production endpoint and it is not trivial to build: it requires a specific authentication with a specific list of inputs that should be serialized in a specific way. This means a simple http.Get() call is not gonna cut it: you'll need a dedicated function (e.g., client.BuildGetSomethingRequest()) to call it.

The test (no mocks) should look like this:

• Run a new API request with different inputs
• Assert that the outputs match the expected outputs

Question here is where should the test for this component live?

If you write the test in the backend (i.e., the same codebase the route is gonna be programmed in), you're essentially making a client for that API route (i.e., something like the client.BuildGetSomethingRequest() we talked about earlier) and you'll be copying the same client when making the frontend.

The other alternative is to functionally test in the API route in the frontend. This way you'll write the request-building code (e.g., client.BuildGetSomethingRequest()) once and also get the benefit of having a healthy test between frontend and backend.

I personally favor the 2nd approach, but it forces the developer to play between two codebases and it feels weird to write the code in one component, but test it in another.

That being said, if the backend and frontend share the same language (Javascript), it makes sense to couple them, but from a microservices standpoint, this is wrong.

What're your thoughts, folks?

Cheers and thanks