From: | Torsten Zuehlsdorff <mailinglists(at)toco-domains(dot)de> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Thoughts on unit testing? |
Date: | 2017-08-24 07:07:03 |
Message-ID: | be82716d-081c-8b6f-2a04-d22b4e8ae196@toco-domains.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 13.08.2017 21:19, Peter Geoghegan wrote:
> On Thu, Aug 10, 2017 at 2:53 PM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>> The current regression tests, isolation tests and TAP tests are very
>> good (though I admit my experience with TAP is limited), but IMHO we
>> are lacking support for C-level unit testing. Complicated, fiddly
>> things with many states, interactions, edge cases etc can be hard to
>> get full test coverage on from the outside. Consider
>> src/backend/utils/mmgr/freepage.c as a case in point.
>
> It is my understanding that much of the benefit of unit testing comes
> from maintainability.
I never had this understanding. I write tests to test expected behavior
and not the coded one. If possible i separate the persons writing
unit-tests from the ones writing the function itself. Having someone
really read the documentation or translate the expectation into a
test-case, makes sure, the function itself works well.
Also it really safes time in the long run. Subtle changes / bugs can be
caught which unit-tests. Also a simple bug-report can be translated into
a unit-test make sure that the bugfix really works and that no
regression will happen later. I literally saved ones a week of work with
a single unit-test.
There are many other advantages, but to earn them the code need to be
written to be testable. And this is often not the case. Most literature
advises to Mocking, mixins or other techniques, which most times just
translate into "this code is not written testable" or "the technique /
language / concept / etc is not very good in being testable".
Greetings,
Torsten
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2017-08-24 07:12:29 | Re: pgbench: Skipping the creating primary keys after initialization |
Previous Message | Fabien COELHO | 2017-08-24 06:53:10 | Re: proposal: psql command \graw |