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 10:57:08 +0100
On 26 Sep 2004, at 18:43, Christian Pekeler wrote:
[sorry for the smime-less repost]
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??
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.
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. When
I use JUnit, I also have this experience. With MPWTest, I do not,
because keeping the tests with the code under test is trivially easy.
I find the latter much more natural and easy.
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.
It seems pretty obvious that certain rigidities in your unit testing
setup are forcing you to introduce entities that aren't strictly
necessary.
Sometimes I also have a testclass to test the interaction between
certain production classes.
I then tend to have an object that handles the interaction between
those production classes. However, nothing at all prevents me from
adding a test-class if I feel the need for it. It is just that I don't
have to do it if there is no need, and I rarely feel the need for it.
That I *can* put tests in categories of the class under test does *not*
imply that I *must* do so.
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?
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.
Cheers,
Marcel
_______________________________________________
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