API Testing.

[RavaszTamas]

When doing API testing we don't do unit tests in that case since those tests should be considered as integration tests by convention since most of the time an API layer of the code doesn't really have anything in it other than calling other service components.
The only mocking to be done here beforehand us that if there are external API calls for other services that are used in the applications, in other cases all the code should be executed.

Note: Might create a PR in the future with these changes.

[godraadam]

Things worth unit testing about API endpoints:

• path/query param or request body data validation
• response status codes for different scenarios
• response data shape
• headers present
• etc.

Which are different from integration testing.
Pros: if API is expected to be stable, unit testing them can ensure that, while keeping the tests fasts unlike end-to-end testing.
Cons: if API is subject to frequent changes in early development, unit tests become more of a hurlde than a tool.

[RavaszTamas]

In that case separate Integration Test examples should be added as well. Given your explanations above then in a separate folder like test/IT or something.

[RavaszTamas]

On the other hand the points you have mentioned above can be also tested using the same Integration test since all validations and responses and used headers are tested with the integration and the unit test for the same endpoint and it becomes redundant. Imagine the case when you make massive changes in the underlying codebase and the unit tests for the api are to bae changed as well and at the integration tests as well, so you have to redo two sets of tests instead of just one.

We can do both approaches then doesn't really matter, but in that case we need to set up an internal convention on how de we approach it.

[godraadam]

Yes, both unit testing and integration testiing is needed for good guarantees. Problem with integration testing is that they are usually slow.
Propose: create e2e tests in separate subfolder of tests. Integration tests should run only in CI environments, while developers can rely on unit tests, to get quick feedback on their work locally.

[RavaszTamas]

That can work, but Integration Test should be executed locally before they are pushed to a CI environment. Usually those environments can be resource limited and much slower than just running all tests locally first.

Like running a postgres DB in docker is two commands to setup as an example, and integrating it with pytest is not that complicated.

SQLite is really dumb and as an example some tests are not behaving the same when using sqlite or postgres and if the production env is in postgres then the integration tests should also use postgres as well.