Is there an easier way to stub a specific command or script with this `bats-mock`?

[dragon788]

I love the syntax of your implementation and it makes a lot of sense to me that the mock is a test double/spy that watches all the invocations and allows you to assert that it was called in specific ways, without necessarily having to write out an assertion for every single call.

While trolling StackOverflow and related sites I came across a question about mocking a script and checking the calls using bats-mock, but they were using the other version and it doesn't make it quite as easy to assert mock_called_with_args or similar, so I wrote up an answer with an example using your bats-mock, but I was having trouble emulating the stub behavior of actually shadowing/preempting a binary in the PATH so that the ${mock} definition was called instead. https://stackoverflow.com/q/38315185/3794873

I eventually came up with a hacky method by doing the mock creation in the setup() method or in each test and then by making a symlink to the mock's file path in the same directory and prepending that directory to the PATH variable and then unlinking and stripping the location back out of the PATH in the teardown or the end of the test. Is there a cleaner way to do this without repeating the code across all of the tests and in such a way that it allows for one or more binaries to be stubbed, in the case you want to avoid any external resources being accessed and you could stub success for the list?

Perhaps this is something that could be added to this better maintained version of bats-mock? Maybe something like mock_set_command_stub_name.

[dragon788]

Upon reflecting on this I also realized that you need to use an additional $(create_mock) call for each binary you want to stub, otherwise you won't be tracking the right number of calls and args, so making a helper function like what jasonkarns/bats-mock uses for stub is probably the way to go.

[grayhemp]

@dragon788 thanks very much for your feedback. I was thinking about possibilities of mocking executables by their real names myself. And yes, symlink-ing + PATH manipulations occurred to me as well. However, the issue with this approach is that the executable can be specified with a path component (like /usr/local/bin/psql) in the script and so the idea breaks here. Not speaking about possible PATH manipulations by the script itself.

I have a hint of idea of solving that by chroot-ing into a disposable tree and doing unsafe things there but nothing is clear here yet, so I'm not sure if it's going to be the solution or there will be something else. I was a little bit hesitant about this enhancement, but after your message I started seeing a clear demand in it, so I scheduled work on it in terms of v2.0.

[dragon788]

Was interesting checking the implementation of stub.sh after discovering it in the question referenced above. https://github.com/jimeh/stub.sh/blob/master/stub.sh Haven't fully digested whether it can handle full paths and still stub the binary or not.

[grayhemp]

@dragon788 interesting tool, thank you. However, I'm a little bit afraid of stub/restore approaches. From my previous experience it's an easy way to shoot oneself in the foot.

[dragon788]

I definitely think your idea of doing it in a chroot is the safest route, that way it can be destroyed between tests to prevent side effects and can't alter the host and cause any issues.

[pszalko]

I just found this bat-mock tool and it looks very promising for unit testing bash code. I wonder if there is any progress with this issue?

[grayhemp]

@pszalko unfortunately it appeared to be harder that though and I just don't have enough time currently to address it properly. However, I would highly appreciate any PRs and/or ideas.