Re: Unit testing framework suggestions?
Re: Unit testing framework suggestions?
- Subject: Re: Unit testing framework suggestions?
- From: Georg Tuparev <email@hidden>
- Date: Sat, 25 Sep 2004 17:32:50 +0200
Uli, I am so glad you started this discussion. I wanted to do it this
for the last two years or so, but never really found time...
On Sep 23, 2004, at 10:51 PM, M. Uli Kusterer wrote:
E.g. UnitKit keeps separate "test objects", which I find kinda odd.
I'm wondering why one shouldn't put the tests in the object in need of
the testing instead... things like that.
I use testing frameworks for many years - something like 15 - long
before xUnit, XP, Agile etc were born. And I used OCUnit almost from
the day it was born, until ...
Until one of my students (a bright chap) came to me and told me that he
wasted a day before he could write his first test method. His exact
words were "... testing with OCUnit is not the simplest thing that
could possibly work" [OCUnit was at the time probably the only
framework for ObjC - but my student was criticizing the method, not the
framework]
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].
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).
Later, we added three additional requirements:
- there should be no technical distinction between unit and acceptance
tests,
- the framework should be able to test the UI, and
- test runs should have memory - ignore for now, it is a subject of
completely different thread ...
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. I am sure all this has some
far reaching philosophical consequences, and although I discussed it
privately with few prominent XPers and Pragmatic Programmers, I never
found time to go deeper into this.
I had the chance to teach Cocoa to a (very) large Apple third party
software provider, and to test most of our ideas. I observed something
very surprising - developers who were exposed to testing framework for
the first time were able to write their first test within 10 min, and
after a day they were semi-experts. But there we two developers with
prior JUnit experience. They struggled really badly! Actually they
needed about a week before feel comfortable with our framework. It
might sound strange, but I went through the same initial struggle. I am
not sure, but this could be comparable to the transition of X11
developers to Cocoa - the first thing they ask for is the "while(1) {
//get next event }" loop - it takes them some time before they stop
feeling the need for such a beast...
Drew and I want to make the sources and some texts freely available,
and we have a permission already to do this, but realistically this
will not happen before the end of october. So I hope you stay tuned :-)
Georg Tuparev
Tuparev Technologies
Klipper 13
1186 VR Amstelveen
The Netherlands
Mobile: +31-6-55798196
_______________________________________________
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