Can someone please suggest a good book on JUnit that goes into detail on how to write tests for methods that do thing like read a file and populate an object's attributes?
I've been wondering how I would go about writing a test for a class where a method opens and reads a file ion order to populate another class (a bean) with the file contents (or rather a record from the file). What is the best practice for this sort of thing?
> Can someone please suggest a good book on JUnit that
> goes into detail on how to write tests for methods
> that do thing like read a file and populate an
> object's attributes?
There are a lot of articles on http://www.junit.org/ ... I'd suggest reading at least some of them to get an idea about approaches to testing.
> I've been wondering how I would go about writing a
> test for a class where a method opens and reads a file
> ion order to populate another class (a bean) with the
> file contents (or rather a record from the file).
> What is the best practice for this sort of thing?
One approach is to keep the file in a known location, and simply read it. This isn't a particularly good approach, as the file might not be in the expected location when the test gets run.
And, when you think about it, it may not be the best application design either, for the same reason.
An alternative is to define your "populate" method so that it takes an arbitrary InputStream or Reader object. For testing, this means that your test can pass a ByteArrayInputStream or StringReader object that it builds locally, and you'll always have complete control over expected results. For the production app, it means that you can get the actual data from multiple sources, and won't have to recode the populate method to deal with the different possibilities.
It's one thing to write a method that takes two params say, A and B, and adds them together. it is easy to write a test for this because it doesn't rely on anything outside of the testing framework. But what does one do when a method needs data from a file or a database or some other store? How can one write a JUnit test when control over test data in a database is not controllable? In other words, I don't control the test data but yet, I have to write a test for a method that reads in data from a database where that data is not guarenteed to be consistent.
The test data can be given in an XML file as standard XML parsing APIs are available in Java
This gives the advantage that XML file name can be given as an argument to Tester class and the test fixtures are initialized by reading the XML file
Even the function to be tested can be varied at run time
First off, JUnit testing assumes that you have complete control over the test environment.
You have the setUp() method to prepare the environment for your test, and the tearDown() method to clean up afterward. In many cases, you can populate your database in the former, clean it up in the latter, and know exactly what you're working with.
If you can't use these methods to change the database (or whatever), then it's time to reduce the size of your tested environment to something that you can control.
For example, if your application reads some data from the database, you can simulate that by manually creating the relevant objects in the setUp() method ... or even within the test methods. But wait, you say, the objects that you're testing access the database themselves. My response is that this indicates a problem with your design: persistence and operation are too tightly coupled.
On the other hand, it's possible that your test plans aren't appropriate for automated testing.
After some heavy reading, I agree, good testing environment employs good design concepts to begin with.
Smaller testable objects are preferred over large bloated ones. An archuitecture that lends itself to testing is also preferrable. For example, instead of trying to test an application that is initiated by a webserver by trying to create an HTTPRequest object yourself, use the ApplicationController and ContextObject patterns to separate the "app" from the "servlet" that way, testing can be done with the "app" frrom junit much easier since it simply has to call the "app" with a contextObject instead of an HTTPReques object.
The Core J2EE Patterns book was really helpful in this regard.
