Conditional skipping tests about bash_unit

[schmidtandreas]

Hi @pgrange,
thank you for your reply and suggestions!

When you run bash_unit, you can run it for several test files at a time. If we introduce this feature, I would consider that skip_if would only apply to the tests present in the same file, right?

Yes, for my use case it would be enough.

Regarding the PoC: I implemented a kind of PoC in dirty way as a workaround.
Maybe it is helpful for you too. My approach was a conditionally renaming of test function:

test_some_test_function()
{
}

if [ -f "/some_file" ]; then
    eval "$(echo "pending_some_test_function() { assert_false; }")"
    unset -f test_some_test_function
fi

Here I reused the already existing "todo" or "pending" mechanism for skipping the test.
This approach have the benefit that the test not just disappears, but instead is marked as skipped.
(Even if the skip message here is the wrong one.)

It would also be helpful if the skip_if could also provide an individual skip message.

[pgrange]

Thanks for your answer and the exemple. Very useful indeed.

Also, I know that's not what you're asking for but I felt it was a good first step so I added a new -s option to the command line parameters in a branch:

-s pattern
skip tests which name matches the given pattern. You can specify several patterns by repeating this option for each pattern. Tests will appear in bash_unit output as pending.

Not sure if I keep it in the final result and/or if it can help already for your use case because it would impose you to add that when calling bash_unit so you would have to change the way you call it to not run these tests and from your description of your situation I'm not sure it would help.

Anyway, just sharing in case it helps.

As for displaying the reason why the test has been skipped that could be a bit tricky, I need to think about it as it has to work for normal and tap output and I'm not sure how it would fit with the current output without introducing too much noise 🤔

[pgrange]

You're just lucky there's no snow on the ski slopes ;)

[pgrange]

Hi @schmidtandreas and thank you for your interest in bash_unit.

When you run bash_unit, you can run it for several test files at a time. If we introduce this feature, I would consider that skip_if would only apply to the tests present in the same file, right?

I'll see if I can make a proof of concept to see how this can work. In the meantime, take a look at test_skipping where I've just put an example of how you would already be able to skip some tests with bash_unit as it is now. It's a bit quick and dirty as the tests would not appear at all in the tests output, not even to say that they were skipped which is not cool in my opinion. But maybe that can help you already move forward.

The idea is to define the tests you want to be run conditionally inside an if condition. That way, if the condition is false, bash_unit will just never now about these tests in the first place, hence they are totally ignored:

if uname | grep Darwin
then
  test_proc_does_not_exist() {
    assert_fail "ls /proc/" "there should not exist /proc on Darwin"
  }
  test_another_test_to_run_only_on_darwin() {
    assert "mkdir -p /tmp/foo/bar"
  }
fi

I hope that can help.
Cheers,

[pgrange]

Please find a first version of skip_if in branch skipping_logic. Maybe you can give it a try and let me know how this works for you.

[schmidtandreas]

Cool, thanks for such quick solution!
I'll try it in next days by the weekend at the latest.

[schmidtandreas]

I tested it with skip_if and it works great with tap format.
With normal format I get an error, due to set -u in my bash script.
Could you fix this with:

  pretty_format "$YELLOW" "\u2717" "${1:-}"

on line 296?

One other point could be improved IMHO:
It is possible to add some kind of SKIPPED notification and for tap format something like # skipped?
Pending notification is confusing little bit.

[pgrange]

Good points!

I fixed the formatting issue.

Also, I've made the distinction in output between skipped and pending tests. Hope that helps.

[schmidtandreas]

I am happy :) My use case is covered and working great!
Thank you again for such quick response!

[pgrange]

#108 merged into master.