dcsimg
Looking for some "Best Practices"
2 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

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

Re: Looking for some "Best Practices"

Posted By:   Lance_Walton  
Posted On:   Monday, December 16, 2002 09:09 AM

QUESTION 3)

One strategy is to use the AbstractFactory pattern. Unit tests can initialise the concrete factory instance as a MockFactory and the production code (or the AbstractFactory class itself if it's a singleton) can initialise it as a DefaultFactory.

This does mean switching in all mocks or none of them. However, since you've said that you're intending to test subsytem behaviour, you could have one AbstractFactory per subsystem. Also, there's nothing stopping you having multiple concrete factories that create different combinations of mocks as required.

Regards,

Lance

Re: Looking for some "Best Practices"

Posted By:   Joachim_Nilsson  
Posted On:   Sunday, November 24, 2002 03:19 AM

QUESTION 1)

Just a tip: If you use Ant when packing your compiled code into production you can filter out and exclude certain class names e.g. Test*.class before packing the classes. This way you can choose b) or c).

If you are considering using NetBeans, here's another:
When creating JUnit classes in NetBeans automatically, the standard is that a JUnit class testing the class Foo.java is named FooTest.java and put into the same directory as Foo.java. This would give you alternative b) but with the class naming reversed.



QUESTION 2)

Use Ant!! It is java based, is plugged into both NetBeans and JBuilder (and most certainly other IDEs) or can be run from command line.

It finds ALL your JUnit tests and runs them with logging capabilities. Use it from a cron job for daily builds and JUnit testing, then email the result back to you every morning.



Good luck!

/Joachim Nilsson
About | Sitemap | Contact