As one of the people asking for a code sample, THANKS!

I understand your 'no love lost' over the named block thing. I took a similar approach last time I wrote a layout system for TT (I guess I should have published it since it was quite similar to bootstrap). Lately I've played with using filters instead. I did a toy app using Catalyst that took this approach, and this is a very early prototype, but the View is defined here: https://github.com/jjn1056/Shutterstock-Exchange/blob/master/lib/Shutterstock/Exchange/Web/View/HTML.pm and the actual code is pulled over from a application model ( here: "https://github.com/jjn1056/Shutterstock-Exchange/blob/master/lib/Shutterstock/Exchange/ListQuestions.pm")

The Template is here: https://github.com/jjn1056/Shutterstock-Exchange/blob/master/share/html/index.tt#L30

This is probably almost exactly not what I really but, but the tiny part that is, is some progress for me :)

Thanks!

"There is no great writing, only great rewriting" - Louis Brandeis

John

I tried Attribute::Handlers, but it didn't work under mod_perl2 because CHECK and INIT aren't run, and BEGIN is too early.

In the end I just wrote my own MODIFY_CODE_ATTRIBUTES sub. It's actually pretty trivial to write your own. See perldoc attributes for details.

Do some of your target audience use IE8 or below? It doesn't do well with SVG.

File::Slurp also happens to come with some other handy functions. I've recently become a big fan of edit_file_lines, which is a bit like doing a map over each line in a file.

With that said, every time I've started with mock objects in the tests (for the reason you suggest), I've regretted it and have refactored dependencies to be able to use real objects. Maybe my rule is best phrased as a goal of refactoring: as few mock objects in the tests as possible.

• I want to test some behavior of an A.
• In order to instantiate an A, I need a B (dependent data, uses-a relationship, whatever).
• I don't care about B (after all, I'm testing A), so I mock it.

Could be B is a PITA to create, or I just don't want to risk changes (or breakage) in B to screw up my tests, or whatever. Even so, if changes (or breakage) in B could screw up my tests, maybe they should fail (if they'll screw up my tests, why wouldn't they screw up my code?). Basically, I use mock objects as a last resort, and I never mock the actual thing I'm testing.

So I think I mostly agree with you.

$updates->{market_capitalization} = $stats->{market_capitalization};

Or was that intentional to remind us how easy it is to make mistakes and therefore need to test our code?

Either way, great post. Thanks

croak 'Incorrect class method call "make_bounded_regex"'
    if ref $class
    or not $class->isa( __PACKAGE__ );

part of a function → class method transition, to be taken out at a later date, as insurance against incomplete refactoring. But that does not exactly “solve” the problem.

The thing is, you're writing software for people to install. If you do that, it makes no sense to me to worry that they can't or won't install software. The people who can't or won't install software won't install the software you're writing! This use case contradicts itself.

Did you, like, go and ask ingy? He's a person one can communicate with.

You're right about the source of the library management problem.

As for lack of CPAN - it is hard to have one without include/require/use...

Like that time I scraped the librarything.com site for the ISBN numbers of my
own books so I could let my computer find out what they were selling for used
at Amazon....

Anyway, the one thing I can say for my way (besides I know how to do it) is it
exposes the guts of the process in a way that makes it easy to know where to
look if something goes wrong. And, as you touch on, I can fire it back up
again at any point in the process if it gets interrupted. Also, nobody can
accuse me of premature optimization, and the jerry-rigged look of the thing
highlights rather than obscures the fact that I'm using "API's" that are really
no such thing; the hack looks like a hack.

I guess that's actually more than one thing I can say for it.

I can only report what I've seen.

"Yet in truth, mock objects are far, far overused."

If every unit (or most units) need mock objects for you to test them to your satisfaction, your tests are likely fragile.

• Mock objects aren't a good testing technique
• Mocking isn't a good testing technique
• Excessive mocking gives false confidence in correct behavior
• Something else?

I don't see a big distinction between mock objects, monkey-patching, test databases, etc. They are all techniques to simulate parts of a system, usually externalities.

Testing itself is simulation. The art of testing is finding the right abstractions to simulate behavior to confirm correctness to the right level of confidence (where the definition of "right" in each case will be different for different code, developers, companies, whatever.)

