Add a python testing framework - #792
Conversation
68c5cfb to
f5b9c4a
Compare
b65da90 to
4e9eaf2
Compare
|
This PR is now ready for review. For reference this is an example of the time it takes to run tests now: And before (with #793) it was: |
| * crude. But since this cleanup is only happening in builds with asserts | ||
| * enabled anyway it seems fine. | ||
| */ | ||
| if (cf_pause_mode == P_SUSPEND && cf_shutdown == 2) { |
There was a problem hiding this comment.
This was the only bug that this new testing infrastructure uncovered. It seems that the previous bash tests did not allow many bugs through so far.
|
Impressive! My Debian 11 reported:
Previous tests ~ 2 min 10 secs. One of the things that annoys me was: Maybe you can replace Are you planning to convert the ssl shell scripts to python as well? I noticed that you adjusted the code. I'm still checking but it seems it should be a separate commit. I didn't inspect the tests yet. |
Good to hear that you're seeing the speed improvement locally too. I had similar improvements on my 10c/20t machine (
Good catch! Both my machine and CI don't have multiple disks, so I didn't run into this. I'll make that change.
So I did convert the ssl tests, but I indeed kept the scripts to create the certificates that are used during those tests. I thought they did the job pretty well, and the advantage of shelling out to the openssl command from python vs from bash seemed perytty negligible. I added one small script new bash script, but that's really just a the few first line from the original Honestly this PR already contains many more changes than I normally like in one PR. Normally I'd want to do this in smaller chunks. But I figured that I needed to convert a bunch of tests to prove (also to myself) that the testing framework was designed well. And once I converted more than half of the tests, I thought I might as well convert all. But that's why I'd like to postpone any other changes to some later PR. |
| # This makes tests run faster and we don't care about crash safety | ||
| # of our test data. | ||
| pgconf.write("fsync = false\n") |
There was a problem hiding this comment.
This is new btw, but it changed test runtime from ~33s to ~22s on my machine. And it seemed like a small enough addition to bundle it in here.
|
Bonus points for this python infrastructure. It found this issue in CI and allowed me to easily run the same test with VALGRIND multiple times in parallel by installing |
Testing in bash is very error prone and the tests are hard to review. This is an initial and unfinished attempt at adding a python based testing framework for PgBouncer.
|
I spent an hour on it. I have some cosmetic changes. No code changes. I noticed that |
|
This version looks good to me. Tests look like and if I enable I didn't investigate why I'm getting the referred warning. Old pytest? I noticed that if you enable Cosmetic changes that I mentioned in the last message are below. (I could have asked you to enable editing this PR but I decided to include it here.) |
Doesn't seem super important I'll leave it as is. I created #799 to track the valgrind issue. I applied your cosmetic changes and I updated the comment in pyproject.toml to include some stuff about the warning you are seeing. |


This changes our testing infrastructure to use python instead of bash.
Both
test/test.shandtest/ssl/test.shand have been completelycoverted to python.
The main reason I want to introduce this change is because Bash
is one of the worst languages to write tests in. One of the main goals
of tests is to find unexpected errors. And bash makes it very easy not
to notice such errors. This made it quite hard for me to write correct
tests and review newly introduced tests in PRs for correctness.
Another big reason I want this change is because writing tests
for #666 requires running multiple pgbouncer processes at the
same time. The bash infrastructure did not allow for this. The
new python testing infrastructure.
Finally there's some other advantages that this new test
infrastructure brings:
faster. The duration of the test step in CI is now ~1 minute
for non valgrind runs and ~2 minutes for valgrind runs.
With the bash testing infrastructure these timings were
5.5 minutes and ~8 minutes respectively.
valgrindlocally is now as simple asENABLE_VALGRIND=1 pytest -n autowindows). I made sure almost all are now fully cross platform
(for the platforms we support in CI).
USE_SUDO=1tests are now run in CI on MacOS and FreeBSD.(I confirmed
USE_SUDO=1works with Linux on my local machine,but was unable to get it working in CI due to
iptablesnot beingallowed in the CI containers).
How to run tests can be found in the updated
test/README.mdfile.PS. I haven't tested with OpenBSD, since I don't have access to such a
machine. I'm fairly confident that the tests will run fine though, since
they pass on all CI plaftorms (including MacOS and FreeBSD). But if
anyone else has access to an OpenBSD box, it would be great if you
could test that tests pass there as well.