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 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 encountered weird errors when trying partial recompilations).
Launching regression tests
I like running tests on a temporary instance that’s created for that purpose only. That’s why I use:
(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
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
Writing regression tests
When you add new features, you need sometimes to add some tests. Regression tests are under
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 the’re good and I add them to the
correct file in
Do you need more ?
If you need more informations, please look at that Postgres documentation.