http://qs321.pair.com?node_id=341348


in reply to Testaholics Anonymous (or how I learned to stop worrying and love Test::More)

Yes, I think you've gone a little too far. Your tests should not be redundant. Redundancy is not something you want in your code, and tests are code.

I test every method before its called with can_ok, and I (re)test the same method on each instance I create. Sometimes I actually set up test_Object_Interface functions and use it to test subclasses (which is the source of many of the duplicate tests).

I would not do this. If the methods are called once and succeed, that should be enough. Testing with can() is not very useful, since that isn't really calling the interface to your class.

I test all my constants using can_ok and then test their value.

I don't see how you could do that without embedding the values of the constants in your test, which would be wrong. Unless these constants are a part of your public API, you should not be testing them at all.

  • Comment on Re: Testaholics Anonymous (or how I learned to stop worrying and love Test::More)

Replies are listed 'Best First'.
Re: Re: Testaholics Anonymous (or how I learned to stop worrying and love Test::More)
by stvn (Monsignor) on Mar 31, 2004 at 20:42 UTC
    Redundancy is not something you want in your code, and tests are code.

    But most of the redundancy of the tests is actually encapsulated in functions (much as you would do to deal with regular code redundancy). I fear that to try and remove the redunancy would result in my not being able to use the functions (test would get to specialized) and while it would reduce redundant tests, it would decrease the modularity of my test code. Is this still not ok?

    I test every method before its called with can_ok, and I (re)test the same method on each instance I create.
    I would not do this. If the methods are called once and succeed, that should be enough.

    Yeah this one seemed like I was over the edge. Thanks for confirming that.

    Testing with can() is not very useful, since that isn't really calling the interface to your class.

    I am actually not using can, but Test::More::can_ok which no doubt it implemented in terms of can (though I have not delved into the source code to be sure, and the difference is probably neglible). I do have to disagree that can is not "really calling the interface to my class" though. Sure it can be calling a subclass potentially, but IMO thats the class interface (just inherited). I view these tests in particular (the Interface ones), as a means of helping me keep my API straight across versions/updates. It makes no assumptions about implementation, but only that the API is the same. It has already proven useful in tracking down a bug in an older installation of our framework, by finding where an API had changed between versions, but had gotten missed while someone was making changes to the code which used the framework. Why do you feel this is not "really the class interface" I am interested to know?

    Unless these constants are a part of your public API, you should not be testing them at all.

    They actually are part of the public API, which is why I wanted to test them.

    I don't see how you could do that without embedding the values of the constants in your test, which would be wrong

    Very true (and exactly what I was doing (Bad programmer! Bad!)), but being part of the public API I want to test them, I suppose that just testing that they are there (can_ok) is good enough. Do you agree?

    -stvn
[reply]
[d/l]
[select]
      But most of the redundancy of the tests is actually encapsulated in functions

      That sounds fine then.

      I do have to disagree that can is not "really calling the interface to my class" though.

      It isn't calling the interface. It is calling the can() method which is typically inherited from UNIVERSAL::can(). This will break if you do any sneaky AUTOLOAD stuff. (Sure, you could fix that, but what a waste of time.) It's better to actually call the method you are checking instead.

      I suppose that just testing that they are there (can_ok) is good enough. Do you agree?

      Yes, for constants. I think it's better to use globals than the subs that the constant pragma creates, but that's a whole other discussion.

[reply]

        At the risk of tempting tilly into posting a top-level meditation in the subject, I disagree that can() is too tricky to get right.

        Granted, many people get it wrong, but the solution is well documented.

        I prefer to test my subs and methods with can_ok() because I prefer the way it documents failure, if things fail. It's also very handy to test exporting, if that's your style.

[reply]
[d/l]
[select]
        This will break if you do any sneaky AUTOLOAD stuff.

        Personally I avoid that stuff like the plague, so it wouldn't be an issue in this particular code base. But i see what you are saying.

        -stvn
[reply]

In Section Meditations