Skip to content

Test order #40

Open
Open
@regexident

Description

@regexident

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:

  1. Tests that failed
  2. Tests that succeeded

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions