You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This isn't really a bug report, but I would like some advise on the usage of quickcheck in this crate.
The background is that I'm in the process of packaging this crate for Debian, and Debian tries to avoid having multiple different versions of the same software packaged simultaneously. This leads to this package being built with quickcheck 1, instead of quickcheck 0.5.
But it seems like quickcheck 1 have a much larger set of possible inputs to the test functions, for example NaN for floating point values.
That results in these kind of errors:
[capitol@batia quantiles]$ cargo test -- error_nominal_test
Finished test [unoptimized + debuginfo] target(s) in 0.01s
Running unittests src/lib.rs (target/debug/deps/quantiles-63095b9941f69c44)
running 1 test
test ckms::test::error_nominal_test ... FAILED
failures:
---- ckms::test::error_nominal_test stdout ----
thread 'ckms::test::error_nominal_test' panicked at 'called `Option::unwrap()` on a `None` value', src/ckms/mod.rs:360:50
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'ckms::test::error_nominal_test' panicked at 'called `Option::unwrap()` on a `None` value', src/ckms/mod.rs:360:50
thread 'ckms::test::error_nominal_test' panicked at 'called `Option::unwrap()` on a `None` value', src/ckms/mod.rs:360:50
thread 'ckms::test::error_nominal_test' panicked at 'called `Option::unwrap()` on a `None` value', src/ckms/mod.rs:360:50
thread 'ckms::test::error_nominal_test' panicked at 'called `Option::unwrap()` on a `None` value', src/ckms/mod.rs:360:50
thread 'ckms::test::error_nominal_test' panicked at 'called `Option::unwrap()` on a `None` value', src/ckms/mod.rs:360:50
thread 'ckms::test::error_nominal_test' panicked at 'v: NaN | percentile: NaN | prcnt: 0 | data: [NaN]', src/ckms/mod.rs:372:17
thread 'ckms::test::error_nominal_test' panicked at '[quickcheck] TEST FAILED (runtime error). Arguments: ([NaN], 0.0)
Error: "v: NaN | percentile: NaN | prcnt: 0 | data: [NaN]"', /home/capitol/.cargo/registry/src/github.com-1ecc6299db9ec823/quickcheck-1.0.3/src/tester.rs:165:28
failures:
ckms::test::error_nominal_test
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 84 filtered out; finished in 0.00s
One way to solve this is to simply disable the unit tests that fail after the upgrade to quickcheck 1, after all, the tests do work with 0.5.
But disabling a large number of the tests feels like a very bad engineering practice, it will make it a lot harder to discover future problems in the packaging.
I took a stab at trying to see if I could do a full upgrade to 1, fix all the failing tests and send the patch upstream, but I lack a bit of domain knowledge here, so it's quite hard to figure out what the correct behavior should be.
Do you have any suggestions on a good way forward?
The text was updated successfully, but these errors were encountered:
Hi
This isn't really a bug report, but I would like some advise on the usage of quickcheck in this crate.
The background is that I'm in the process of packaging this crate for Debian, and Debian tries to avoid having multiple different versions of the same software packaged simultaneously. This leads to this package being built with quickcheck 1, instead of quickcheck 0.5.
But it seems like quickcheck 1 have a much larger set of possible inputs to the test functions, for example
NaN
for floating point values.That results in these kind of errors:
One way to solve this is to simply disable the unit tests that fail after the upgrade to quickcheck 1, after all, the tests do work with 0.5.
But disabling a large number of the tests feels like a very bad engineering practice, it will make it a lot harder to discover future problems in the packaging.
I took a stab at trying to see if I could do a full upgrade to 1, fix all the failing tests and send the patch upstream, but I lack a bit of domain knowledge here, so it's quite hard to figure out what the correct behavior should be.
Do you have any suggestions on a good way forward?
The text was updated successfully, but these errors were encountered: