When you (or someone else) add new features to Postgres, we need to be sure we didn’t break anything… That’s where regression tests are quite handy.

Preparing your environment

The best thing to do before testing a patch (and so before applying it) is to fetch the last version of master.

git checkout master
git pull --rebase

Then you can apply your patch (as indicated in that article):

git checkout -b testing_my_awesome_patch
patch -p1 < my_awesome_patch_path

You’ll need to recompile PostgreSQL (and you might want to make a full recompile in that case, because you might encounter weird errors when trying partial recompilations).

make clean

Launching regression tests

I like running tests on a temporary instance that’s created for that purpose only. That’s why I use:

make check

(First time after a make clean can be slow.)

If you have something like

=======================
 All 186 tests passed.
=======================

It means it’s goods :-).

If not, you’ll find a file called postgresql/src/test/regress/regression.diffs that will help you find what’s different between the output and the expected result. You’ll find a copy of your standard output for these tests in postgresql/src/test/regress/regression.out.

Writing regression tests

When you add new features, you need sometimes to add some tests. Regression tests are under the src/test/regress directory.

When you add some tests, you’ll need to provide the expected results. I haven’t found something less effective than running the tests once and look at the diff file. Then I inspect my results to be sure they’re good and I add them to the correct file in src/test/regress/expected/.

Do you need more?

If you need more information, please look at that Postgres documentation.