Add --filter option to run tests matching a regular expression #126
Conversation
Touch-ups to use more convenient Bash syntax.
This is in preparation for adding the --filter option, which will require consuming the argument that follows it.
Closes #106. This enables the user to execute a subset of tests that match a regular expression.
libexec/bats-core/bats
Outdated
| version | ||
| printf 'Usage: bats [-c] [-r] [-p | -t] <test> [<test> ...]\n' | ||
| printf '%s\n' \ | ||
| 'Usage: bats [-h] [-c] [-f <regex>] [-r] [-p | -t] <test> [<test> ...]' |
There was a problem hiding this comment.
While we're here I've been wondering if we should unify the two help outputs - I rarely want to see the short options without long info. What do you think about moving the version and the Usage: headers to help() and always showing that? /cc @jasonkarns
There was a problem hiding this comment.
I've kept version separate, but consolidated usage() and help() into usage(). How's that?
| esac | ||
| done | ||
| fi | ||
| while [[ "$#" -ne 0 ]]; do |
There was a problem hiding this comment.
This block looks much cleaner 👍
| printf '%s() { bats_test_begin "%s" %d; %s\n' "$encoded_name" "$name" \ | ||
| "$index" "$body" | ||
|
|
||
| if [[ -z "$BATS_TEST_FILTER" || "$name" =~ $BATS_TEST_FILTER ]]; then |
There was a problem hiding this comment.
I wonder if this should be case insensitive? It's certainly more convenient that way, as the only way I know of altering Bash regex case sensitivity is out-of-pattern, e.g. shopt -s nocasematch.
There was a problem hiding this comment.
I'm leaning against case insensitivity, but not strongly. Is it really significantly inconvenient for you, @sublimino? If it isn't, yet the case sensitivity reveals itself as a point of friction for users, perhaps we could add it later.
There was a problem hiding this comment.
It's a minor annoyance with the first time I tested this PR, that's all :) I'll feed back after I've used it in anger
There was a problem hiding this comment.
So are you good to go with this update? Feel free to merge if you like, or wait if you want @jasonkarns or others to chime in. (On the changes as they are, as well as whether I should throw in case insensitivity.)
I know I still owe @jasonkarns feedback on #124 as well... But after digging into this and queuing up some other cleanups and changes on top of this on Saturday, I gave myself a break on Sunday.
There was a problem hiding this comment.
For what my two cents is worth, I don't think we gain much from having case insensitivity here. That said, if it is a friction point for users later, we could implement an --ifilter option to allow the user to decide whether they want case insensitivity or not. As far as actually doing case insensitivity, shopt -s nocasematch may be the only way we can do it without explicitly requiring Bash 4+. We also would run the risk of name collisions, and would need to have detection logic for that in the event it is used. On the whole, I'm not sure that case insensitivity support gives us enough back to offset the implementation effort.
All of that said, the rest of this looks good to me.
Per @sublimino's suggestion in #126, `usage()` and `help()` have been combined into `usage()`. Also updates the format of the `Usage:` stanza to make it more readable. Also adds the `BATS_VERSION` environment variable, which seems like a reasonable item to export. This implementation is in conflict with the change @jasonkarns made in #124, though as small change to that PR should bring it in line.
This was causing the extended syntax tests to fail when running via `bats -f extended test` because none of the tests run under those cases matched `BATS_TEST_FILTER`. Also removed some vestigial `emit_debug_output` calls, and replaced `bats_trim_filename` with a direct string prefix removal expression when computing `RELATIVE_FIXTURE_ROOT`.
This is a little cleaner in a sense, and allows us to add other options more easily in the future.
Also updates the README and adds a few entries to the "Unreleased" section of the CHANGELOG.
Now that the filter is passed through as a command line flag, BATS_TEST_FILTER no longer exists.
|
FYI, I've also pushed commits to remove |
`BATS_PERFORM_TEST_FLAGS` will make it easier to pass flags through when implementing features in the near future. Also added some comments to explain what's happening with bats-exec-test re-invoking itself via `bats_perform_tests`.
All manner of builds started failing on Bash versions < 4.4 (admittedly I didn't test using 3.2.57(1)-release before pushing): - https://travis-ci.org/bats-core/bats-core/builds/406704189 - https://travis-ci.org/bats-core/bats-core/builds/406704230 Chapter and verse from https://tiswww.case.edu/php/chet/bash/CHANGES: > This document details the changes between this version, bash-4.4-rc2, > and the previous version, bash-4.4-beta2. > > 3. New Features in Bash > > a. Using ${a[@]} or ${a[*]} with an array without any assigned > elements when the nounset option is enabled no longer throws an > unbound variable error. This sidesteps the issue by using `BATS_PERFORM_TEST_CMD` to building the re-invoked bats-exec-test command, ensuring the array won't be empty.
|
In the interest of keeping things moving, I'm going to merge this now and submit my next cleanup PR. @jasonkarns, I've literally put time on my calendar for Saturday morning to take a look at #124 and take it for a test drive. I'm thinking we can use it to release v1.2.0 by early next week. |
Closes #106. This enables the user to execute a subset of tests that match a regular expression.
Also does a couple other things (might be easier to review commit-by-commit):
--filteroption to take an argument (the previous algorithm wouldn't).IFS=was missing fromhelp().encode_nametobats_encode_test_nameto avoid collisions.