Integration tests for UDP Tracker

[josecelano]

I'm trying to reproduce the error in issue #42. I've only created the scaffolding for integration tests so far.

If there is no bug I want to use this scaffolding for other integration tests. If we consider them helpful.

[josecelano]

hi @da2ce7 @WarmBeer I have added three tests:

• should_return_a_bad_request_response_when_the_client_sends_an_empty_request
• should_return_a_connect_response_when_the_client_sends_a_connection_request
• should_return_an_announce_response_when_the_client_sends_an_announce_request

After adding the third one, I started having random failures for the third one. First, I send the "connect" request and then the "announce" request. For some reason, the client does not receive the "announce" response, but the server is sending it (I see it in the log).

If I comment out the first two tests, It always works, so tests must not be isolated. I'm using a different client instance with a different local port for each test to be sure clients do not collide.

[josecelano]

Sometimes I get this message:

2022-10-06T19:36:29.518810036+01:00 [torrust_tracker::logging][INFO] logging initialized.
2022-10-06T19:36:29.518884993+01:00 [torrust_tracker::jobs::udp_tracker][INFO] Starting UDP server on: 127.0.0.1:6969
test udp_tracker_server::should_return_a_bad_request_response_when_the_client_sends_an_empty_request ... ok
thread 'udp_tracker_server::should_return_an_announce_response_when_the_client_sends_an_announce_request' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 111, kind: ConnectionRefused, message: "Connection refused" }', tests/udp.rs:118:43
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
test udp_tracker_server::should_return_a_connect_response_when_the_client_sends_a_connection_request ... ok
test udp_tracker_server::should_return_an_announce_response_when_the_client_sends_an_announce_request ... FAILED

failures:

failures:
    udp_tracker_server::should_return_an_announce_response_when_the_client_sends_an_announce_request

test result: FAILED. 2 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

And sometimes, the tests stop at the third test (there is no timeout for the "receive" data function).

If I stop the test execution with "CTRL+C" the socket is not close because there is still a thread (I suppose it is the udp server).

[mickvandijke]

Hey @josecelano ,

When you run the tests synchronously Eg:

#[tokio::test]
async fn test() {
    should_return_a_bad_request_response_when_the_client_sends_an_empty_request().await;
    should_return_a_connect_response_when_the_client_sends_a_connection_request().await;
    should_return_an_announce_response_when_the_client_sends_an_announce_request().await;
}

They pass 100% of the time.

I think when you run the tests at the same time, each of the tests will try and boot up a new udp tracker while all the tests are ongoing. This probably leads to packet loss.

So to fix it, we either have to run the tests synchronously or provide each test with its own UdpServer (on a unique port).

[josecelano]

hi @WarmBeer @da2ce7, I've also added the test for the scrape request. I think it's ready for review. I only check basic behaviour. Only the happy path, and I only check the response type. Particular cases are (or should) be covered by unit tests. If you think that other tests could be helpful, let me know.

Maybe adding more tests to cover the full specification would be nice. That would be useful to run smoke tests against live UDP servers. But maybe it makes more sense to use a real client for that and make it an independent project.