suggested invocation too ponderous

[wchristian]

I'm assuming here that the boilerplate suggested in the POD is the optimum combination you found through active use of the module. I'm not 100% sure i grok it right, but i'll assume that 99% of people would want to use it that way. That means i'd want to put your boilerplate in every test script i have. Which means both a lot of code duplication and a lot of copypasting or typing.

There should be some kind of invocation that puts the boilerplate in a single line with considerably fewer letters.

Ideas for this are either specific import options (talking with @ribasushi we didn't find any pleasant names yet) or a wrapper module that does what your boilerplate does.

[ribasushi]

For the record - I find the use of if in the boilerplate as a step backwards, and is something I would discourage when encountered in a project. Personally I am definitely going to use the module in "full-on" mode - it will be reporting diags when failing during normal user-side installs, without any regard for AUTOMATED_TESTING being set or not.

[dagolden]

In my experiments, reporting diags when failing is an enormous amount of clutter when developing, particularly for any large dep chain. Having that on every test is crazy.

Admittedly, my plan is to jam it into the *.t files with dzil, so I never have to write the boilerplate.

That said, given Christian's comments, I'm inclined towards something like this:

use Test::DiagINC;  # defaults to only under AUTOMATED_TESTING
use Test::DiagINC ':author'; # runs under AUTOMATED_TESTING or AUTHOR_TESTING
use Test::DiagINC ':always'; # always runs

That makes my recommended behavior easy, short and without the "if". It allows Peter or others who wish the full frontal %INC dump to opt into two increasing levels of frequency.

Also, consider that the longer term goal per Andreas is to get the dump happening even for passing tests under AUTOMATED_TESTING so that his regression box can more easily find the culprits of failing tests.

Thoughts?

[ribasushi]

I am ok with the above import args. I am sad of the default changing but it is what it is, will have to add :always... always

Regarding your last remark - probably :always is a bit overloaded: "always run (in terms of environment)" or "always report (in terms of fail/pass)"?

You likely will end up wanting:
:smoker (default), :author, :<something> and :on_fail (default), :<something>
Having a foggy day, can't come up with sane alternative terms.

[dagolden]

The more I think about it, I think it's too soon to decide on these use cases. Thing might change if #1 gets figured out.

I'm going to leave this open as a reminder

[wchristian]

Just a small note that i didn't make clear enough, i think. When i mention the boilerplate i meant all of it, including the T::M invocation. In other words: I think DiagINC should also load Test::More, so it doesn't need to be mentioned specifically. Due to how often DiagINC would be used, i think that's a fair shortcut to take.

[dagolden]

Ah! That's not going to happen. If someone wants to include it into Test::Most or if people want to role their own testing bundles like that, that's fine with me. But this single-purpose tool (which works even without Test::Builder) is not going to also become a bundler of other test modules.

[wchristian]

It's not particularly single-purpose if it's in every test script. It is in
fact more like a pragma than, for example, Test::Fatal. That said, it'd be
fine if the dist included a separately named module to activate Test::More
together with DiagINC, or have it be an import option (as long as it's
actually less verbose).

On 8 February 2014 13:55, David Golden [email protected] wrote:

Ah! That's not going to happen. If someone wants to include it into
Test::Most or if people want to role their own testing bundles like that,
that's fine with me. But this single-purpose tool (which works even without
Test::Builder) is not going to also become a bundler of other test modules.

Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-34543333
.

[ribasushi]

Fwiw I do not see any harm in shipping a Test::More::DiagINC in the distribution, with the obvious behavior.