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

Add a command to relaunch tests but limited to the failing one(s) #214

Closed
Canop opened this issue Oct 1, 2024 · 7 comments · Fixed by #227
Closed

Add a command to relaunch tests but limited to the failing one(s) #214

Canop opened this issue Oct 1, 2024 · 7 comments · Fixed by #227
Assignees
Labels
enhancement New feature or request

Comments

@Canop
Copy link
Owner

Canop commented Oct 1, 2024

(follows issue #213 and discussion with @GeeWee)

The idea would be to hit a key and have the same test/nextest/whatever job relaunched but scoped to the failing test(s).

Hitting escape would take you back to all tests.

@Canop Canop self-assigned this Oct 1, 2024
@Canop Canop added the enhancement New feature or request label Oct 1, 2024
@GeeWee
Copy link

GeeWee commented Oct 1, 2024

That would also be incredible - just like Jest's option to only rerun failing tests!

@Canop
Copy link
Owner Author

Canop commented Oct 4, 2024

A serious problem is that cargo test doesn't support specifying several tests to run. Either you run them all or you run all the ones which contain a specific string.

So if I want an easy scoping feature, it would run only when there's only one failure. Or when using nextest.

@Canop Canop mentioned this issue Oct 5, 2024
@Canop
Copy link
Owner Author

Canop commented Oct 5, 2024

Tests of the PR welcome!

@GeeWee
Copy link

GeeWee commented Oct 6, 2024

I did a bit of digging, and I think a potential workaround might be to:

  • List all tests
  • Pass the --skip FILTER argument to cargo test, skipping any test that passed from the list. It's a libtest argument that can be passed multitple times.
  • All that's left should be the failing tests.

I'm not 100% if you'll run into issues with command length if you have a lot of tests, but it's at least a possible avenue.

@Canop
Copy link
Owner Author

Canop commented Oct 6, 2024

@GeeWee Oh, I missed that. It's interesting.

@Canop
Copy link
Owner Author

Canop commented Oct 6, 2024

Of course, nextest doesn't support it, which makes it hard to support in a generic way ^^

A skip logic is also very painful in other ways (for example it makes it impossible to serialize the mission order, or to pass it at command line) and would have to be tested on projects with thousands of tests.

So I'll probably merge the current PR as is (when scoping, you're usually interested in your new failing test anyway) and postpone using (or not) --skip. And maybe I'll have a look at cargo test to see if a PR improving it is possible.

@Canop Canop closed this as completed in #227 Oct 6, 2024
Canop added a commit that referenced this issue Oct 6, 2024
# In short

If you ran a test job, and there's a failure, hit <kbd>f</kbd> to have the job "scoped" to the failures, ie not executing other tests.

If you want to go back to all tests, hit <kbd>esc</kbd>.

Fix #214 

# Details

`cargo test` doesn't support passing several test keys, so scoping only takes the first failure.

If you're running another test command, for example `cargo nextest run`, then all failures are part of the scope.

It's possible to start bacon in scoped mode: `bacon test(mymodule::some_fun)`. Hitting <kbd>esc</kbd> will bring you to the unscoped tests.

If you want to define a different binding (maybe you're already using the <kbd>f</kbd> key), you can refer to the `scope-to-failures` internal. For example:

```
[keybindings]
alt-f = "scope-to-failures"
```
@GeeWee
Copy link

GeeWee commented Oct 7, 2024

I think that's a good call :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants