What's the quickest way to re-run tests with changed options?

[shepmaster]

A common workflow of mine is to run all the tests, see what tests failed, then focus in on a single failing test, occasionally setting options like --nocapture.

I'm trying out rustic-mode after a long time of using cargo-mode, so I have a strong muscle memory for ctrl-u g (universal-prefix, recompile). Doing this in cargo-mode allows you to edit the cargo test command line in the minibuffer, which is a pretty fast operation.

In rustic-mode, the best I've found so far is p (rustic-popup), navigate down to the "test" line, enter, edit the command line, t. I'm sure I'm overlooking something easier.

[CeleritasCelery]

The easiest way would be with rustic-cargo-test, which is bound to C-c C-c C-t by default (the rustic commands are all under C-c C-c ). If you want to change the arguments you add the universal argument C-u C-c C-c C-t. If you have rustic-cargo-use-last-stored-arguments set to t, it will always reuse the last arguments you entered.

Once the rustic-compile buffer has opened with the test results, you can call recompile on it (g) to rerun as well.

There is also rustic-cargo-test-dwim which is bound to C-c C-c C-c, which will only run the function or module at point.

[shepmaster]

Sorry, I guess I left out some details! I've already got the tests running (using rustic-cargo-test), and now my cursor is inside the compilation buffer. That's when I realize I want to focus on a specific test. Inside that buffer, C-c C-c C-t is not bound to anything, so the C-u prefix won't help. To use that flow, I'd have to switch back to the original buffer first, which is more keystrokes than the cargo-mode equivalent I'm used to. In a way, cargo-mode's C-u g is very similar to C-u C-c C-c C-t but shorter and present in the compilation buffer.

Once the rustic-compile buffer has opened with the test results, you can call recompile on it (g) to rerun as well.

Right, but that doesn't allow me to change how that buffer runs the tests. It's great after I've focused on a test and am attempting to fix it, but right now I'm trying to streamline the "focus on one test" part.

There is also rustic-cargo-test-dwim which is bound to C-c C-c C-c, which will only run the function or module at point.

Which is useful, but it's approaching the problem from a different direction than what I'm talking about. To use this in my described flow, I'd be editing code, run all the tests, read the failed test name in the test buffer, navigate to the test back in the code buffer, then run the test. Popping back from the test buffer to the code buffer and the navigation to the test is a pretty big stumble when I'm in the flow.

In a magical world where everything works they way I want it to, rustic-mode would do some emacs magic on this output of the tests so that I could click / press enter on the test::beta text and it would change the test arguments to include --exact test::beta:

running 71 tests
test test::alpha ... ok
test test::beta ... ok
test test::omega ... FAILED

---

If you have rustic-cargo-use-last-stored-arguments set to t, it will always reuse the last arguments you entered.

As an aside, is there an easy way to reset the arguments back to default? I actually like the stickiness of the arguments, but once I'm done focusing on a test I want to go back to the full list.

[shepmaster]

rustic-mode would do some emacs magic on this output

This is some really nasty, hacked-up code that shows what I vaguely mean:

(defun jpg-focus-test (button)
  (let* ((test-name (button-get button :jpg-focus-test-name))
         (test-args (format "-- --exact %s" test-name)))
    (rustic-cargo-test-run test-args)))

(define-button-type 'jpg-focus-test-button 'action 'jpg-focus-test)

(defun jpg-focus-test-hook ()
  (goto-char compilation-filter-start)

  (while (re-search-forward "^test \\([^\s]+\\) ..." nil t)
    (let ((start (match-beginning 1))
          (end (match-end 1))
          (test-name (match-string 1)))
      (make-text-button
       start
       end
       :type 'jpg-focus-test-button
       :jpg-focus-test-name test-name))))

(add-hook 'compilation-filter-hook 'jpg-focus-test-hook)

With this, the compilation output looks like:

Activating that button focuses on the one test. My elisp is... poor... so I'm sure that this could be much better. Thoughts I had while writing this:

1. How can I restrict this filter to running only on rustic compilation modes? Right now it's every compilation.
2. It'd be cool to start from the current buffers test arguments and update them to include the test name specification. That way, we don't lose details that may be needed to make the test work.
3. How does the filter pass data to the hook, exactly? For example, if we get half of a line in one call and the other half in the next, the regex would never match. Maybe it needs to only look at whole lines somehow?
4. It'd be good to add customization for the button face.

Please feel free to take all of this code (ideally improved!) and put it in rustic directly, if you think it'd be useful.

[shepmaster]

Ah, I see now that your PR has similar functionality. The only difference I have seen is that using a button provides some amount of visual feedback that something is actionable there. Not sure if there's anything to address that, however.

[CeleritasCelery]

Thanks for clarifying. I think the idea of adding a prefix argument to rustic-recompile to change the command is great. I can work on implementing that.

As an aside, is there an easy way to reset the arguments back to default? I actually like the stickiness of the arguments, but once I'm done focusing on a test I want to go back to the full list.

The easiest way is probably to launch with the prefix argument again and clear it.

[CeleritasCelery]

I implemented your suggestions in #78. Test it out if you get a chance.