bats: add support for deteriministic --shuffle#196
bats: add support for deteriministic --shuffle#196cyphar wants to merge 1 commit intobats-core:masterfrom
Conversation
|
This still needs some tests -- though I'm a little cautious about how we're going to test the seed values in a way that doesn't cause us problems in the future (if |
648e3ac to
0ad3d99
Compare
d09dd86 to
03b17b2
Compare
|
As an update, it looks like old bash versions don't like the |
|
I'm 👍 on the feature. Haven't looked at the implementation, though. But before we settle too hard on the interface (the flag and var names), can we put together a quick survey of what other tools are using for their CLI flags/options/var names? That way we can follow any existing norms, however, slight they may be? |
There are many cases where tests accidentially depend on one another, and bats users might want to ensure their test suite does not have this behaviour. While --jobs gives you some randomness in the execution, --shuffle allows for deterministic ordering in order to re-test a particular case (by setting BATS_SHUFFLE_SEED) and also shuffles all tests entirely. In order to avoid a dependency on GNU coreutils (for OS X users), we can't use shuf(1) and instead have to resort to a fairly contorted usage of paste(1). On the plus side is means we can be sure that the ordering won't change with new shuf(1) versions. Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
|
@jasonkarns As far as I'm aware there aren't many other testing tools which provide something like this. @sublimino mentioned this in #171. Ruby has |
|
@cyphar Virtually every testing tool that I'm aware of, which supports random execution, also supports re-running a prior random order deterministically. RSpec: Minitest is random by default and accepts seed via Cucumber uses In JavaScript/node land: Mochajs doesn't officially support random order, but the "heavily used" patch uses Jasmine has Tap, Jest, Ava, Cypress don't seem to support true randomization nor determinism with a seed; though they support parallelization of the suite so there's some implicit randomicity but without the ability to re-run that particular order. (And they can both force serial runs, which of course isn't the same as deterministically re-running a random order.) The rest of the common JS tools (tape, teenytest, nightwatch, qunit) don't seem to support randomization at all. I would be curious to see what features the top 2 or 3 testing tools of python, php, perl, go, java, .net support. At the very least |
|
Personally, I do like cucumber, rspec, and mochajs' dual use of a single flag for both enabling randomization and providing the seed (since a seed without random ordering is meaningless).
|
|
I will go with
Is not a large number of tools, not that no tools which support random execution support re-using the same order (in fact I would argue the opposite because it's such an obvious thing to need). |
| mkdir -p "$BATS_TEST_SUITE_TMPDIR" | ||
| } | ||
|
|
||
| arrays_equal() { |
There was a problem hiding this comment.
might be worth putting into a seperate commit, maybe with dedicated tests
| # We can't be sure what the order will be -- but it should be different | ||
| # between different runs. We ignore all #-lines because they always include | ||
| # BATS_SHUFFLE_SEED which should always be different anyway. | ||
|
|
There was a problem hiding this comment.
Not sure how it is made sure that the several runs will not accidentally produce the same order. I guess that even different seeds could result in the same order.
If there is a slight chance of a collision (same seed or same order with different seed) i suggest calling with fixed seeds that are known to be free of collisions.
There are many cases where tests accidentially depend on one another,
and bats users might want to ensure their test suite does not have this
behaviour. While --jobs gives you some randomness in the execution,
--shuffle allows for deterministic ordering in order to re-test a
particular case (by setting BATS_SHUFFLE_SEED) and also shuffles all
tests entirely.
In order to avoid a dependency on GNU coreutils (for OS X users), we
can't use shuf(1) and instead have to resort to a fairly contorted usage
of paste(1). On the plus side is means we can be sure that the ordering
won't change with new shuf(1) versions.
This is a follow-up of #172.
Signed-off-by: Aleksa Sarai cyphar@cyphar.com