Getting test infected

[Faisal Khan]

Despite learning the importance of testing software during the computer science course, I entered the field of IT from web sites > web applications (initially in CF and then PHP) > finally moving onto Java - thus never really got heavlity into testing.
Though I do tend to test my code but its never definitive testing and its certainly never been test driven development. I am in the process of re-writing an application and would like some advice on testing.
I have started the development from backend, have just finished tidying up the database tables etc. I have now moved onto writing business model classes and wrote a couple of them. Beofre I proceed, I would like to unit test my code.
How strict is unit testing, for example, I have written a Database class, CarDAO which extends Database and a CarBean which extends CarDAO. Should I now test each of these "units" individually so write a DatabaseTest, a CarDAOTest, a CarBeanTest etc. The CarBean also required some information from the corporate so I had to also start writing the CorporateDAO and CorporateBean.
Can someone please advise on a good strategy to testing the abvoe using JUnit (my Database class is using the tomcat JNDI datasource settings to connect to the MySQL database - should I also write a stand alone connection to test outside tomcat environment).
Moving on from here should I write the test classes first based on the business requirements and then write the code, bearing in mind that the application is written already but very badly.
Apologies for going on but I am little bit confused abou some matters and wanted to seek clarification and guidance to emabrk upon a good testing strategy.
Any help will be most appreciated.

[Stan James]

This is a great path you're on. Stick with it! Writing testable code is not at all simple. Writing the tests first will certainly help. It pays to study some of the OO principles that help you avoid coupling so you can test classes in isolation.
I try to avoid tests that require the database because it's hard to be confident the database is in a clean state before you start. But here you are talking about testing the classes that most intimately interface with the database, so you'll have to have some db contact. Try to make sure these classes are as thin as possible, and do nothing that isn't related directly to the database instance. That means you move all functionality that can be tested without the database to other classes. Read up on mock objects and see how often you can fake the presence of the database.
That's way vague ... hope it helps a little. Feel free to post test and design ideas as you go. We'd love to learn from you, too!

[Jeanne Boyarsky]

Faisal,
I suggesting starting small. It's easier to get used to writing unit tests by testing code without dependencies.
Also, many people have two categories of tests. The names vary, but there are pure logic unit tests that don't require any external dependencies and integration type tests that require the database.
JUnit in Action walks you through some examples of the different types of tests.

[Tim Perkuhn]

The book "Refactoring -- Improving the Design of Existing Code" from
Martin Fowler might possibly be interesting for you.

[Faisal Khan]

Thanks for the excellent suggestions you have all provided me and more so the inspiration to keep going.
Stan - I will read up on mock objects today and come back with more stuff, hopefully that should clear things up for me. As it stands most of what my Beans are doing is fetching vehicle prices, discounts etc and do the calculations.
I may get a copy of JUnit but I haven't really got the time at the moment to read it - I have read a good few articles from www.junit.org - i think once I am rolling I will be fine but its just the getting going part which is hard.