[anko]

One of my pet peeves about shell scripts (speaking as a former UNIX admin) is the lack of static typing or test frameworks. So not only is the language less elegant than modern programming languages, but it's harder to test for bugs and you don't even get type safety.

[oweiler]

I'm currently in the process of putting together a first version of bash-specs, a Bash testing framework which provides features found in other languages' test frameworks, like

- a DSL for describing specifications

- the ability to mock functions and commands

- detailed, human-readable output

You can find some sample-tests in the spec/ folder (bash-specs eats its own dog food by testing itself ;)).

Dokumentation is lacking and the mocking is currently broken but both will be fixed within the next days.

https://github.com/helpermethod/bash-specs/

[mbrock]

Testing might be less of a common practice for quick shell scripts, but it can be done and there's nothing particularly difficult about it, compared to other languages. Especially with "pure" scripts that don't revolve around system effects... which is the case with other scripting languages too.

As for static typing, agreed, though considering that shell is basically a scriptable FFI, real static typing would probably add a lot of complexity? Attempts at "typed shell" don't seem to go over well, maybe due to "worse is better" dynamics.

BTW, re: testing shell scripts: https://github.com/sstephenson/bats

[rakoo]

The creator of bup (https://github.com/bup/bup/) also created wvtest (https://github.com/apenwarr/wvtest) to "unit test" any code in any combination of language on any platform. It's actually kind of cheating: all you do in your code is write lines with a specific format, and then the wvthing parses that to display stats.