Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

E2E testing scaffolding #105

Merged
merged 2 commits into from
Apr 21, 2023
Merged

E2E testing scaffolding #105

merged 2 commits into from
Apr 21, 2023

Conversation

josecelano
Copy link
Member

@josecelano josecelano commented Apr 18, 2023

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?

@josecelano josecelano changed the title Prrof of Concept: E2E tests suite Proof of Concept: E2E tests suite Apr 19, 2023
@josecelano
Copy link
Member Author

For some reason, it's not working on the GitHub runner. It works on my local machine:

cp .env.local .env
./bin/install.sh
./docker/bin/e2e-env-up.sh
docker ps
cargo test -- --ignored 
./docker/bin/e2e-env-down.sh

It seems the tracker service is not started. See output for the docker ps.

@josecelano josecelano changed the title Proof of Concept: E2E tests suite E2E testing scaffolding Apr 21, 2023
@josecelano josecelano mentioned this pull request Apr 21, 2023
5 tasks
@josecelano josecelano marked this pull request as ready for review April 21, 2023 08:40
@josecelano
Copy link
Member Author

Hi @da2ce7 @WarmBeer, this is ready to review. I will create new issues for adding tests to all the API routes: #106

@josecelano
Copy link
Member Author

ACK eedb0ce

@josecelano josecelano merged commit 66ce532 into torrust:develop Apr 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

1 participant