Selecting test methods?
Sean Corfield
test method to run rather than just those that begin with "test"
(which is how all the other unit test frameworks seem to operate).
Well, any method except setUp() and tearDown(), that is.
Is there any reason for not restricting test case methods to just testXxx()?
When I'm creating mock objects in a test case, I often use THIS and
just add any necessary methods to my test case. cfcUnit only attempted
to run testXxx() methods so it ignored my mock methods. I'm not going
to defend my approach - I know it wouldn't occur to many folks and
everyone else that I've shown it to just thinks I'm doing something
weird... :) Of course, MXUnit doesn't get very far trying to run these
mock methods so I'm going to have to rewrite some of my test cases.
Not complaining (this time!), just curious as to the logic.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
Marc Esher
OK, this is a question about the framework that i *can* answer. it's a
bug/feature i introduced quite some time ago that we never caught.
i'm pretty sure that bill's original implementation of TestCase did
just collect public functions starting or ending with "test".
meanwhile, when i originally wrote the eclipse piece, i created a
function for fetching test methods that was outside of the testcase
code. eventually that code made its way into testcase, replacing the
original code.
now, my thinking at the time was along these lines: i like how junit4
and testng work in that they don't enforce function names. when you
read good testng test cases, for example, the function names sort of
tell a story. now, those frameworks require you to use an @Test
annotation, but that's it.
So my thinking at the time, if i remember correctly, was "I like how
they don't enforce a name, but i don't like how you still have to
annotate it, so let's just throw out the need for an annotation". My
thinking -- and granted I didn't spend much time thinking about this
-- was that if you had code in a test case you didn't want the
framework to run, then just make it private (or package). And this
probably holds true for *most* situations. I had not considered yours,
though, and i think it's a valid one.
It'd take about 3 seconds to fix this bug, but I'm going to hold off
and talk to bill about how he wants to proceed. it's his baby, after
all. one of our credos has been along the "favor convention over
configuration" line, because that keeps things simple. But I suspect
we'll want to make this type of thing configurable in the
mxunit-config.xml file. probably what we'd do is have a list of
patterns that constitute a test function, and by default the patterns
would be test* and *test. this would get us back in line with cfunit
and cfcunit convention, but it'd allow folks like me to easily
customize. for me, that test* default would break at least some of my
test cases, so i'd just make the pattern in my config be "*" (or go
rename my tests).
those are just my back-of-the-napkin thoughts.
I've added it as an issue and we'll post back here when a fix is released.
thanks a lot, Sean.
marc
Sean Corfield
> So my thinking at the time, if i remember correctly, was "I like how
> they don't enforce a name, but i don't like how you still have to
> annotate it, so let's just throw out the need for an annotation".
A reasonable line of thought and it answers my question completely.
> I had not considered yours, though, and i think it's a valid one.
Well, it was easy for me to refactor the test code to use an
additional CFC (which I probably should have done in the first case).
> It'd take about 3 seconds to fix this bug, but I'm going to hold off
> and talk to bill about how he wants to proceed.
As it stands right now, there could be MXUnit users who rely on the
"any public method" approach so changing it could break their code.
Adding the configuration option is interesting and would allow folks
like me to restore the cfcUnit behavior if I wanted (this is the only
one that bit me so it's no big deal).
BTW, I noticed another difference between cfcUnit and MXUnit that bit
me: in cfcUnit, setUp() and tearDown() are called via the base class
which means they can be declared private in the test case. In MXUnit,
setUp() and tearDown() must be declared public otherwise the framework
will not run them (cfcUnit is much fussier about method signatures in
general but I had all of my setUp() and tearDown() methods private
because that was possible :)