Posted By:
Michael_Chermside
Posted On:
Tuesday, November 19, 2002 10:41 AM
Hi! I am starting at a new company, and am starting on a new, fairly large project. As such, I'm presented with a fairly unique opportunity to establish some standard practices for unit testing. A few things are obvious. Yes, writing unit tests for all new code should be STRONGLY ENCOURAGED. Yes, the JUnit framework is what we will use for launching our tests. Some are less obvious, but I'm still clear on what to do. For instance, writing tests that include the database are often QUITE difficult. Not everyone has a copy of Oracle; we can't just erase tables willy-nilly to set up for each test; etc. So I will use mock objects (hopefully star
More>>
Hi!
I am starting at a new company, and am starting on a new, fairly large
project. As such, I'm presented with a fairly unique opportunity to
establish some standard practices for unit testing.
A few things are obvious. Yes, writing unit tests for all new code
should be STRONGLY ENCOURAGED. Yes, the JUnit framework is what we
will use for launching our tests.
Some are less obvious, but I'm still clear on what to do. For instance,
writing tests that include the database are often QUITE difficult. Not
everyone has a copy of Oracle; we can't just erase tables willy-nilly
to set up for each test; etc. So I will use mock objects (hopefully
starting from those at www.mockobjects.com) to simulate the connection,
and other "external" data sources/sinks.
And there are a few questions on which I'd like to hear input from
some with more experience so I can start out using "Best Practices"
instead of having to learn from my OWN experience.
-
QUESTION 1:
-
Where do my JUnit unit tests go?
I see 3 likely answers... (a) make each an inner class of the
class being tested, (b) for every class "Foo" have a class called
"TestFoo" in the same package, or (c) have a separate (but parallel
hierarchy of classes... SOURCE/com/pkg/Foo.java is tested by
TEST/com/pkg/TestFoo.java.
I lean towards (c) because it makes it easy to build the "real" code
and the "test" code separately, and omit the "test" code from
production deployment. Are there other significant issues here?
-
QUESTION 2:
-
How do I automatically build the suite of all tests?
For each class, I can have several methods called "testXxx()" and
can collect them into a suite to run at once. I can collect the
suites together into larger suites, eventually coalescing into a
suite called "RunAllTests" which does just that. But this requires
me to write each of these suites, and to remember to include each
and every test class. I'd rather if "RunAllTests" just magically
found all of the tests... that way I couldn't forget to include
one and wind up with some tests that never get run just because I
forgot a line in a suite. How do I create this "magical"
RunAllTests?
Stray thought... if there's no simple solution in straight java,
I wonder if ant can help me to achieve RunAllTests as an ant
target?
-
QUESTION 3:
-
How do I "turn on" my mock objects when tests are running?
The most straightforward use of mock objects is to pass them
directly to the code being tested. However, (despite the fact that
this is a bit broader than simply "unit" testing), I plan to have
a lot of tests that exercise an entire sub-system at once. For
example, I might create the input file, run the command, and then
test the output file. But if this "command" opens a connection to
a database (or other system), then I'd like to return a mock
ResultSet instead of a real one. So the code that obtains a DB
connection has to look at some global setting to see if we're in
"test mode" or "real life". What is a good way to achieve this --
is it something I'll have to write for myself?
I'm sure I'll have more questions also, but this email is QUITE long
enough as is. Thanks in advance for any feedback, suggestions, or
pointers to other forums/FAQs for this kind of stuff.
-- Michael Chermside
<<Less