Hi @da2ce7 @WarmBeer. I want to add some tests for the API before changing things, for example, updating dependencies.

I wanted to implement something like what we did for the tracker (integration tests). But If I want to do the same:

• I need to change the application bootstrapping. I need to start/stop the backend programmatically.
• I also need to mock or enable/disable the tracker.

I started following that path, but it requires a lot of changes, and I do not want to make big changes without tests :-/. So I decided to try a different approach:

• Run the backend and its dependencies (tracker and DB) with docker-compose.
• Implement real E2D tests without changing anything (black box).

I'm going to use the same instance. Steps:

• Docker-compose up
• Run the tests
• Docker-compose down

I will need an option to reset the DB. Not implemented yet.

This PR is just the scaffolding with one test for the API entrypoint (about).

I think I can add some tests for most endpoints and then switch to integration tests (like the Tracker). They should be faster and more reliable. I think I can reuse the same tests. The only difference should be the bootstrapping for the app.

Once we have the integration tests, we can start adding the unit tests.

In conclusion, the steps would be:

• E2E test (minimum changes on production code).
• Migrate to integrations test (apply changes needed for integrations tests).
• Start writing unit tests.

This way we always are safe while refactoring.

The only problem I see is we could have a problem with only one app running. But I guess we can avoid test conflicts if we use unique IDs, torrents, users, etcetera, for each test.

What do you think?