# from Ovid
# on Monday 31 December 2007 03:15:
>For example, here's a couple of time bombs waiting to happen:
>
> sub slurp {
> open FH, "< $file" or die $!;
> do { $/ = undef; <FH> }
> }
>
>Without the process boundary, I'm more likely to catch this in tests.
>
>I know most folks would disagree with me on this, but I find this a
> far more common problem than folks think.
Do you happen to have another example? This one looks to me like poorly
written code in the test (or are you citing this as code in the
product?) Terribly hackish code in the tests is not such a huge deal,
so I'm reluctant to see "being forced to address it" as a benefit of
T::A.
Either way, it is glaringly bad code.
a. any call to slurp() doesn't pass a filename -- screams of evil
b. 2-arg form of open -- banned
c. non-lexical filehandles -- banned
That is, I think there are other ways to catch such fish. I suspect
that adding peculiarities of the test environment is a not-so-good
detection mechanism.
Perhaps you're trying to address the "code makes global state
assumptions" issue? Well, I think that might be borrowing trouble.
Consider e.g. a singleton which is customizable upon creation
(by-design it assumes that only one set of parameters applies from
creation onward.) How could one test variations on that singleton's
parameters with T::A?
I think a preload-then-fork approach more closely replicates the
production environment.
--Eric
--
Cult: A small, unpopular religion.
Religion: A large, popular cult.
-- Unknown
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
