develooper Front page | perl.perl5.porters | Postings from January 2022

Re: Broken stack traces from use statements.

Thread Previous | Thread Next
January 16, 2022 06:59
Re: Broken stack traces from use statements.
Message ID:
On Sat, 15 Jan 2022 at 20:20, Martijn Lievaart <> wrote:

> On 1/15/22 19:01, Karen Etheridge wrote:
> On Fri, Jan 14, 2022 at 10:06 PM demerphq <> wrote:
>> Thanks, although I feel it is worth noting that this was not a fix to
>> DBIx::Class and the patch never broke DBIx::Class, it was the tests for
>> DBIx::Class that were broken only.
> I don't think that's very fair to say. The tests are verifying behaviour
> expected by the runtime code, and there is a reason why they are written
> the way they are. Otherwise, any broken test could be "fixed" by simply
> removing the test altogether. We've all worked with junior programmers who
> want to do that, and we've all rightfully scolded them for it.
> Part of fixing the test is understanding why it was written the way it
> was, and what runtime behaviour is associated with that test. Changing a
> test's expected result means that runtime behaviour is also changing, and
> other things might need to be addressed there as a result.
> On the other hand, it could be that this test isn't testing anything
> useful at all, but I don't think that's been established here.
> Or the test tests something useful, works around bugs to do so, and when
> those bugs get fixed, the test starts failing. It looks like that is the
> case here.
That doesn't change the fact that the *test* was broken by this change, NOT
the code it was testing. Fixing the test to pass under the caller() fix did
not require modifying anything but the test code, and as such I feel
entirely entirely to say that the *test* was broken, not the code.


perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About