Install/Setup Directions?

[noncreature0714]

This is related to documentation. I'm guessing this is obvious to everyone who uses shunit2, but how do I setup shunit2 in a project for use? Do I clone it? Curl it?

[github-pawo]

Copy shunit2 script in your test folder and try the example in the quickstart section -> https://github.com/kward/shunit2#-quickstart

[EvgeniGordeev]

The easiest solution for this issue is to place shunit2 to Release assets so that no one has to deal with git clone and provide the install command like (assuming the next version is 2.1.8):

curl -L https://github.com/kward/shunit2/releases/download/2.1.8/shunit2 -o /usr/local/bin/shunit2
chmod +x /usr/local/bin/shunit2

Then the quickstart example can be transformed into:

#! /bin/sh
# file: examples/equality_test.sh

testEquality() {
  assertEquals 1 1
}

# Load shUnit2.
source shunit2

[sirosen]

I found this difficult/confusing as well, and opened a duplicate (sorry! closed now: #128 ). But there are some things in there I don't want lost:

1. Install instructions should cover including shunit2 in-tree

I want to write a testsuite and then provide my coworkers with instructions to run it. I'd like to give them the testsuite with the version of shunit2 which it uses. I think this is a reasonable/common usage -- in modern languages, I'd provide a package spec of some kind which specifies the version of a testing package to use. The only way to do that here is to include it in-tree.

2. Example scripts only source shunit2, but you can also invoke shunit2 on a test script

I'm not clear on what the difference in behavior is. Any guidance? Is one preferred?

3. Test file discovery and writing a custom test runner is non obvious

If you're using shunit2, it's probably because you want to write a large number of tests, and maintenance will be easier if you keep them organized by subject/type/etc in separate files. But... how do you do that? As far as I can tell, you have to write a wrapper script that does whatever discovery you want for test files, and invokes them correctly. Is that correct? Are there best practices? What's a good minimal test runner?

a small test runner, as an example

Is this good? Bad? Do other people have ways they prefer to do it?

#!/bin/bash
cd "$(dirname "$0")"
runsuite() {
  echo -e "\n-- Running suite: $1 --"
  bash ./lib/shunit2 "$1"
}
main() {
  if [ $# -gt 0 ]; then
    bash ./lib/shunit2 "$@"
  else
    for f in ./suites/*_test.sh; do
      runsuite "$f"
    done
  fi
}
main "$@"

[codingjoe]

Here, this simple setup should help people to get started in a blink:

#!/usr/bin/env bash

# … your tests

command -v shunit2 || {
  curl -sLo /usr/local/bin/shunit2 https://raw.githubusercontent.com/kward/shunit2/master/shunit2
  chmod +x /usr/local/bin/shunit2
}
source shunit2

[davidkhala]

curl -sLo /usr/local/bin/shunit2 https://raw.githubusercontent.com/kward/shunit2/master/shunit2
  chmod +x /usr/local/bin/shunit2

For people add this snippet but seeing error like

chmod: cannot access '/usr/local/bin/shunit2': No such file or directory add sudo before curl

[codingjoe]

@davidkhala good point, I tested this on docker without sudo. Of course, we could simply install shunit2 is an unprivileged location or simply download it into /tmp and source it from there.

[Peter-Malcolm]

Still having some issues getting this to install reliably.

• The releases here https://github.com/kward/shunit2/releases
  only contain a tar.gz or zip containing the full source rather than just the relevant binary

• apt-get only hosts version 2.1.6 as far as I can tell.

• I can't find a way of getting the version reliably from the shunit2 itself. shunit2 -v and shunit2 --version don't do what I would expect. ( nor do shunit2 -h or shunit2 --help )

• Is shunit2 safe to install reliably using? curl -L https://raw.githubusercontent.com/kward/shunit2/master/shunit2 If the main script has any dependencies on any other files in the repo presumably this will break, probably nastily? Also you're tracking the master branch so if/when v3 comes out your code may break.

• the curl based approaches above don't include --fail flag so may result in writing a file with "Not Found"

For stability, I'm inclined to suggest a git clone + chmod based approach: git clone --branch v2.1.8 https://github.com/kward/shunit2 chmod +x shunit2/shunit2 ln -s "$(realpath shunit2/shunit2)" tests/shunit2

Not sure if anyone has a better suggestion?

[opsb]

There's a brew package available now

$ brew install shunit2