The trick you did to have the test command declare the test description before the actual test as well as having it flush out the result of the previous test is a bit scary, though, and makes it hard to implement more advanced features. How about this for API?
test "Description" — just declares the test description
ok — pass/fail based on $?
pass and fail — unconditionally pass or fail (for use inside more complex shell logic)
skip — emits a skipped test (ok N - description # SKIP)
todo — mark the next test as a TODO (not ok N - description # TODO)
diag — Print a diagnostic line (starts with a # , then anything after, will be printed by prove -v but can be suppressed when you just want test results).
The change does add one line in the simplest case, but in my opinion it would be worth it for the sake of avoiding confusion.
A TODO test is “expected to fail”, which means that when it fails it doesn’t increment the failure count, and when it passes, the test harness will tell you about it so that you can remove the TODO annotation. It’s a very nice way to “write failing tests” without actually making the test run fail.
Generally speaking, I’m not a big fan of advancing for the sake of advancing and rather keep things as simple as possible. Actually, not a big fan of doing anything for the sake of doing it.
Also, in general, if something feels scary, I’d rather not change it but understand it.
Regarding confusion, why avoid confusion?
Now, regarding the technical ideas, I think they’re good but for now I’m going to leave this version unchanged, however you can always download the code and add the chances yourself for your own use cases. I’ll keep your ideas in mind.
Nice idea :)
The trick you did to have the
testcommand declare the test description before the actual test as well as having it flush out the result of the previous test is a bit scary, though, and makes it hard to implement more advanced features. How about this for API?test "Description"— just declares the test descriptionok— pass/fail based on$?passandfail— unconditionally pass or fail (for use inside more complex shell logic)skip— emits a skipped test (ok N - description # SKIP)todo— mark the next test as a TODO (not ok N - description # TODO)diag— Print a diagnostic line (starts with a#, then anything after, will be printed byprove -vbut can be suppressed when you just want test results).The change does add one line in the simplest case, but in my opinion it would be worth it for the sake of avoiding confusion.
A
TODOtest is “expected to fail”, which means that when it fails it doesn’t increment the failure count, and when it passes, the test harness will tell you about it so that you can remove the TODO annotation. It’s a very nice way to “write failing tests” without actually making the test run fail.Generally speaking, I’m not a big fan of advancing for the sake of advancing and rather keep things as simple as possible. Actually, not a big fan of doing anything for the sake of doing it.
Also, in general, if something feels scary, I’d rather not change it but understand it.
Regarding confusion, why avoid confusion?
Now, regarding the technical ideas, I think they’re good but for now I’m going to leave this version unchanged, however you can always download the code and add the chances yourself for your own use cases. I’ll keep your ideas in mind.
You can see my use case here: https://adi.tilde.institute/linters/.
I am perplexed as to the point of this. What is the value in it? Why would I want to use it? The post explains none of these things.
The point is to run tests on shell scripts, so that as code changes over time, the output/result of that code is what’s expected/required.
The whole concept of unit testing is explained on Wikipedia if you wish to know more: https://en.wikipedia.org/wiki/Unit_testing
Then I consider this is a very poor attempt at a unit testing library.
Why do you say that?
This is a bit simplistic for my tastes, but thumbs up for another tool that helps people write maintainable shell.
In case anyone wonders: I use shunit2 for testing stuff I write in shell.
The code [0] reads like a joke.
[0] https://adi.tilde.institute/test.sh/test.sh
What do you mean?