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

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Monday December 09, 2002
02:51 PM

Testing a superclass

[ #9345 ]

The more I test, the more problems I seem to come up with. Over the past few days, I was running into more and more problems testing a superclass. This particular class should not be instantiated. Instead, it provides a set of common methods for subclasses. However, I broke my own rule and instantiated it directly for my tests. This wound up causing me no end of subtle problems with my test suite and I found myself writing weird testing hooks directly into the superclass, moving them back out to the tests, and then ran into even more bugs.

I solved this by creating a dummy subclass in my test suite and then ran into the problem of Perl not allowing data inheritence. Now I have class methods to provide easy access to the class data, but that allows calling programs to get at this data. I suppose I could try to export the class data into the subclass, but that seems even worse (and still allows the calling programs to get at the data). I think I'll stick with the class methods and simply remind people in the documentation that being able to access this stuff doesn't mean that they should.

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.