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 19:06:05 +0100
Parallel class hierarchies indicate too tight coupling, duplication, a
lack of abstraction and usually result in hard to change code.
Being somewhat of a simpleton, I see parallel class hierarchies as the
same thing in two places, and thus a trivial violation of
OnceAndOnlyOnce. A lot of the other problems come as a result of this.
Since tight coupling is the very purpose of unit testing (as we want
to test every public method of a specific class),
So why not attach the test-code directly to the code to be tested?
Especially if it is less work to do so (the coupling is fully
automatic) and we have reduced our entities ( Occam's Razor, DTSTTCPW )
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.
Two objections: first, your argument seems inconsistent. On the one
hand, you state that you want tight coupling, on the other hand you
don't perceive the fact that the hierarchies do get out of sync as a
problem. Second, my practical experience with both styles leads me to
conclude that it is a problem, at least relative to the solution
without quasi-parallel hierarchies.
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.
You don't *have* to maintain a category, it is just useful for
documentation purposes. The practical difference is that the tests are
directly, unambiguously and simply attached to the class to be tested.
So you have fewer entities in your program/framework. Less to think
about. More chunking, more abstraction...good. One very simple
benefit: if you view unit tests as a form of documentation, it is
obvious where to find the unit tests for a particular class. With
xUnit style, this is far from obvious.
Also, a class is a somewhat more heavyweight entity than a mere
category: it occupies the global namespace, you have to give it a
name, etc. It also has to be a subclass of TestCase and therefore
implies a link-time + runtime dependency on the unit testing framework.
But really, I think this boils down to you being both quite accustomed
to xUnit style, and not having practical experience with the other
style. Try to step back for a moment, and maybe consider what Georg
said about how different programmers reacted to their unit testing
framework (which I do not know). It was the ones with xUnit experience
that had the most difficulty.
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.
I thought you want them to be highly coupled? How do you find the
tests that belong to a class?
They just happen to start out looking parallel in the beginning.
Nothing good or bad about this, IMHO.
I beg to differ.
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.
Yep, that's also what I found. I want tests to be as obvious 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.
Compared to not having unit testing: full agreement. However, coming
from MPWTest I found the separate class hierarchies of tests required
by JUnit to be bothersome.
I think we're splitting hairs.
Hmm...I agree that you are splitting hairs, trying to pooh pooh
something that you haven't actually used that (a) is simpler and (b)
easier to use than existing unit testing. The differences may appear
small to you in theory, but I find them to be actually significant in
practice, having actually used both styles and having found xUnit style
lacking (though still absolutely superior to not unit testing).
None of the different point of views in this thread (not just in this
mail) justify a big argument in my opinion.
So why are you arguing?
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.
If you go back to Georg's post, and actually also to Uli's, you will
see that the arguments presented are directly connected with trying to
make unit testing even simpler and more straightforward, which can only
help the cause.
When I came upon xUnit, I found that I didn't get it. There seemed all
this extra complexity/baggage that just baffled me, especially coming
out of YAGNI-land :-) It seemed to me that it could be a lot simpler,
especially in Objective-C. And it turns out that it *could* be a lot
simpler and more comfortable to boot.
And it seems I am not the only one baffled:
On 23 Sep 2004, at 21: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.
Just because you are sufficiently clever that things like that don't
baffle you, doesn't mean that the rest of us are as well. So, if you
want more unit testing, help make it easier!
Unit testing does not *have* to be in xUnit style. In fact, the
TDD-gurus wholeheartedly recommend writing your own unit testing
framework.
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.
That would be great, but I am not entirely convinced that Apple
frameworks have been or are developed in TDD style...
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
1d480c25f397c4786386135f8e8938e4
_______________________________________________
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