More than one test-case for a class

Discussion of testing theory and practice, including methodologies (such as TDD, BDD, DDD, Agile, XP) and software - anything to do with testing goes here. (Formerly "The Testing Side of Development")

Moderator: General Moderators

Post Reply
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

More than one test-case for a class

Post by Ambush Commander »

I recently ran into a situation where I needed to create two separate test-cases for one single class. Is this a good idea, or does it indicate that the class needs to be refactored into two classes? They test two different aspects of the class: the first is for its functionality, the second is for its error reporting. I would have put them together in one test-case, but their requirements for the setup()/teardown() functions are different.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

Usually that indicates you should refactor the class into two; you mention you have the functionality and the error reporting - why not have the functionality in it's own class that throws exceptions, then have an error handler class, and another error reporting class?
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Well, I can't throw exceptions because that would disrupt the program flow: these are all non-fatal errors, really, I guess they're really warnings or notices. (Also, PHP 4). So that setup probably wouldn't work.

To reuse your metaphor though, I would still need to test that the class with functionality is actually throwing the exceptions when appropriate error conditions are met. So I'd still be testing the same class >.>
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

How about using a plugin approach for the error output then? This way, if it wasn't passed in the class doesn't output any errors, simply swallows them. If the error class is supplied, you're simply using the interface giving you an abstraction.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

That's probably what I'm doing right now. The error collector is passed in through a registry object that is passed in by parameter. For performance reasons, we test that the error collector is an actual object before calling it, but this is only a five character overhead.
Post Reply