In that case may I suggest starting with Test::Warn?

I am now getting quite a few fails which are caused by the tester not having Test::Warn installed and it not being a required dependency.

Is it not bad practice to force the user to install a module just for the tests?

It's a good question. I'm a proponent of not making the end user install more than they need so in the general case I would agree.

However, in this particular case we are talking about Test::Warn which at the time of writing this post has 365 direct dependents and 5381 total dependents. In other words, if you were to install any random dist from CPAN there's a decent chance that it will require Test::Warn. For such a widely-used dist I would have few qualms about adding this as a dependency of one of my dists.

The other option, as already outlined by kcott, is to make it optional. List Test::Warn as one of the "recommended" or "suggested" dependencies. Then if it isn't installed and the user doesn't want to install it that's fine but you need the test which uses it to check for this and skip that block if Test::Warn is missing. See for example Exporter::Tiny which recommends Test::Warnings and Test::Fatal and then checks for their presence.

---

🦛

However, in this particular case we are talking about Test::Warn which at the time of writing this post has 365 direct dependents and 5381 total dependents

It seems, quite a few testers don't have Test::Warn installed...

Perhaps they only have core modules on their setup for testing.

"Is it not bad practice to force the user to install a module just for the tests?"

Not necessarily.

In general, I'd expect the user to run `make test` (perhaps via cpan or other, similar utility). My Makefile.PL files typically include:

    'Test::More' => 0,
[download]

Do note that if you're using features from later versions, you should adjust the minimum version accordingly; for instance, if you use done_testing(), you'll need:

    'Test::More' => 0.88,
[download]

The end-user is not expected to run Author Tests. These usually require $ENV{RELEASE_TESTING} (or similar) to have a TRUE value. I don't know what you're using at the moment, but I believe I've seen Test::Pod and Test::Pod::Coverage (maybe others).

My current practice is to list the modules needed for Author Tests in the README file; although, that's a fairly recent thing and I'm still evaluating whether to continue with it. However, I also supply a safety net. Here's one of my test files (specifically for personal use):

$ cat 99-00_pod.t
#!perl

use v5.36;

use Test::More;

BEGIN {
    if (! $ENV{CPAN_AUTHOR_TEST}) {
        plan skip_all => 'Author test: $ENV{CPAN_AUTHOR_TEST} false.';
    }
}

eval {
    use Test::Pod 1.52;
    1;
} or do {
    plan skip_all => 'Test::Pod 1.52 required.';
};

all_pod_files_ok();
[download]

Skipping means that tests don't fail but do report what test module was missing. I only recommend this for Author Tests.

You're welcome to use that. You'd need to make some adjustments around version numbers. Also, I use RELEASE_TESTING for $work; CPAN_AUTHOR_TEST, in my personal code, avoids conflicts.

— Ken

Thanks Ken,

I'm rapidly discovering that there is so much more to testing than I ever imagined!

Thanks for that...Test::Warn looks like just what I need.

Except I cannot get it to work :(

Could it be because I am generating the warnings by printing directly to STDERR like so:

STDERR->print("Stripe Webhook Warning: $message\n");
[download]

Could it be because I am generating the warnings by printing directly to STDERR

Yes:

use strict;
use warnings;

use Test::More tests => 2;
use Test::Warn;

# Your code which gives an expected warning
sub foo {
    warn "Stripe Webhook Error: Invalid Stripe Signature\n";
}

sub bar {
    STDERR->print ("Stripe Webhook Error: Invalid Stripe Signature\n")
+;
}

# Test your code
warning_is { foo (); } "Stripe Webhook Error: Invalid Stripe Signature
+\n",
    'Invalid sig warning issued';
warning_is { bar (); } "Stripe Webhook Error: Invalid Stripe Signature
+\n",
    'Invalid sig STDERR print issued';
[download]

So don't do that. :-)

---

🦛

I came across this very interesting thread which reminded me why I didn't use warn - I don't want line numbers in the warnings from the module!

using warn instead or print STDERR?

The module does have the option to suppress or override warnings. I could use that but wanted to include the error situations in the tests.

So don't do that. :-)

Too late...

I've just sent the latest version off to CPAN to try to deal with the perplexing issue of Test failing during CPAN Testing, which is more urgent than suppressing output to STDERR. That will nave to wait for the next release!