selectrum
selectrum copied to clipboard
radian-software
Add tests
You might also get some inspiration from this hand-rolled test suite for a package I never really got around to finishing: https://github.com/raxod502/dumbparens/blob/master/dumbparens-tests.el
I'm really proud of it, particularly the part where making individual tests is so trivial, and it allows you to specify arbitrary keyboard actions in an easy to understand format. My philosophy with tests is that they should be absolutely trivial to write, otherwise nobody's going to write them, least of all me :)
An example test: https://github.com/raxod502/dumbparens/blob/d9e5f0745cc7b233ae8d4a303f18a533870237c3/dumbparens-tests.el#L117-L121 And the part of the test runner that handles translating the keyboard input: https://github.com/raxod502/dumbparens/blob/d9e5f0745cc7b233ae8d4a303f18a533870237c3/dumbparens-tests.el#L71
This approach might not work for Selectrum. I don't know how keyboard macros interact with recursive edits and/or the minibuffer.
I have the hope that there already exists some test framework which would handle it for us! There are enough similar completion systems - maybe we find something reasonable somewhere.
My philosophy with tests is that they should be absolutely trivial to write, otherwise nobody's going to write them, least of all me :)
My philosophy is even lazier - I prefer golden tests and avoid writing tests manually. In the case of your dumbparens this would probably work well. You type some key sequence and then record the output, and the test cases are auto generated behind the scenes. If something changes, regenerate the output.
Those tests look great! They also remember me of the approach used in whole-line-or-region. I did something similar for objed tests which were inspired by those used in lispy. In objed to add a new test I would create a file with the key input at the top and describe the buffer state before and after like this. Unfortunately no one has extracted the general idea of these approaches to a package AFAIK. Maybe we can transfer some of these concepts to the tests we need for Selectrum. For now we could start with something simple like some completing-read or read-file-name calls which check for the expected UI state afterwards (shown candidates, selection state).
@clemera It would be ideal if we find a solution which works in general. Then I could use the test lib for consult too!
Once we have enough tests in place we can look for opportunities to extract things which could be generalized. But for the start we could keep things simple, most important to me would be to get some basic functionality tests first to avoid regressions like in #297.
@clemera No I am not asking for generalizing tests, I am rather asking if there is a test framework which would work for both selectrum and consult. If selectrum decides to include its own self baked test framework this would not be be useful for me.
My context was different, in that case I think a combination of ert and with-simulated-input could work for consult, too. I'm not aware of existing solutions tailored to minibuffer completion tests.