Re: Better testing coverage and unified coding for plpgsql loops

Tom Lane wrote:

> However, while I was doing that, it seemed like the tests I was adding
> were mighty repetitive, as many of them were just exactly the same thing
> adjusted for a different kind of loop statement. And so I began to wonder
> why it was that we had five copies of the RC_FOO management logic, no two
> quite alike. If we only had *one* copy then it would not seem necessary
> to have such duplicative test cases for it. A bit of hacking later, and
> I had the management logic expressed as a macro, with only one copy for
> all five kinds of loop.

I'm not entirely sure about this rationale. Improving coverage is of
course an important goal, but it's not the only one: each documented
construct and behavior should be tested also explicitly, to avoid any
inadvertant breakage. You're probably the most careful committer in the
project, but what that means is that some other less careful committer
(present or future) will need to hack this code again in the future and
break some of the cases that you've made to work, because the test cases
only exercise the generic behavior through some specific kind of loop,
and not every individual kind of loop specifically.

In other words, I think testing (the basic behavior of) every construct
separately is worthwhile even if it tests the same code several times.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services