Testing#

Before getting into to the details there’s a popular myth which needs dispelling: that testing shell scripts is basically pointless. I suspect this is an unfortunate side–effect of the most common style of shell script: a bunch of commands with many responsibilities and side–effects. As a community, developers moved away from that many years ago in most programming except shell scripting. One reason for this is probably that shell scripts can be difficult to handle as a unit when split up — a set of shell scripts are much less of a unit than a set of Java classes or even a Python package. But by splitting up scripts we can make them much easier to test. We just need to make sure they stay together into production, so that they still work as a unit.

Another common myth is that testing is an all–or–nothing proposition. Instead, every test should improve the project a little bit, allowing the long–term quality and speed of development to become good enough and stay good enough.

Probably the highest value testing to get started with is a simple side–effect–free transformation. Code without side–effects is easy to test, because it doesn’t matter in which order the tests run. They can even run in parallel, which is really helpful once your test run times crawl up over the one second mark. A lot of shell scripts are written so that almost every line has side–effects, but usually those side–effects can be isolated so that the remaining code can be tested easily. And transformations are really common in shell scripts.

Let’s start with a typical example: your application stores database connection information in a JSON configuration file. You want to write a backup script, and have decided that doing this as Bash is easiest for now. But the database client takes this configuration as command line arguments, so you need to transform it. You might already be thinking about something like database_client $(grep --regexp=… config.json | sed --expression=…) STATEMENT – let’s see how you might test that transformation.

config.json:

{

  "username": "user",

  "password": "pass"

}

We want our new script to print “user” followed by “pass”, each NUL–terminated:

#!/usr/bin/env bash

script_directory="$(dirname "${BASH_SOURCE[0]}")"

test_should_print_username_and_password_nul_separated() {

    configuration='{

  "username": "user",

  "password": "pass"

}'

    mapfile -d '' result < <(

        "${script_directory}/config-transformer.bash" <<< "$configuration"

    )

    assertEquals 'user' "${result[0]}"

    assertEquals 'pass' "${result[1]}"

    true

}

# shellcheck source=shunit2

. "${script_directory}/shunit2"

shunit2 is probably the leading framework for testing shell scripts. It is focused on portability, so if you do need to write portable shell scripts it is a good choice for testing all of them with the same script. Unlike ordinary scripts we should not set -o errexit etc. in test scripts, because these options would interfere with the way shunit2 works.