Is a test database (a "mock database") any better or worse than a mock object that simulates a database connection? That depends. For me, I'd say it's probably whichever is faster to implement; whichever is more likely to faithfully replicate behavior found in the real world; whether I'm trying to test requests or responses; and on what assumptions are acceptable about the correctness of the database itself.

That logic extends to other parts of your argument -- they all depend on the definition of "troublesome" for the nature of a particular test, but your definition of "troublesome" might differ from anothers'. Maybe your argument reduces to "only mock what is troublesome and don't mock for the sake of mocking if that complexity is more troublesome than the trouble you're avoiding". I'd accept that, but still think the devil is in the details.

Your straw-man Socratic argument asks "why test in isolation?" and gives a facile answer. A few more-thoughtful reasons I can think of off the top of my head include:

• It's often cheaper to test small bits of code (and/or data) than full systems, making it easier to test frequently during development, catching errors earlier when the cost to fix is lower
• It's often easier to reason about correctness (for both test design and debugging) when there are fewer degrees of freedom, less coupling and less overall complexity
• It's easier to write (and run) unit tests during development when only a portion of the system has been built or when development responsibilities are split across teams or developers

tl;dr summary:

Excessive reliance on either unit testing or full-system testing is misguided. Mocking is one of many techniques to construct a test simulation. For any situation, pick a simulation technique to give the greatest confidence in correct behavior for the least amount of trouble. Actually think what those mean to you and don't get stuck following anyone else's dogma.

In addition to all that, I've heard different views of how BDD differs from traditional Test-Driven-Development (TDD). Someone once said that there isn't a real difference, and someone on IRC told me that from what they understood, TDD was more about unit-tests, while BDD was more about integration tests and system tests. Personally, I have used Test::More and related modules to write some system tests and integration tests for my modules, and I don't see why they are not suitable for that (though I admit something like FIT or INGY's Test::Base may be somewhat better suitable if you're doing a lot of data-driven testing). Part of this may be an issue I have, that when I write a test, I usually don't consciously think whether it is a unit test or a system test or whatever, but just try to write a meaningful test that reproduces and tests the offending behaviour.

It is quite useful for that.

Really? What does it achieve that a “use” wouldn’t?

I agree with Schwern, 'use_ok' is not the problem.

In a simple map such as... map { $_, f($_) } ... it is less obvious but is the same situation: the actual map block is returning a list containing $_ (rather than the value of $_), and whatever happens after that is fetching the value.

But it's not, and very strangely so:

perl -MModern::Perl -e 'sub f { say "_ is $_"; $_++ }; $_ = 0; say join( ", ", $_, f(), $_, f(), $_, f(), $_, f() );'
_ is 0
_ is 1
_ is 2
_ is 3
4, 0, 4, 1, 4, 2, 4, 3

It works the same whether you use $_ or $x: the variable is evaluated at the end of the expression.

Using tie to see what runs when is illustrative:

perl -MModern::Perl -e 'package Tied; my $x = 0; sub TIESCALAR { bless {}, "Tied" } sub FETCH { say "FETCH $x"; $x } sub STORE { my ($this, $value) = @_; $x = $value; } package main; my $y; tie $y, "Tied"; sub f { say "y is $y"; $y = $y + 1; }; sub n { print "\n"; () } $y = 0; say join( ", ", $y, f(), n(), $y, f(), n(), $y, f(), n(), $y, f(), n() );'
FETCH 0
y is 0
FETCH 0
FETCH 1

FETCH 1
y is 1
FETCH 1
FETCH 2

FETCH 2
y is 2
FETCH 2
FETCH 3

FETCH 3
y is 3
FETCH 3
FETCH 4

FETCH 4
FETCH 4
FETCH 4
FETCH 4
4, 1, 4, 2, 4, 3, 4, 4

As we can see, the value of $y is fetched four times, right before running join, not interleaved with the calls to f().

Perl makes easy things "very easy" and difficult things possible.
or even
Perl makes difficult things easy and easy things easier.

Perl makes it very easy to write a simple Hello World script, and learn the basics. But if I want to create a web page, PHP makes it easier.

Maybe we should make it possible to install Wamp, and run this.

<?perl
     say "Hello World";
?>