Java Reference
In-Depth Information
.will(returnValue(new Person(PERSON_ID)));
PersonService service =
new PersonService((PersonDao)mock.proxy());
new Person(new Integer(1)), new Integer(1));
assertNotNull("Expected non-null person instance.",
assertEquals("Expected ID to be " + PERSON_ID,
PERSON_ID, person.getId());
assertTrue("Expected valid person.",
Again we're making use of both JU nit and JM ock. As you can see in listing 13.6,
the testing approach is consistent at each layer of the application. This is a good
thing, as it makes for simple, focused unit tests that are easy to maintain.
That's as far as we'll go with unit testing for i BATIS . There are a number of
great resources that discuss unit testing in general. Try a Google search for “unit
testing.” You'll find plenty to help you to improve your unit-testing skills and per-
haps discover even better ways than those described here.
13.2 Managing iBATIS configuration files
By now it's pretty clear that i BATIS uses XML files for configuration and statement
mapping. These XML files can become unwieldy very quickly. This section dis-
cusses some best practices for organizing your SQL mapping files.
Keep it on the classpath
Location transparency is one of the most important aspects of application maintain-
ability. It simplifies testing and deployment of your application. Part of location
transparency is keeping your application free of static file locations such as /usr/
local/myapp/config/ or C:\myapp\ . Although i BATIS will allow you to use specific
file locations, you are better off using the classpath. The Java classpath is helpful
when you want to keep your application free of any specific file paths. You can
think of the classpath as a mini file system that your application can refer to inter-
nally through the use of a classloader. A classloader is able to read resources from
the classpath, including classes and other files. Let's take a look at an example.
Imagine the following file structure on your classpath:
Search WWH ::

Custom Search