Skip to content
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

Slow Unit Tests - LoadEventNexusTest #10993

Closed
1 task done
OwenArnold opened this issue Aug 21, 2014 · 3 comments
Closed
1 task done

Slow Unit Tests - LoadEventNexusTest #10993

OwenArnold opened this issue Aug 21, 2014 · 3 comments
Assignees
Labels
Framework Issues and pull requests related to components in the Framework Maintenance Unassigned issues to be addressed in the next maintenance period. Stale This label is automatically applied to issues that are automatically closed by the stale bot
Projects

Comments

@OwenArnold
Copy link
Contributor

This issue was originally TRAC 10151

This ticket is blocked by :

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.

Russell Taylor had previously worked on this, but the tests are still taking 14 seconds to run.


Keywords: Maintenance

@OwenArnold
Copy link
Contributor Author

@OwenArnold (2014-11-19T14:15:49):
Not realistically going to get done for the 3.3 release. This is however linked to the work that Owen and Pete have done (are doing) the ground work for in http://trac.mantidproject.org/mantid/ticket/10471


@NickDraper (2015-04-27T08:10:34):
Moved to R3.5 at the R3.4 code freeze

@OwenArnold OwenArnold added Framework Issues and pull requests related to components in the Framework Maintenance Unassigned issues to be addressed in the next maintenance period. labels Jun 3, 2015
@OwenArnold OwenArnold added this to the Release 3.5 milestone Jun 3, 2015
@NickDraper NickDraper modified the milestones: Release 3.5, Release 3.6 Sep 14, 2015
@NickDraper NickDraper modified the milestones: Release 3.6, Release 3.7 Jan 22, 2016
@peterfpeterson peterfpeterson added this to To do in Maintenance Nov 20, 2018
@stale
Copy link

stale bot commented Feb 23, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. If you feel this is incorrect please comment to keep it alive, with a reason why.

To prevent closure, e.g. for long-term planning issues, add the "Never Stale" label.

@stale stale bot added the Stale This label is automatically applied to issues that are automatically closed by the stale bot label Feb 23, 2021
@stale
Copy link

stale bot commented Mar 2, 2021

This issue has been closed automatically. If this still affects you please re-open this issue with a comment so we can look into resolving it.

@stale stale bot closed this as completed Mar 2, 2021
Maintenance automation moved this from Icebox to Done Mar 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Framework Issues and pull requests related to components in the Framework Maintenance Unassigned issues to be addressed in the next maintenance period. Stale This label is automatically applied to issues that are automatically closed by the stale bot
Projects
Development

No branches or pull requests

3 participants