-
Notifications
You must be signed in to change notification settings - Fork 24
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
Drop dependency on rustc_test #76
Milestone
Comments
Maybe we should do this for UNIC-0.5. I'll take a look this weekend. |
behnam
added a commit
that referenced
this issue
Aug 5, 2017
Convert `punycode_tests` crate to a normal integration test, instead of using `rustc-test` crate, which becomes unstable now and then. If needed to better handle test failures in the future, we can take the approach used in other UNIC integration tests: counting fails/passes and reporting. See <#76>
behnam
added a commit
that referenced
this issue
Aug 5, 2017
Convert `punycode_tests` crate to a normal integration test, instead of using `rustc-test` crate, which becomes unstable now and then. If needed to better handle test failures in the future, we can take the approach used in other UNIC integration tests: counting fails/passes and reporting. See <#76>
behnam
added a commit
that referenced
this issue
Aug 5, 2017
Convert `conformance_tests` crate to a normal integration test, instead of using `rustc-test` crate, which becomes unstable now and then. If needed to better handle test failures in the future, we can take the approach used in other UNIC integration tests: counting fails/passes and reporting. See <#76>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Background: rust-lang/rust#43683
Integration tests using
rustc_test
, although look nicer in the actual test file, aren't that organic (files cannot be just copy-pasted) and can break regularly, because of the changes to rustc internal.For these kinds of tests, we have an alternate solution which collects failed test cases and throws one panic at the end, if there are any fails, with some useful information which can be catched with a
#[should_panic(expected = "... test cases failed! (... passed)")]
pattern.Example: https://github.com/behnam/rust-unic/blob/master/unic/bidi/tests/conformance_tests.rs#L25-L44
This approach also has the benefit that it allows temporary failures for big tests, meaning that you don't have to get everything in perfect shape before you can commit your big test to master. We've been using this for the non-100%-conforming bidi module, enabling gradual improvements over time.
The text was updated successfully, but these errors were encountered: