in reply to Re: STDERR in Test Results
in thread STDERR in Test Results

Why not test for it in that case?

Simply because I didn't know about those Test modules...

Replies are listed 'Best First'.
Re^3: STDERR in Test Results
by hippo (Archbishop) on Jun 19, 2023 at 08:36 UTC

    In that case may I suggest starting with Test::Warn? I find it the simplest of the three (and these are not the only three of course) as it has a very logically straightforward approach. Simply:

    use strict; use warnings; use Test::More tests => 1; use Test::Warn; # Your code which gives an expected warning sub foo { warn "Stripe Webhook Error: Invalid Stripe Signature\n"; } # Test your code warning_is { foo (); } "Stripe Webhook Error: Invalid Stripe Signature +\n", 'Invalid sig warning issued';

    Task::Kensho recommends Test::Warnings which is fine but a little more abstract. Both modules are widely used in other dists. I have found Test::Trap useful on occasion but it can take a bit of wrangling to set up properly.


    🦛

      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.


        🦛

        "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,

        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,

        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();

        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 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");

        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';

        So don't do that. :-)


        🦛