Re: Unit testing framework suggestions?
Re: Unit testing framework suggestions?
- Subject: Re: Unit testing framework suggestions?
- From: Marcel Weiher <email@hidden>
- Date: Mon, 27 Sep 2004 00:47:02 +0100
On 26 Sep 2004, at 19:57, Marco Scheurer wrote:
On Sep 26, 2004, at 13:59, Marcel Weiher wrote:
Hmm...I guess I should (have) advertise(d) MPWTestKit a little more
heavily, because it has these attributes. There are hooks for more
flexibility if you need it, but the basics are absolutely trivial.
+testSelectors
{
return [NSArray
arrayWithObjects:@"myWonderfulTest1",@"myWonderfulTest2",nil];
}
+myWonderfulTest1
{
}
+myWonderfulTest2
{
}
Hey, now I have to disagree with not only Georg, but also Marcel!
Don't you think that the fact that these tests need to be in class
methods smelly?
No. Also, they don't *need* to be in class methods. You can, if you
want to, override the +testFixture method to return any object you
please, and that will then be the test-fixture for that class.
However, the default is the class itself and I hardly every found
myself sufficiently motivated to change it.
Of course you keep them "close" to the tested class, but you still
have an instance of one class testing an instance of another class.
Huh? I have the class testing instance of itself. This seems
perfectly reasonable and has caused me absolutely no problems. Why do
you say an instance of one class testing an instance of another class?
Do you mean an instance of the metaclass??
If the idea is to have both testing and tested code in the same file,
nothing forbid having two classes in the same file either.
Sure. And if there is some reason why I *do* need a subclass to test,
then I do precisely that, for example when testing a category of a
class that already has tests. I could also do it if I actually needed
extra state.
So it's YAGNI and DTSTTCPW: yes, the things you state *can* happen,
but they are trivial to deal with when they do and for the 90% of the
time that they are not needed there is a simpler solution.
And I don't buy the argument that writing tests in a category rather
than a class change the whole perspective on unit testing and how it
makes it so much more integrated in the development activity.
I wouldn't buy it from a purely theoretical point of view either, but
after a little more than 1 year of JUnit (after a number of years with
MPWTest), I can say that it has definitely been the case. YMMV.
Of course OCUnit has TestCase and TesSuite, but that's an
implementation detail with which nobody needs to care if they don't
want to. They are not getting in the way of writing tests. For
instances TestSuite are automatically created to group the test cases
of different compilation units.
Yes, MPWTest creates both TestSuites and TestCases automatically
(though you could interfere and get your own grouping).
I'm a fan of categories, but in that case, I don't see the point.
Writing a test using OCUnit and, I suppose, many others is just as
trivial:
@implementation MyTestCase:TestCase
- (void) testWonder1
{
}
@end
Now I have to wonder: you complained above about an instance of one
class testing an instance of a different class (which wasn't the case),
and this is precisely the case here. How is MyTestCase related to the
class being tested?
One way or another the only required activities are to write test
methods and to run them.
Not quite. At the very least, you need to link in the testing
framework.
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
1d480c25f397c4786386135f8e8938e4
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden