De-randomized tests
As noted several times, code coverage bounces up and down due to randomized tests. One way of avoiding this is to hardcode all cases to be tested: time consuming, but allows to cover all borderline cases. A simpler way would be to initialize the RNG seed somewhere. Definitely not a major issue, but also serves as reminder that we should put order to tests at some point.
- [x] Set at least the RNG seed
- [ ] De-randomize tests
I think it may also be dependent on the order the tests on the different platforms finishes. They seem to differ by the amount that is reported. I haven't verified this though. But we should make sure the tests are non random. As well as improving the tests in student ways, such as looping over tests for different types, and test that the results are of that right type.
On Wed, Mar 29, 2017, 00:15 Lorenzo Stella [email protected] wrote:
As noted several times, code coverage bounces up and down due to randomized tests. One way of avoiding this is to hardcode all cases to be tested: time consuming, but allows to cover all borderline cases. A simpler way would be to initialize the RNG seed somewhere. Definitely not a major issue, but also serves as reminder that we should put order to tests at some point.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kul-forbes/ProximalOperators.jl/issues/21, or mute the thread https://github.com/notifications/unsubscribe-auth/ADFlSVpJ9Br4KEhlfM-Lpv9r9pZastQbks5rqYaNgaJpZM4MsQ2H .