Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I usually use one driver script per test class. What are the benefits of glomming them all together, besides having fewer files?

    • You can still do one driver script per class, but there are two benefits to Test::Class::Load. When I'm writing a Test::Class program, I run those tests by typing ,t in vim. However, if I do that, it's easy to forget to write a helper script. A developer could easily check in test code which never gets run.

      The second benefit accrues as you're writing larger test suites. Let's say you've written thirty test classes. Let's say that those thirty classes load an average of twenty modules each (this is re

      • Establishing database connections and similar tasks can be expensive, so often you only want this done once, but with thirty driver scripts, you generally have to do this multiple times.

        I can understand that, but it's never been an issue for me. The largest test suite I have still takes only three or four minutes to run, and I like having the process boundary between separate tests.

        Maybe it's my inexperience with this approach, but I distrust the lack of separation between units.

        • I can understand that, but it's never been an issue for me. The largest test suite I have still takes only three or four minutes to run

          While three or four minutes isn't too bad (and I've seen Perl tests suites that take more than 90m to complete) my general feeling towards test suites is the shorter time they run - the more often I will run them. The quicker I can make that feedback loop the happier I am.

          Maybe it's my inexperience with this approach, but I distrust the lack of separation between units.

          Why (he asks curiously)?

          • Actually, I do agree with chromatic on that one. If you don't realize that your state is changing between test methods, having tests run in alphabetical order can mask hidden assumptions in your tests. The obvious example is not doing proper setup and teardown on test databases. But a more subtle example is when naughty code decides to change a global's value. That can be extremely difficult to debug.

            • True. But you can have the opposite sort of bugs where the lack of a persistent test environment hides bugs caused by changes in global state.

              I generally find that these are more common than bugs hidden by a persistent environment. Maybe this is a side effect of my development style.

              In general, in developer test land, I find tests involving lots of state cause more problems than they solve. Having tests that can run independently of each other is lovely.

              You're spot on however with Test::Class's alphabetical