Re: Unit testing framework suggestions?
Re: Unit testing framework suggestions?
- Subject: Re: Unit testing framework suggestions?
- From: Marcel Weiher <email@hidden>
- Date: Sun, 26 Sep 2004 12:59:28 +0100
On 25 Sep 2004, at 16:32, Georg Tuparev wrote:
Well, this gave me a lot of food for thinking. At that time I was
already reading a very early draft of Kent's TDD book, and happy I was
not - not because of the technique, but because of the technology...
So after thinking about this for almost two months, finally I came to
the conclusion that the problem is exactly the one you discovered -
separation of TestCase from the class being tested [well, in reality
this is not always true -- but please read my replays to Marco I
intend to write later today for more].
Yes, this was my impression as well, at first simply a conjecture and a
code smell: parallel class hierarchies. Now that I've worked with
JUnit for well over a year, I am absolutely convinced that my decision
to allow the class to test itself for MPWTest was precisely right.
At the time Drew and I was starting to put our thoughts about
multi-volume text book on Cocoa programming (still work in [slow]
progress), so we had a beer together and write down (on a A6 index
card) the requirements for a testing framework to be publish in the
book. Here what we scribbled:
- the integration to any cocoa project (existing or new) should not
take longer then a minute
- one should learn the basics in max 5 mins
- test could be placed anywhere (in TestCase or directly in the class).
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
{
}
[Automatic test-case discovery could be added, but I actually find the
explicit listing of my tests useful]
[snip more requirements]
We ended up writing something that at first looked like a simplified
version of xUnit. But is was not! Very soon I discovered that actually
it is completely new beast. The difference is more on how it changed
my way of testing - the flow. Now actually I can not call it testing
any more ... it feels more like compiling, or debugging - a real
integrated part of the development process. And it is part of the
program you write (as it should be - I discovered this much later) -
not part of the IDE as the original xUnit was supposed.
YES! That is exactly my experience with MPWTestKit. The tests are an
integral part of each class that is written. They are always there.
They do NOT produce a dependency on the unit test framework, which only
adds infrastructure to run the tests in a controlled/grouped fashion.
In addition to the tests being automatically associated by a class,
they are automatically grouped by framework.
_______________________________________________
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