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.)
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
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; ^ FAILED $
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