R – How should I promote Perl warnings to fatal errors during development

continuous integrationperlunit testingwarnings

When running an applications test suite I want to promote all Perl compile and run-time warnings (eg the "Uninitialized variable" warning) to fatal errors so that I and the other developers investigate and fix the code generating the warning. But I only want to do this during development and CI testing. In production, the warnings should just stay as warnings.

I tried the following: In "t/lib" I created a module TestHelper.pm:

# TestHelper.pm
use warnings FATAL => qw( all );
1;

Then called the test suite like this:

$ PERL5LIB=$PERL5LIB:./t/lib PERL5OPT=-MTestHelper.pm prove -l t/*.t

But this did not have the desired effect of promoting all warnings to fatal errors. I got the warnings as normal but the warnings did not appear to be treated as fatal. Note that all my test.t scripts have the line "use warnings;" in them — perhaps this over-rides the one in TestHelper.pm because "use warnings" has a local scope?

Instead I've done this:

# TestHelper.pm
# Promote all warnings to fatal 
$SIG{__WARN__} = sub { die @_; };
1;

This works but has a code smell about it. I also don't like that it bombs out on the first warning. I'd rather the test suite ran in full, logging all warnings, but that the test status ultimately failed because the code ran with warnings.

Is there a better way to achieve this end result?

Best Answer

I think you're looking for Test::NoWarnings.

Related Solutions

How should I unit test multithreaded code

Look, there's no easy way to do this. I'm working on a project that is inherently multithreaded. Events come in from the operating system and I have to process them concurrently.

The simplest way to deal with testing complex, multithreaded application code is this: If it's too complex to test, you're doing it wrong. If you have a single instance that has multiple threads acting upon it, and you can't test situations where these threads step all over each other, then your design needs to be redone. It's both as simple and as complex as this.

There are many ways to program for multithreading that avoids threads running through instances at the same time. The simplest is to make all your objects immutable. Of course, that's not usually possible. So you have to identify those places in your design where threads interact with the same instance and reduce the number of those places. By doing this, you isolate a few classes where multithreading actually occurs, reducing the overall complexity of testing your system.

But you have to realize that even by doing this, you still can't test every situation where two threads step on each other. To do that, you'd have to run two threads concurrently in the same test, then control exactly what lines they are executing at any given moment. The best you can do is simulate this situation. But this might require you to code specifically for testing, and that's at best a half step towards a true solution.

Probably the best way to test code for threading issues is through static analysis of the code. If your threaded code doesn't follow a finite set of thread safe patterns, then you might have a problem. I believe Code Analysis in VS does contain some knowledge of threading, but probably not much.

Look, as things stand currently (and probably will stand for a good time to come), the best way to test multithreaded apps is to reduce the complexity of threaded code as much as possible. Minimize areas where threads interact, test as best as possible, and use code analysis to identify danger areas.

Java – How to address unchecked cast warnings

The obvious answer, of course, is not to do the unchecked cast.

If it's absolutely necessary, then at least try to limit the scope of the @SuppressWarnings annotation. According to its Javadocs, it can go on local variables; this way, it doesn't even affect the entire method.

Example:

@SuppressWarnings("unchecked")
Map<String, String> myMap = (Map<String, String>) deserializeMap();

There is no way to determine whether the Map really should have the generic parameters <String, String>. You must know beforehand what the parameters should be (or you'll find out when you get a ClassCastException). This is why the code generates a warning, because the compiler can't possibly know whether is safe.

Related Topic