-
Notifications
You must be signed in to change notification settings - Fork 514
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
Restore tests (replaces PR #147) #206
Conversation
the testCreateMultipleCalibration fails if you run only this one. testCreateSimpleCalibration and testCreateMulitpleCalibration use the same data so the result of calibration could be different in regard of the order of the execution. Best to launch |
Thanks @avouspierre. I believe the last commit makes this a "real" fix. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m not quite qualified to review this, I’m afraid.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm submitting this review as a proxy for @itsmojo since his review should count for this PR. I did do a test test, and a test build to a simulator.
This closes Issue #146 |
There are 2 commits to this PR.
testCreateMultipleCalibration
test so it will pass instead of failThese are notes from @itsmojo:
Regarding having to comment out the 4 tests in CalibrationsTests, the issue seems to be that the expected values are only returned on the first Test run for a given iPhone simulator. After the first run, the values seem to be a consistent values of 0.9500000000000307, 15.999999999996717, 91.99999999999918 & 2 (instead of the 0.8, 37, 101 & 1 in the initial run that are being tested for). So this seems like this is a stateful test which really should be reworked to have consistent results on each run. Also, using XCTAssertTrue() for these tests is not as helpful as using XCTAssertEqual() so that you can see both values on a failure and so an optional accuracy parameter can be used to deal with non exact floating point values like 15.999999999996717.
Note:
The original PR #147 was automatically closed when the Trio repository was made public. This replaces that PR.