|Problems? Is your data what you think it is?|
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||Need Help??|
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