mbland / go-script-bash

95%

master: 95%

LAST BUILD ON BRANCH stub-hash-reset

branch: stub-hash-reset

CHANGE BRANCH

x

Reset

• stub-hash-reset
• appveyor
• bats-helpers
• bats-v1.0.1
• cl-assertions-#181
• cla-#214
• cla-#217
• close-bats-fd-3
• copy-#184
• create-fwd-script-#186
• diff-lib
• fileutil-module-#184
• fix-coverage-kcov-v35
• fix-fileutil-create-dirs-msys2
• forwarding-script
• go-template-download
• issue-template
• master
• mirror-dir-#186
• native-path-#186-#187
• null
• path-lib
• platform-#184
• platform-freebsd
• run-script-helpers
• skip-if-none-present-#186
• skip-template-test
• tarball-#186
• v1.6.0
• v1.7.0
• walk-#184

Build # 690

Build Type

push

travis-ci

Committed by mbland

Commit Message

bats/helpers: Reset executable hash after stubbing

`stub_program_in_path` now calls `hash` on the new stub to ensure it is
discovered instead of the implementation it's intended to replace.
Previously, if `stub_program_in_path` was invoked for a program that
had already been executed by the test, the original program would still
get invoked rather than the stub (unless `hash` was called or `PATH` was
updated elsewhere).

Per the comments from the 'bats-helpers: {stub,restore}_program_in_path
trigger Bash command rehash' test case:

`restore_program_in_path` unconditionally updates `PATH`, which resets
Bash's executable path hash table. I didn't realize this until calling
`stub_program_in_path` on `rm` and finding that the `rm` stub was only
found when it was the first in a series of programs to be stubbed. After
some trial and error, I realized this was because the
`create_bats_test_script` call invokes `rm` and `stub_program_in_path`
only modifies `PATH` on the first call.

This isn't documented in the Bash man page, but once I figured out what
was happening, my hypothesis was confirmed by:
  https://superuser.com/a/1000317

Run Details

1 of 1 new or added line in 1 file covered. (100.0%)

2796 of 2955 relevant lines covered (94.62%)

249.32 hits per line