Ticket #9895 (closed: fixed)
Slow Unit Tests for Alex Buts
Reported by: | Owen Arnold | Owned by: | Alex Buts |
---|---|---|---|
Priority: | major | Milestone: | Release 3.3 |
Component: | Framework | Keywords: | Maintenance |
Cc: | Blocked By: | ||
Blocking: | #9905 | Tester: | Harry Jeffery |
Description (last modified by Owen Arnold) (diff)
We have a number of slow running unit tests which we need to fix as part of the 3.3 maintenance window. We are targeting test suits than execute in > 2 seconds on our clean rhel6 build servers. For IO tests (Loading & Saving) we have applied a more generous threshold of > 5 seconds.
See the full list to see which tests have been assigned to you: http://www.mantidproject.org/images/2/2f/Slow_tests.xlsx_-_Sheet1.pdf
Criteria
- Test suits (each test class instance) should execute in < 1 second as a rough target
- As a corollary to the above, If the test suite contains lots of test methods aim for < 0.1 second per test method
- If for some reason you get the speed up the test below the target using the strategies listed below, you need to justify why when you close the ticket.
Guidelines/instructions to help
- Keep tests readable and improve code readability where possible. Unit tests are documentation.
- Do not delete test methods without good reason. We do not want to reduce test coverage
- Changing the algorithm code to improve speed is OK, but exercise caution. Add additional test coverage if it's not already good enough.
- Take test methods that are slow and involve IO, or are processor intensive and make them into system tests. Integration tests are not Unit tests.
- Most of the speed improvements will probably come from better selection of input data. Caching input data is also a good option.
- Create sub tickets for algorithms or groups of algorithms to help testability if you wish, but mark this ticket as the 'blocked' by each one.
Change History
comment:1 Changed 6 years ago by Owen Arnold
- Owner changed from Vickie Lynch to Alex Buts
- Status changed from new to assigned
- Description modified (diff)
- Summary changed from Slow Unit Tests for Vickie Lynch (cloned) to Slow Unit Tests for Alex Buts
comment:4 Changed 6 years ago by Alex Buts
refs #9895 This should fix ConvertToDiffractionMDWorkspace tests
The test is not written by me but just decreasing number of test points by two orders of magnitude do works without, seems, affecting the coverage.
Changeset: db3094375713062a406828ef97fbac139edbd423
comment:5 Changed 6 years ago by Alex Buts
refs #9895 This should fix MaskPeaksWorkspaceTest
by creating source workspace with the same number of events as before.
Changeset: 13a2114ab15f37af5ca2e4141131faead0079b2a
comment:6 Changed 6 years ago by Alex Buts
- Status changed from inprogress to verify
- Resolution set to fixed
I've reduced the times for ConvertToMDDiffractionWorkspace2Test and ConvertToMDDiffractionWorkspaceTest to less then one second by decreasing the number of points to process.
As for ConvertToMDMinMaxGlobalTest and ConvertToMDMinMaxLocalTest, their execution times are in order of 20ms and I do not see how or where seconds may come from.
To test look at the test results and test execution time for any development build.
comment:7 Changed 6 years ago by Harry Jeffery
- Status changed from verify to verifying
- Tester set to Harry Jeffery
comment:8 Changed 6 years ago by Harry Jeffery
- Status changed from verifying to closed
Merge remote-tracking branch 'origin/bugfix/9895_SlowUT'
Full changeset: 716362e2d5b1cfe05cb121ed021983c791f23b6e