Advanced Concepts

Let's have a look at:
  • Test Doubling
  • Code Coverage
  • Naming Conventions

Test Doubling

For a very detailed explanation read Mocks Aren't Stubs.

Obviously in shell scripts we will not use objects in the traditional sense of OOP, but still implementing mock or fake values will go a long way for tests that can go deep in the code, without making changes in live systems.
In this example the "some_command" executable will read the fake file and export the string "expected" into $ENVIRONMENT_VARIABLE, which is what we test. 

testCommandWithFile() {
  . some_command /testdirectory/mock/FAKE_FILE >/dev/null 2>&1
  assertEquals "expected" "$ENVIRONMENT_VALUE"
  return 0
}
Using mock data allows to perform unit tests, so we can be sure that the code works as expected.
This is important as with integration tests, there can always be uncertainties as to the interface availability or even changes in the data format.
Of course it also means, that if any data format has relevant changes, we need to update the mock data.
For an example how to loop through several lines and perform the same test look at "examples/mailcheck/email_validity.test".

Code Coverage

The base assumption here is, that with a high coverage of your code with tests, you can be sure that it will work as intended.

As such this assumption is wrong, as of course the quality of the tests dictates how many real errors will be caught early on.

For more details see Code Coverage on Wikipedia.

There are several tools available,
known to work with shunit2 are bashcov and kcov.

Naming Conventions

Even though a variable name could be conceived as just an arbitrary placeholder and using anything like A, B, C, V1, V2 or I-have-data is just fine it becomes much more useful when used as a mnemonic value.

This means a coder or a team will reflect certain logical elements within variable names and will opt for a certain writing style.

For a great overview of different naming convention styles see https://devopedia.org/naming-conventions.

Some key points about naming conventions:
  • Never underestimate the time that is saved by improved readability!
  • When working on a defined product or within a team, you should have them.
  • It is fine to refine the usage via tribal knowledge e.g. within code reviews.
  • Bad naming conventions can ruin your mood!