-
Notifications
You must be signed in to change notification settings - Fork 23
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
Test order #40
Comments
Btw, both of these stats are already collected during test execution. As such
We would "simply" have to add serialization via Serde to persist them to |
Yes, this is a good feature, for large refactoring it's much needed. Ruby's Rspec use this flag: https://relishapp.com/rspec/rspec-core/docs/command-line/only-failures With this persistence file:
With |
I'll look into it when I find some time, thanks! |
I think we should come up with a more sophisticated model for test execution order.
Two goals I would want to achieve by changing the current naïve logic:
Have failing tests fail earlier
For this we would need to keep some stats about the most recent test suite execution.
Based on this we would then partition the sub-blocks of each context into two groups:
The runner would sort the sub-blocks by moving the group of failing tests to the front.
Prevent tests from depending on execution order.
Within these groups then we would want to randomize the order of sub-blocks to prevent accidental dependencies on execution order.
In principle rspec does already prevent one from depending on execution order through its sophisticated environment isolation. In the case of shared mutable state (sharing a database connection behind a mutex between contexts e.g.) however rspec cannot give such guarantees.
The text was updated successfully, but these errors were encountered: