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

Various test clean ups #1145

Merged
merged 9 commits into from
Nov 23, 2019
Merged

Conversation

Thomasdezeeuw
Copy link
Collaborator

Various test clean ups. Easiest to review by commit.

Updates #995

@Thomasdezeeuw
Copy link
Collaborator Author

It seems that Azure pipelines rebases the pr on master, which had an additional commit compare to my local branch. That is why the CI is failing.

@Thomasdezeeuw
Copy link
Collaborator Author

After a rebase on master the CI is green now.

Copy link
Contributor

@kleimkuhler kleimkuhler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like a lot of what this PR does, but I think the assert_... macros provide a lot of value in testing; I'm not sure removing these is the best path forward. For example, dealing with test errors with the macro:

failures:

---- unix_stream_try_clone stdout ----
thread 'unix_stream_try_clone' panicked at 'assertion failed: error = Os { code: 35, kind: WouldBlock, message: "Resource temporarily unavailable" }', tests/unix_stream.rs:166:16
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.


failures:
    unix_stream_try_clone

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 13 filtered out

without the macro:

failures:

---- unix_stream_try_clone stdout ----
thread 'unix_stream_try_clone' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 35, kind: WouldBlock, message: "Resource temporarily unavailable" }', src/libcore/result.rs:1165:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.


failures:
    unix_stream_try_clone

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 13 filtered out

With the macro, the failure output provides the exact line in the source where the error occurred. With only unwrap, you don't know which unwrap caused the failure in the test. For tests that have a lot of unwraps this can be difficult to hunt down.

Overall, I really like the addition of expect_read! and expect_write!! Thanks for consolidating a lot of those assertions.

tests/util/mod.rs Outdated Show resolved Hide resolved
tests/util/mod.rs Outdated Show resolved Hide resolved
tests/util/mod.rs Outdated Show resolved Hide resolved
@kleimkuhler kleimkuhler mentioned this pull request Nov 14, 2019
@Thomasdezeeuw
Copy link
Collaborator Author

@kleimkuhler I agree that when using unwrap having an indirect/incorrect line number is a bit annoying. I always run with RUST_BACKTRACE=full (or 1), so the problem is less pressing. I don't really agree that having two macros for is worth it. Also hopefully something like rust-lang/rfcs#2091 would fix the problem in future.

I also fixed the expect_read docs.

}
}

impl From<Interests> for Readiness {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this! The Mio update in Tokio could probably use something similar instead of the explicit checks that are there.

@kleimkuhler
Copy link
Contributor

@Thomasdezeeuw Even with assert_ok!, I do usually end up switching to RUST_BACKTRACE=1 once I need to actually see why a Result is not the expected value, so that is a good point.

There are going to be some conflicts with the UDS tests getting split up, but I think most will just be replacing the macros with unwrap. Once that is taken care of I'll be good with this change!

The unwrap function has the same effect.
The unwrap_err function has the same effect.
Used in the ExpectEvent structure.
Removing expect_readiness completely. It didn't use the token so it was
unclear what event should have read/write closed indicators.
This also removes the echo_server test from the tcp module. All
functionality is tested elsewhere and this test is just too complex to
attempt to fix (it used the TryRead and TryWrite traits).
Some places checked the return value after a write, but all. This ensure
that all write, send and send_to calls check the return value.
Testing macro that calls read/recv/peek or recv_from/peek_from and
checks if the received bytes are expected. In case of {recv,peek}_from
it also checks the source address.
@Thomasdezeeuw
Copy link
Collaborator Author

Rebased this on master @kleimkuhler can you take another look? I'll to merge this quickly as rebasing this is a pain in the.. you know what :)

Copy link
Contributor

@kleimkuhler kleimkuhler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Thanks for dealing with the rebase and getting these all cleaned up.

@Thomasdezeeuw Thomasdezeeuw merged commit b4bc8f1 into tokio-rs:master Nov 23, 2019
@Thomasdezeeuw Thomasdezeeuw deleted the test-cleanup branch November 23, 2019 13:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants