Odd...the failure is due to a violation of unofficial Bash strict mode. Will look a little later.

Ah, now I see it, plain as day (from https://travis-ci.org/bats-core/bats-core/jobs/389756078):

not ok 42 ensure compatibility with unofficial Bash strict mode
[...snip...]
# output:
# bash: //libexec/bats: No such file or directory

This because the test case runs Bats thus:

  run bash -u "${BATS_TEST_DIRNAME%/*}/libexec/bats" \
    "$FIXTURE_ROOT/unofficial_bash_strict_mode.bats"

So ${BATS_TEST_DIRNAME%/*}/libexec/bats resolves to //libexec/bats, when it should resolve to /opt/bats/libexec/bats. (Also, it should be ${BATS_TEST_DIRNAME}/bin/bats. Pushed a commit to #92 for that.)

So I'd suggest the command should be some variation of the following:

docker run -it -v $(pwd):/opt/bats-dev bats:latest /opt/bats-dev/test

Yep, that runs very nicely!

I should add, to be clear: the failure was due to the /test directory being isolated from the rest of Bats. It's reasonable for those file to expect to access files in the same project, so I'd recommend mounting the root of the project in the container, not just the test directory alone.

And actually, I'm beginning to wonder if the extra build step is of any value to our build, given the documented technique in #94. What do you think?

I'd prefer to have the tests runnable in isolation as they're testing the application in the container, but I understand that adding code to do so may be un-intuitive for maintainers.

I've updated the PR to reflect requested changes in #93 (comment)

Just added a comment to your latest update in #93. I think I understand what you're saying now, and suggested more explicit wording.

I re-tested it earlier today and your assertion is correct @mbland. Will get it fixed

I am closing this since we don't use travis anymore. The usecase might still be valid. If so, we should put up an issue for that.