http://qs321.pair.com?node_id=1194123


in reply to Quieting Test::More

IMHO

I think the real problem is using Test::More as a debugger

I get how easy it is to start using testing modules for everything

I get wanting document every debugging session , every development milestones,

but doing it in one file is bad habit, as is doing it using testing modules , the modularity of your API suffers if there is no separation between testing and development

the solution is smaller and smaller teeny tiny test files, like bug specific rt-666.t bug-frobnitz.t, even if 80%-99% of each test file are identical save for the input/output

but if you're gonna debug learn the API :) https://metacpan.org/pod/Test::More#Diagnostics

Update: Link fixed by GrandFather

  • Comment on Re: Quieting Test::More (purpose, diag)

Replies are listed 'Best First'.
Re^2: Quieting Test::More (purpose, diag)
by stevieb (Canon) on Jul 04, 2017 at 00:19 UTC

    I don't think you are understanding completely what I'm asking/referencing here.

    I do not do many things within a single file. In fact, I have written accepted patches to ExtUtils::MakeMaker documentation that ensures that sub tests and sub directories are understood within the testing framework, to ensure compartmentalized testing is available, and documented.

    I write test files that are specific to a small piece of my software, eg t/05-sub_one.t, t/10-sub_two.t. It doesn't matter if the test file has two or 400 tests in it. I want to know how to shut things up so I can see my print statements only.

    You can verify if we're on the same page here or not by looking here.

    I feel that my APIs flourish by testing them the way I do. I am definitely open to comments in that regard though, if one looks at one of my APIs, then the tests, then responds about them directly.

Re^2: Quieting Test::More (purpose, diag)
by stevieb (Canon) on Jul 04, 2017 at 00:06 UTC
    404 on the link... this message will (hopefully) self-destruct. I would have /msgd, but, anonymonk and all.