TDD in shell scripts

So what is the state of the religious war in trying to make *having a bash* more robust with modern patterns? I have written some amazing throw-aways myself over the years, but the TDD approach would tell you that this is now almost always a waste of time, that you will want to do it the right way and reuse what you have invested in, or be able to when you have to against plan.Nonetheless, I went out looking for any wisdom on TDD in the bash world. I found some interesting bits. I have to admit that I have been doing the more complicated stuff in higher level languages, preferably ruby or python. But the shell is still there and needs to be addressed. Build and deploy if nothing else.

Firstly, I would ask people to read through this [set of slides]( and then tell me what shouldn’t be followed in it. Ray Smith has crafted an excellent summary of biblical verse.

If you insist on not using perl, python or ruby for highly complex things, well, you can get some [advanced stuff on bash](, but other than modularization with functions for easier testing, I wouldn’t go overboard.

Some threads on TDD in bash include [this](, [this](, and [this](

This guy has written a bash [mock module]( It might prove useful even by ensuring that you understand what you are dealing with since you have to code the mock response.

This [little gem]( shows a way to set up a continuous integration framework on your scripts with the Ruby [Watchr]( There is also [Guard]( if you need some more sophisticated functionality, like SIG handlers.


Leave a Reply

Your email address will not be published. Required fields are marked *