Why, for the love of Notch, do people keep porting everything that you're supposed to be doing in a real programming language to Bash? Yes, it's Turing complete, but the syntax is ugly and inconsistent, there is just about no support for data structures, and you have to fork a process to do practically anything!
Bats isn't a port of anything, and sometimes Bash is the right tool for the job.
I maintain two other projects written in Bash (rbenv and ruby-build). I looked, and couldn't find any suitable testing tools for Bash, so I created Bats.
My criteria for deciding what to work on in the open-source world is: do I need something that doesn't yet exist, or something whose existing implementations are unsuitable? If yes, I try to fill the void as best I can, and package it up nicely so others can use it too.
I could see this being very useful for testing little scripts and even small c command line applications i have written.
In the case of the small command line applications this is probably the ideal way to test them. Obviously if the application is even remotely complex you will want unit tests too which probably should be implemented in the language (so you can test your procedures directly) but there is a case for integration tests as well.
If you structure your program in a certain way, there's no need to distinguish between procedures and commands. See git and rbenv, which expose a single meta-command to your $PATH but are comprised internally of many smaller commands that invoke each other and communicate over standard I/O.
Comments
Why, for the love of Notch, do people keep porting everything that you're supposed to be doing in a real programming language to Bash? Yes, it's Turing complete, but the syntax is ugly and inconsistent, there is just about no support for data structures, and you have to fork a process to do practically anything!
Bats isn't a port of anything, and sometimes Bash is the right tool for the job.
I maintain two other projects written in Bash (rbenv and ruby-build). I looked, and couldn't find any suitable testing tools for Bash, so I created Bats.
My criteria for deciding what to work on in the open-source world is: do I need something that doesn't yet exist, or something whose existing implementations are unsuitable? If yes, I try to fill the void as best I can, and package it up nicely so others can use it too.
FWIW here's a vaguely doctest-like tool I wrote: https://github.com/darius/tush
May be unsuitable for you, as you say -- it looks like it takes less typing/punctuation to write the example tests, though.
Wow, I really like the literate style. Great stuff.
Thanks!
Another test framework written in (pure) shell is Sharness: http://git.io/sharness
It was derived from the Git test harness. I'm already using it for a couple of my projects.
I could see this being very useful for testing little scripts and even small c command line applications i have written.
In the case of the small command line applications this is probably the ideal way to test them. Obviously if the application is even remotely complex you will want unit tests too which probably should be implemented in the language (so you can test your procedures directly) but there is a case for integration tests as well.
If you structure your program in a certain way, there's no need to distinguish between procedures and commands. See git and rbenv, which expose a single meta-command to your $PATH but are comprised internally of many smaller commands that invoke each other and communicate over standard I/O.
This is also known as the UNIX philosophy :)
I doubt that all of git commit is implemented in main. So I'm sure that there is still plenty of use for unit tests.
As a matter of fact, all automated tests of the Git project are powered by a shell-based TAP harness, which tests executable commands only.
To be fair, there are some dedicated C tools driving unit tests via CLI, but most of the tests are based on the final plumbing and porcelain commands.