Re: [HACKERS] Thoughts on unit testing?
| От | Chris Travers |
|---|---|
| Тема | Re: [HACKERS] Thoughts on unit testing? |
| Дата | |
| Msg-id | CAN-RpxABzgQxEYCPbpzzNm5Ys_w92kLGFRYAf+4HsuQc+YQN4g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Thoughts on unit testing? (Torsten Zuehlsdorff <mailinglists@toco-domains.de>) |
| Список | pgsql-hackers |
On Thu, Aug 24, 2017 at 9:07 AM, Torsten Zuehlsdorff <mailinglists@toco-domains.de> wrote:
On 13.08.2017 21:19, Peter Geoghegan wrote:On Thu, Aug 10, 2017 at 2:53 PM, Thomas Munro
<thomas.munro@enterprisedb.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.
I don't want to see full test coverage of the code btw. I think that undermines the benefit from testing.
I would like to see better test coverage though for reasons below.
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.
Right. I would go so far as to say I test to the documentation, not to the code. Usually when I test my own code, I write docs, then code, then I re-read the docs, and write test cases from the docs.
In my not-so humble opinion, the point of tests is to make sure you don't break other people's stuff, people who are reading the docs and using them when they write their code.
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.
Also comparing to the docs means we have a way to reason about where misbehaviour is occurring that means better maintainability and less code entropy in the course of fixing bugs.
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".
Agreed here. Usually you end up with better, more stable, more carefully designed components as a result. But as I say, documentation, design, and testing are actually harder to get right than coding....
So with the above being said, the fact is that a lot of advanced stuff can be done by writing C libraries that get preloaded into PostgreSQL. These C libraries risk being broken by cases where behaviour does not match documentation. So if I want to translate an oid into a db name or vice versa, I might call the internal functions to do this. Having a stable C API would be of great help in ensuring longer-term maintainability of such libraries. So I think it would be good to add some unit tests here.
Of course it also means we get to decide what functionality is sufficiently stable to test and guarantee, and that saves both time in maintenance, and it improves the safety of moving forward.
But I still think the question of what to test ought to be geared around "what are we willing to try to guarantee as behaviour for some years, not just to ourselves but to third parties."
Greetings,
Torsten
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Best Regards,
Chris Travers
Database Administrator
Saarbrücker Straße 37a, 10405 Berlin
В списке pgsql-hackers по дате отправления:
Предыдущее
От: David RowleyДата:
Сообщение: Re: [HACKERS] CONNECTION LIMIT and Parallel Query don't play well together