example-shpec

Shpec test drive

Shpec is a quite mature testing framework with it's first release from 2013. Its DSL is looks like a simpler version of shellspec's DSL.

Shpec tries to not implement things that can be done as easily in bash it self.

Test format

There's a specific DSL built into the framework to support BDD style tests:

describe "ice_cream_price.sh (e2e)"
  it "should display 100 for the price of a portion for low quantities"
    assert equal "$(src/ice_cream_price.sh 1)" "Total 100"
  end
end

✔️ What's really interesting is that despite this DSL, files are simple Bash files. It's possible mix simple Bash statements and functions with the DSL, so even if the DSL lacks certain features, it's usually not a limitation.

⚠️ This language looks really neat and extensible, but on the other hand it's something that one have to get used to in order to write tests efficiently.

Test Discovery

✔️ The test runner considers all files as tests that are in the shpec folder and their name ends in _spec.sh. By default all test cases are executed, by calling shpec with a shpec-file as the first parameter, only this case is tested.

✔️ It also expects a specific project structure, test files must be in the schema of ./shpec/**/*_shpec.sh, custom matcher should be in ./shpec/matchers/ every thing else is up to you.

Assertions

✔️ The framework provide many customizable/combinable assertions via it's DSL, and the failures generated by these assertions contain all necessary context information.

Custom assertions

✔️ The DSL itself is extensible with custom matchers.

You can define custom matchers simply as functions, but in order to make them reusable, you have to put them in an extra file under shpec/matchers/.

⚠️ If all else fails Bash functions can be directly called from the tests, and with that custom assertions can be implemented. However it might have the downside that the bashy code has to interface with the DSL, which might be not so convenient, and the test code will be a mix of DSL and bash.

Mocking

✔️ Mocking is possible with all three common techniques:

• alias
• function export
• PATH override

✔️ Also there is stubbing build in.

Activity

⚠️ The project is not in development right now, is seems to be in a "done enough" state.

✔️ The project had quite some releases over the past year. The author is active answering issues and taking care of PRs.

Documentation

✔️ The project test's itself, the tests are not only functional but are written to be good examples. Also, the Readme gives a good overview on how to use and where to read more.