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 12:10:43 +0100
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??
Yes, you've got method of the class object testing methods of the
instance.
Yes, that is the default case, with which I have no problems so far.
If one would want to have the test methods as instance, all one would
have to do is override +testFixture to return an instance. So far, I
haven't found the need for this.
These tests are no more internal than when implemented in another
class.
I didn't claim they were, except for organizational purposes.
In both cases we probably start by instantiating an instance of the
tested class. The testing code that needs to be written is the same.
It is very similar, but not the same. Again, I didn't claim there were
any significant differences. You just don't need an extra class, one
that is not related to the class under test.
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.
Not fair. Comparing testing with Junit and testing with OCUnit is a
bit like comparing programming in Java and programming in Objective C.
I don't like JUnit either.
I was referring to one specific aspect where OCUnit matches JUnit.
What do you not like about JUnit?
Save that that feature, I find JUnit fine (apart from having to work in
Java in the first place, but that is a completely separate issue).
So I don't think your objection is warranted.
I was not complaining, but pointing out that having tests as class
methods of the tested class or as instance methods of another class is
not fundamentally different.
I have found that it is significantly different, because you are
leaving something out that is unnecessary and gets in the way.
MyTestCase is a client of the tested class. It includes its interface.
Again there is no difference, if you decide to move your category in
other files, you would also need to include relevant headers.
This is not true. First, there still is a difference, because a
category is still part of the class. Second, I usually don't decide to
do that.
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.
Well sure, and your tests run when you don't link to your framework?
Yes. It is the test-tool that links to the test framework. It then
just loads the framework under test and everything is fine.
Please note that I've said since the beginning that not subclassing
TestCase was also possibility. And I'm not saying that it is
necessarily worse, but that the claims that doing so makes the testing
activity so much better, simpler, easier and enjoyable are wrong in my
opinion.
Is your opinion backed by experience with both styles?
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