It's not that it's dangerous, it's that I don't think it's a sensible requirement for the thing being tested.

I suppose I'm not willing to fire up an apache2 on some random port every time I want to test something that happens to involve Apache2::RequestRec. If I can't create the $r in a "pure" context then I should be able to mock it, that's exactly what Test::MockObject is for (and very good at).

So, I dunno, maybe my objection is mostly aesthetic (plus the broken documentation) but I feel strongly enough about it that I refuse to "poison" my test suite for all eternity by constantly firing up web servers in order to verify things like correct unicode object serialization to a cookie.

(I do of course admit that my definition of "poison" could be very different than anyone else's.)

Maybe my best answer to your question is that the danger lies in introducing that "poison" into a test infrastructure that I'm hoping to live with for years to come.

(And I love how ridiculously personal people can take their Perl code. Do Java people do this?)

If I can't create the $r in a "pure" context then I should be able to mock it, that's exactly what Test::MockObject is for (and very good at).

Aha, right. Then why don't you just do it? fake the $r with Test::MockObject?

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

You're absolutely right, and thanks for making the point.

I slept on it and realized it actually can't (hopefully) be that hard to figure out what Apache2::Cookie needs from the $r and mock that. And then I would at least have a leg to stand on in my complaining, and maybe even a patch for the docs. :-)