Running Tests
| The test suite for performing regression tests is distributed with the source code of PostgreSQL and can be found in the src/test/regress directory in the source tree of PostgreSQL. To start the regression test you use the following command: [hs@athlon regress]$ make check PostgreSQL performs a lot of checks and testing. Although a lot of work is done by the test, it takes only a few seconds to complete. Let's have a look at the test in detail and see what is done by make check -n : [hs@athlon regress]$ make check -n make -C ../../../contrib/spi REFINT_VERBOSE=1 refint.so autoinc.so make[1]: Entering directory `/usr/src/redhat/SOURCES/postgresql-7.1.2/contrib/spi' make[1]: `refint.so' is up to date. make[1]: `autoinc.so' is up to date. make[1]: Leaving directory `/usr/src/redhat/SOURCES/postgresql-7.1.2/contrib/spi' /bin/sh ./pg_regress --temp-install --top-builddir=../../.. -- schedule=./parallel_schedule --multibyte=SQL_ASCII A script called pg_regress is started with various parameters. You'll take a closer look at pg_regress later in this section. To execute the test, a temporary server is started. Make sure that the test is not executed as root , because the PostgreSQL daemon must not be started as root . After executing the regression test, we get the following messages from the test suite: make -C ../../../contrib/spi REFINT_VERBOSE=1 refint.so autoinc.so make[1]: Entering directory `/usr/src/redhat/SOURCES/postgresql-7.1.2/contrib/spi' make[1]: `refint.so' is up to date. make[1]: `autoinc.so' is up to date. make[1]: Leaving directory `/usr/src/redhat/SOURCES/postgresql-7.1.2/contrib/spi' /bin/sh ./pg_regress --temp-install --top-builddir=../../.. -- schedule=./parallel_schedule --multibyte=SQL_ASCII ============== removing existing temp installation ============== ============== creating temporary installation ============== ============== initializing database system ============== ============== starting postmaster ============== running on port 65432 with pid 29536 ============== creating database "regression" ============== CREATE DATABASE ============== installing PL/pgSQL ============== ============== running regression test queries ============== parallel group (13 tests): name boolean char int2 varchar text float4 float8 oid int8 int4 bit numeric boolean ... ok char ... ok name ... ok varchar ... ok text ... ok int2 ... ok int4 ... ok int8 ... ok oid ... ok float4 ... ok float8 ... ok bit ... ok numeric ... ok test strings ... ok test numerology ... ok parallel group (18 tests): lseg point path date circle polygon interval comments inet tinterval time abstime reltime box timestamp type_sanity oidjoins opr_sanity point ... ok lseg ... ok box ... ok path ... ok polygon ... ok circle ... ok date ... ok time ... ok timestamp ... ok interval ... ok abstime ... FAILED reltime ... ok tinterval ... ok inet ... ok comments ... ok oidjoins ... ok type_sanity ... ok opr_sanity ... ok test geometry ... ok test horology ... ok test create_function_1 ... ok test create_type ... ok test create_table ... ok test create_function_2 ... ok test copy ... ok parallel group (7 tests): create_aggregate create_operator inherit triggers constraints create_misc create_index constraints ... ok triggers ... ok create_misc ... ok create_aggregate ... ok create_operator ... ok create_index ... ok inherit ... ok test create_view ... ok test sanity_check ... ok test errors ... ok test select ... ok parallel group (16 tests): select_distinct_on select_into select_distinct subselect select_implicit union transactions random select_having arrays join case portals hash_index aggregates btree_index select_into ... ok select_distinct ... ok select_distinct_on ... ok select_implicit ... ok select_having ... ok subselect ... ok union ... ok case ... ok join ... ok aggregates ... ok transactions ... ok random ... ok portals ... ok arrays ... ok btree_index ... ok hash_index ... ok test misc ... ok parallel group (5 tests): portals_p2 alter_table foreign_key rules select_views select_views ... ok alter_table ... ok portals_p2 ... ok rules ... ok foreign_key ... ok parallel group (3 tests): limit temp plpgsql limit ... ok plpgsql ... ok temp ... ok ============== shutting down postmaster ============== ======================= 1 of 76 tests failed. ======================= The differences that caused some tests to fail can be viewed in the file `./regression.diffs'. A copy of the test summary that you see above is saved in the file `./regression.out'. make: *** [check] Error 1 As you can see in the following code, pg_regress has a lot of parameters that you can use to perform the regression test without using the Makefile: [hs@athlon regress]$ ./pg_regress help PostgreSQL regression test driver Usage: pg_regress [options...] [extra tests...] Options: --debug turn on debug mode in programs that are run --inputdir=DIR take input files from DIR (default `.') --multibyte=ENCODING use ENCODING as the multibyte encoding, and also run a test by the same name --outputdir=DIR place output files in DIR (default `.') --schedule=FILE use test ordering schedule from FILE (may be used multiple times to concatenate) --temp-install[=DIR] create a temporary installation (in DIR) Options for `temp-install' mode: --top-builddir=DIR (relative) path to top level build directory Options for using an existing installation: --host=HOST use postmaster running on HOST --port=PORT use postmaster running at PORT --user=USER connect as USER The exit status is 0 if all tests passed, 1 if some tests failed, and 2 if the tests could not be run for some reason. Report bugs to <pgsql-bugs@postgresql.org>. You can see the test suite performs a huge number of tests, but not all of them are always successful, although we have installed PostgreSQL properly and our test system (Red Hat Linux release 7.1 with kernel 2.4.2-SGI_XFS_1.0 on AMD Duron) is capable of running PostgreSQL without any problems. You take a closer look at test evaluation in the next section. First, let's look inside a regression test. The first step is to create a PL/pgSQL-enabled database and test the basic datatypes. The following code performs a regression test for the datatype text : -- -- TEXT -- SELECT text 'this is a text string' = text 'this is a text string' AS true; SELECT text 'this is a text string' = text 'this is a text strin' AS false; CREATE TABLE TEXT_TBL (f1 text); INSERT INTO TEXT_TBL VALUES ('doh!'); INSERT INTO TEXT_TBL VALUES ('hi de ho neighbor'); SELECT '' AS two, * FROM TEXT_TBL; You can see that the heart of a regression test is a set of SQL commands. In this case, the test is simple and easy to understand, but there are also tests containing a lot more SQL code, such as the following test suite for rules : [hs@athlon sql]$ ls -l rules.sql -rw-r--r-- 1 hs cybertec 24967 Dez 5 2000 rules.sql After checking the rudimentary datatypes implemented in PostgreSQL, the more complex datatypes, such as lseg and timestamp , are tested. The test suite executes an SQL file for every datatype tested and stores the results in files. Now that all datatypes have been checked extensively, PostgreSQL checks things such as triggers, aggregates, transactions, and PL/pgSQL. Note that if a test fails, as you saw in the previous regression test, the test suite does not stop working. All the SQL code needed for the test can be found in the src/test/regress/sql directory in the source tree of PostgreSQL. Feel free to go through the SQL code, because it is a perfect compilation of examples and might save you a lot of time with more complex tasks . |
