Slow Unit Tests for Martyn Gigg

[Owen Arnold]

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

1. Test suits (each test class instance) should execute in < 1 second as a rough target
2. As a corollary to the above, If the test suite contains lots of test methods aim for < 0.1 second per test method
3. 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

1. Keep tests readable and improve code readability where possible. Unit tests are documentation.
2. Do not delete test methods without good reason. We do not want to reduce test coverage
3. Changing the algorithm code to improve speed is OK, but exercise caution. Add additional test coverage if it's not already good enough.
4. 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.
5. Most of the speed improvements will probably come from better selection of input data. Caching input data is also a good option.
6. 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.

[Martyn Gigg]

It looks like the changes in #9740 have decreased all of these tests below the required 2s threshold. The speeds of the tests, on the last ​clean develop build, marked against my name are:

• AlgorithmManagerTest - 1.2s
• FrameworkManagerTest - 1.4s
• ResolutionConvolutionCrossSectionTest - 35ms

I don't think it's worthwhile doing anything else on the code relating to this.

[Owen Arnold]

Agreed. There has been a speedup. Would be nice if some of these tests ran in < 1 second, but not worth the effort, and in some cases would be impossible on RHEL6 anyway, based on the issues we have seen around OMP loop thread creation.

[Stuart Campbell]

This ticket has been transferred to github issue ​10741