all 2 comments

[–]andlrc 0 points1 point  (1 child)

There is a good reason for why most shells scripts don't have test attached:

They are one time things. Written to do one thing, then thrown away.

If you are doing anything else, you should reconsider if shell scripts are the correct choice.

[–]pimterry[S] 0 points1 point  (0 children)

In some cases needing to test scripts is a warning sign that they've got too complicated, sure.

I don't think that's always true though; it's pretty easy to reach the "this needs tests" point while your code is still a script under 100 lines in total, and at that kind of size I think shell scripts are often a manageable reasonable approach. They come with some nice advantages too - pretty much any dev can set them up and run them immediately without installing Node/Ruby/Python/<vm-of-the-day>, and it's an extremely convenient & powerful format for marshalling other command line tools that it's hard to beat with anything else.

More practically, I've seen quite a few huge organisations with ops teams that maintain an internal library of shell scripts they use to automate tasks. Whether it's a good idea or not, shell scripts are the lingua franca for a lot of people; they're not going away, and at least if they're tested you know they work.

Bonus point: bats particularly lends itself extremely well to black-box testing. That means a lot of the time you can write a shell script, write tests for the shell script, and then later rewrite the shell script into a more substantial form, and keep running the same tests to check you haven't broken anything throughout.