A few months ago, John D. Cook wrote about the viability of unpopular programming languages.
His story starts with a comment about Perl 6, to which someone replied, "Does anyone actually use Perl 6?" (or words to that effect).
"My first thought," he writes, "was, I bet more people use Perl 6 than Haskell, and it's well known that people use Haskell."
What is the relationship between popularity and viability?
I ran across this the other day while writing some sample code for the next chapter of Testing Strategies for Modern Perl.
How can we use long lists of symbols from an imported package and still keep the code readable?
I usually prefer use statements of the form:
use My::Module qw(symbol1 symbol2 symbol3);
Except for specially understood modules, like
Test::More, I don't like to just import everything. Rather I like to explicitly call out only the specific symbols I need.
But what if you need to:
use My::Module qw(
symbol1 symbol2 symbol3 symbol4 symbol5 etc and so many symbols
that it takes up several lines all the time in every package
that uses it
There are a few alternative approaches.
The first part of this series described Test Hierarchy, a hierarchy of test classes that mirrors the classes under test, and explained why it’s an antipattern. Part two explored what makes a good unit test and why Test Hierarchy does not. This third and final post reflects on why programmers use Test Hierarchy and why these reasons aren’t persuasive.
rockyb’s recent post about B::DeparseTree contained several insights on testability and writing good tests. Here are my takeaways.
The first part of this series described Test Hierarchy, a hierarchy of test classes that mirrors the classes under test, and explained why it’s an antipattern. For how common it is, this practice doesn’t even produce good unit tests.