Shell tests
Go to file
David Jones 32b1941d75 0.0.1 2013-06-20 00:08:48 +01:00
tests blah 2012-10-11 15:47:08 -04:00
website@21fbc34f35 web 2012-10-10 21:00:50 -04:00
.gitmodules website submodule 2012-10-08 09:54:07 -04:00
HISTORY todo 2012-10-10 21:00:55 -04:00
LICENCE BSD licence 2012-10-18 09:52:28 +01:00
package.json 0.0.1 2013-06-20 00:08:48 +01:00
readme.md /bin/sh now 2013-06-19 09:20:13 +01:00
urchin Make it a /bin/sh script. For greater good. 2013-06-19 07:46:31 +01:00

readme.md

  ,  ,  ,_     _,  , ,   ___, ,  , 
  |  |  |_)   /    |_|, ' |   |\ | 
 '\__| '| \  '\_  '| |   _|_, |'\| 
`  '  `    `  ' `  '     '  ` 

Urchin is a test framework for shell. It is implemented in portable /bin/sh and should work on GNU/Linux, Mac OS X, and other Unix platforms.

Try it out

Urchin's tests are written in Urchin, so you can run them to see what Urchin is like. Clone the repository

git clone git://github.com/scraperwiki/urchin.git

Run the tests

cd urchin/tests
../urchin .    

Globally

Download Urchin like so (as root)

wget -O /usr/local/bin https://raw.github.com/scraperwiki/urchin/master/urchin
chmod +x /usr/local/bin/urchin

Now you can run it.

urchin <test directory>

Writing tests

Make a root directory for your tests. Inside it, put executable files that exit 0 on success and something else on fail. Non-executable files and hidden files (dotfiles) are ignored, so you can store fixtures right next to your tests. Run urchin from inside the tests directory.

Urchin only cares about the exit status, so you can actually write your tests in any language, not just shell.

More about writing tests

Tests are organized recursively in directories, where the names of the files and directories have special meanings.

tests/
  setup
  setup_dir
  bar/
    setup
    test_that_something_works
    teardown
  baz/
    jack-in-the-box/
      setup
      test_that_something_works
      teardown
    cat-in-the-box/
      fixtures/
        thingy.pdf
      test_thingy
  teardown

Directories are processed in a depth-first order. When a particular directory is processed, setup_dir is run before everything else in the directory, including subdirectories. teardown_dir is run after everything else in the directory.

A directory's setup file, if it exists, is run right before each test file within the particular directory, and the teardown file is run right after.

Files are only run if they are executable, and files beginning with . are ignored. Thus, fixtures and libraries can be included sloppily within the test directory tree. The test passes if the file exits 0; otherwise, it fails.