I've seen it on many places to test shell scripts. For example: in the same bash interpreter source code. See files using the '.right' extenion [0]. I think i

I've seen it on many places to test shell scripts. For example: in the same bash interpreter source code. See files using the '.right' extenion [0]. I think it's a flexible approach, compared to using things as shunit, or TAP producers. The main advantage of using shunit (or TAP producers too), I think is to re-use available tools (at least in the case of TAP producers), and the possible familiarity of new contributors with the syntax. Personally I avoid test libraries that use traps and eval, and bash code can become so complex, that I thing there is not a single testing library (Written in bash) that could work with all my code base. As soon as you start using advanced features (shell options, traps, code tracing features, readonly stuff, filedescriptors, etc) most assumptions become wrong. Anyway, the most hard part of test complex shell programs (specially those related to system administration), is to test functionality. It's easy (and even not useful) to assert that 'myecho 1' will print '1' and return 0. But things become hard to test when you want to see if a partition routine works well with +2TB disks, if a netfilter ruleset is resilient to attacks (unknown by the author), if a program is safe to unexpected (by the programmer) input, if a backup restore will not break production... Fun to see this on hackernews front page. One of my pet projects is just the same, but not being inspired by chef. [0] http://git.savannah.gnu.org/cgit/bash.git/tree/tests http://git.savannah.gnu.org/cgit/bash.git/tree/tests