If you are interested in the Spring Framework’s MVC packages, this could be helpful. It’s a unified description of the life cycle of a web application or portlet request as handled by Spring Web MVC and Spring Portlet MVC. I created this for two reasons: I wanted a quick reference to the way Spring finds […]
Google have released the Google Web Toolkit — “Build AJAX apps in the Java language”. At first I thought this might just be their version of the Yahoo UI Library, but it turns out to be a completely different approach to the same problem. The YUI Library (and most other Ajax libraries) allow you to […]
Functions that take collection parameters should take the generic parameter. E.g. don’t do this:
public void process(ArrayList list);
This may seem obvious, but many JUnit tests are written that don’t really test anything useful.
Don’t write tests cases for code that’s too simple to fail on its own: that would be a waste of time. You’re supposed to write tests that test your application code, not the test framework or the compiler.
11 August 2004
|
By Bennett
|
Topics: JUnit, Java
|
Import statements provide good documentation, but not if they contain wildcards. For example:
import com.zikzak.db.*;
import com.zikzak.util.*;
No function should ever throw a RuntimeException by design, unless it has documented requirements for its arguments or object state that are not fulfilled. Essentially, it must always be possible for the caller of a function to do enough checking so that it can be sure no RuntimeException will be thrown.
Using throws Throwable and throws Exception subverts the exception checking system. If you do this, callers are forced to catch Throwable or Exception, which may catch both unchecked and checked exceptions. This forces callers to use instanceof to see whether the exception is one that they can deal with.
Put TestCase classes in the same package as the class they are testing. This makes it easy to test protected and package-visible methods. It’s still a pain to test private methods though.
Profiling is an excellent way to find resource bottlenecks in a program. Java has built-in profiling tools that you can use to easily view a profile of a program’s runtime execution.
If a function that returns an object is unable to return the object because of an error, it should not return null. Instead, it should throw some defined exception. This means that the handling for the error can occur at the appropriate place, by catching the defined exception. This appropriate place may be at the […]