Re: Unit testing framework suggestions?
Re: Unit testing framework suggestions?
- Subject: Re: Unit testing framework suggestions?
- From: Christian Pekeler <email@hidden>
- Date: Mon, 27 Sep 2004 09:31:17 -0600
On Sep 27, 2004, at 3:57, Marcel Weiher wrote:
On 26 Sep 2004, at 18:43, Christian Pekeler wrote:
On Sep 26, 2004, at 5:59, Marcel Weiher wrote:
On 25 Sep 2004, at 16:32, Georg Tuparev wrote:
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.
Parallel class hierarchies are a code smell if both hierarchies are
production code.
Says who??
What? You mean if I say something, it doesn't carry enough authority
for you? ;) OK, I restate as: In my personal experience, I have never
perceived parallel class hierarchies as a code smell if one hierarchy
is for production code and the other for unit tests.
Parallel class hierarchies indicate too tight coupling, duplication, a
lack of abstraction and usually result in hard to change code. Since
tight coupling is the very purpose of unit testing (as we want to test
every public method of a specific class), and since we usually want to
test concrete implementations instead of abstractions, I'm of the
opinion that parallel class hierarchies are not a problem in the
context of unit testing.
We're dealing with one hierarchy of production code and another one
of unit testing code. To me, that doesn't smell.
To me it does. Because I still have to build/maintain both
hierarchies.
If you have to maintain a test category instead of a test class per
production class, I fail to see a significant difference for practical
purposes.
In my experience, for anything but trivial systems, these two class
hierarchies are not an exact mirror of each other.
Well, that might be because it is difficult to keep them in sync.
I'm usually not even trying to keep them in sync. They just happen to
start out looking parallel in the beginning. Nothing good or bad about
this, IMHO.
Often times I have more than one test class per production class.
These test classes test different aspects of the production class and
usually have different setups.
Hmm..when I have different setups, I don't have to create separate
classes. I just factor out a different setup method in my test code.
Sure, that's another good way of doing this. I've recently met the
author of the upcoming XUnit Patterns book. He told me that he doesn't
like the one setUp/tearDown per test class approach because they're
invoked implicitly and therefore make the individual test methods
harder to read. I don't mind the implicit invocation as it makes my
test code shorter, but every now and then have explicit setUps as well,
especially when the test methods in a test class all have different
requirements.
And other timed I don't have a test class for a production class at
all because I only test what could possibly fail and what requires me
to do TDD.
Then how did the class get written, under TDD? When you look at that
particular class, how do you find the tests for it?
It can happen as a result of refactoring. For example I create a common
super class for two existing classes that have some form of code
duplication, then I usually don't create a test for the new superclass
until I have to. Or if instances of class A create instance of class B,
and B happens to be a simple container, then I usually just have a
simple test for B in the testclass for A. When working with Apple's
frameworks, I find TDD is not always practical. For example, I don't
usually test my controllers (but try to keep them as small and simple
as possible).
To me, almost all this looks like symptoms of *having* to maintain a
parallel class hierarchies, and not being able to keep them in sync.
Why you would think of them as *good* things puzzles me.
I didn't mean to imply that I find them good, they just don't bother me.
I think we're splitting hairs. None of the different point of views in
this thread (not just in this mail) justify a big argument in my
opinion. I think it's great that we have more than one unit testing
solutions and I'm very interested in seeing how they're different. I'm
a bit disappointed that only the usual suspects are writing in this
thread, indicating that unit testing is still not a mainstream activity
in this community. I'm looking forward to the day that Apple releases
all their frameworks and libraries with the sources of the
corresponding unit tests and a community which wouldn't accept anything
less.
Christian
_______________________________________________
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