From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: More business with $Test::Builder::Level in the TAP tests |
Date: | 2021-10-08 16:14:57 |
Message-ID: | 901355a6-0bd0-b5ad-4bac-94705a966849@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/6/21 9:53 PM, Michael Paquier wrote:
> On Wed, Oct 06, 2021 at 07:33:22AM -0400, Andrew Dunstan wrote:
>> We should probably state a requirement for this somewhere. Maybe in
>> src/test/perl/README. AIUI, the general rule is that any subroutine that
>> directly or indirectly calls ok() and friends should increase the level.
>> Such subroutines that don't increase it should probably contain a
>> comment stating why, so we can know in future that it's not just an
>> oversight.
> That makes sense. How about something like that after the part about
> Test::More::like and qr// in the section about writing tests? Here it
> is:
> +Test::Builder::Level controls how far up in the call stack a test will look
> +at when reporting a failure. This should be incremented by any subroutine
> +calling test routines from Test::More, like ok() or is():
> +
> + local $Test::Builder::Level = $Test::Builder::Level + 1;
I think we need to be more explicit about it, especially w.r.t. indirect
calls. Every subroutine in the call stack below where you want to error
reported as coming from should contain this line.
Suppose we have
sub a { b(); }
sub b { c(); }
sub c { local $Test::Builder::Level = $Test::Builder::Level + 1;
ok(0,"should succeed"); }
AIUI a call to a() will show the call in b() as the error source. If we
want the error source to be the call to a() we need to add that
increment to both b() and a();
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Mikael Kjellström | 2021-10-08 16:55:02 | Re: Time to upgrade buildfarm coverage for some EOL'd OSes? |
Previous Message | Tom Lane | 2021-10-08 16:12:43 | Re: Time to upgrade buildfarm coverage for some EOL'd OSes? |