Re: Unit testing framework suggestions?
Re: Unit testing framework suggestions?
- Subject: Re: Unit testing framework suggestions?
- From: Georg Tuparev <email@hidden>
- Date: Sun, 26 Sep 2004 01:33:37 +0200
It happens that I disagree with Marco once each decade (so do not
expect me to start discussing with him next 10 years) ... but I feel
this is one of these occasions...
Also read this in the context of my previous replay to Uli.
On Sep 24, 2004, at 4:56 AM, Marco Scheurer wrote:
On Sep 23, 2004, at 22:51, 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.
Most implementations of testing kits implements tests in a subclass of
TestCase.
True. As far as I know only NUnit - and I believe because of technical
reasons (I might be wrong - never spent too much time on it).
One reason is that tests can have their own state and ivars, and it
wouldn't be a good idea to mix this with the class you want to test.
You might be right is theory, but at least I and all the people I
enjoyed working with almost never kept state between two tests.
Actually, if I think very hard, I cannot find a single case where my
need of using state was not because of stinky code - or bad design, or
bad refactoring. In our testing framework, we create an instance of the
tested class for every single test method. In cases where we need
singleton we need to override the setUp and tearDown methods. For class
like App Delegate (instantiated in a nib file) we write:
+ (id)setUp { return [NSApp delegate]; }
+ (void)tearDown:(id)testInstance { }
This feels strange at the beginning - normally one needs to implement
setUp and tearDown for each TestCase class, but with our framework we
need from time to time to knock them off - most often though one never
touches them. Also note the "+" in front of these methods. This is not
a typo :-)
Here a typical test method:
- (void)testVisibleWindow {
SEConfirmIsTrue(tableWindow != nil, @"Window should not be nil");
SEConfirmIsTrue([tableWindow isVisible],
@"Window should be visible after the application is
launched");
}
UI testing made easy...
Another is that tests are written from the perspective of a user of
the class rather than as "internal" tests. A good practice is to write
the tests before you write the tested code. If you do so, your tests
can be seen as a formal specification of the code to be written.
Developer writes tests first - to help him or her to write the real
code. So you write a test not as a user, but as an author. Tests are
also the best known to me way of documenting - and you want to keep the
doc close to the code - otherwise they will get out of sync - therefore
test are so good - they must be in sync if they have to pass! [I am
sure this might sound like Knuth's Literate Programming - in retrospect
I have to acknowledge that after Drew and I wrote the first version of
our testing framework, I though that this is the closest practical way
of doing literate programming for Cocoa]
Another is that a lot of stuff is usually done in the TestCase class,
so that writing a test is as simple as writing a single method in a
subclass of TestCase.
Luckily we have categories in ObjC. And no one stops you putting this
"lot of stuff" to a category of NSObject :-) But more importantly,
there is no need to have a lot of stuff in TestCase class.
[...]
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