Starling Software K.K Language:

PGtools Unit Test Demonstration

Here’s how you can set yourself up to run the unit tests included in the example application that comes with pgtools. If you download and extract the archive, you’ll find that the example application is located in the example-app/pgsql/exampledb1 directory. To try out the tests, do the following.


First, make sure you’re using some flavour of Unix. Unless, of course, you’re an experienced Windows and Cygwin hacker, and feeling brave.

Second, ensure that you have PostgreSQL 8.0 or later installed on your system. You can try this with a 7.x PostgreSQL (this whole system was originally developed under 7.2), but it’s not been tested with that for a long time.

Third, make sure that when you type “psql” at the command line prompt you are logged in, without having to type a password, to a database to which you have write access. Setting the various PG* environment variables and adding a line to the $HOME/.pgpass file can help with this. (See the psql manual page for more details.)

Running Tests

Run the example-app/pgsql/exampledb1/Test shell script. (You can run this from any current working directory; the script will find out its own location and knows where everything else lives relative to it.) Don’t worry about stomping on any of your data; the test system uses its own namespaces (schemas, in SQL lingo) to avoid colliding with anything already in your database. Since this schema is named exampledb1, the namespace will be named unit_test_exampledb1.

If everything passes, you should see something similar to this:

    $ ./example-app/pgsql/exampledb1/Test
    Testing /u/cjs/co/starling/pgtools/example-app/pgsql/exampledb1
    Loading schema into unit_test_exampledb1
    === test/error_test.sql
    === test/get_credit_card.sql
    === test/get_person.sql
    === test/time_based_test.sql
    All tests passed.

One error that you may see, depending on what versions of PGTools and PostgreSQL you’re using, is due to a change in the error messages printed by PostgreSQL. It looks something like this:

    $ ./example-app/pgsql/exampledb1/Test
    ***** pg-functions
    ***** pg-load-schema
    ***** example-app
    --- test/error_test.errors      2006-01-26 16:25:17.000000000 +0900
    +++ /tmp/dbunittest.out.13451.err       2007-07-31 01:31:55.000000000 +0900
    @@ -1,3 +1,3 @@
    -ERROR:  syntax error at or near "error" at character 11
    +ERROR:  syntax error at or near "error"
    LINE 1: SELECT an error;

The error output is in unidiff format; the framework in fact uses “diff -u” to compare the expected and actual output. In this particular case, what this says is that the test expected to see “ERROR: syntax error at or near “error” at character 11”, but didn’t (thus the minus sign at the beginning of the line), and it did not expect to see “ERROR: syntax error at or near “error”” (without the “at character 11” at the end) but did (thus the plus sign at the beginning of the line). The next two lines are context of the output where the error occurred.

If you run into this problem, simply edit example-app/pgsql/exampledb1/test/error_test.errors to match what your version of PostgreSQL prints.

If you didn’t run into the problem, try changing that file anyway to break the tests and see what happens. Play with other tests to break them and see what happens. Try adding new ones, perhaps simple ones that test built-in PostgreSQL functionality and functions.


If you have any problems running this, do feel free to contact us

Back to pgtools Logo