in reply to Re^3: Test Survey Results
in thread Test Survey Results

Hmm, well to me not bothering to RTFM, or do some basic research (e.g. ask on PerlMonks - a response would've been forthcoming within minutes) is not really a valid excuse for not doing testing. Putting a test suite in place takes time, and if you don't have the time to find out about Apache::Test, then you're clearly not committed to testing.

And why should mod_perl be more difficult to test than anything else? If your modules are properly factored, they should be decoupled from mod_perl. If they're not, well your issue isn't mod_perl, it's your code base.

There *are* valid reasons for not doing testing (but they're typically outside the realm of programming, e.g. management won't allow it (explicitly, or implicitly by not allowing enough time to complete tasks with tests)). I don't believe the fact that your application is mod_perl can be a valid reason. Whoever wrote that may have *actual* valid reasons, but to me, it makes sense to be aware of those (so you can potentially do something about them) than to blame it on something you most likely can't change, and get away with not bothering to write tests.

Replies are listed 'Best First'.
Re^5: Test Survey Results
by DrHyde (Prior) on Aug 07, 2008 at 10:25 UTC
    mod_perl is hard to test because you have to test how your code interacts with the black box that is Apache's guts; how it copes with running lots of copies concurrently; and so on. Yes, it's easier if your code is in nice little modules that are decoupled from mod_perl, but then you're not testing mod_perl. You still need to test to thin layer that sits between your modules and mod_perl and you still need to test the concurrency bit. Programmers aren't used to thinking about concurrency even if they jolly well should be, as can be seen from the vast majority of code on the CPAN which doesn't bother with any concurrent tests at all, let alone really carefully testing it.