Appendix A. Development tips for portable applications 307
sticking to the class and method contracts the developer is more likely to achieve
the desired outcome: a module that is going to pass Unit Test first time around.
Local comments best practice: why, not what
During coding, code should be commented where necessary. The comments we
are talking about in this case are not JavaDoc comments. They are local
comments written at some point in an algorithm inside a method body. The
general best practice rule of thumb for writing effective comments is that the
comments should explain 'Why?' and not 'What?'. Well-designed, well-written
code is itself a documentation of what is happening. If code is so poorly designed
or esoterically written that it is not clear what is happening then the developer
should consider being more explicit in their coding style or re-factoring the code.
Why something is being done is not always so clear locally. Variables and
method calls often come from separate modules. Non-procedural languages do
not put everything in front of the developer at the same time. Explaining why
something is being done in a particular way is what local comments should be
Saving time in code reviews
Good documentation of code saves time during code reviews. It allows other
developers to read code more easily. It also cuts down on findings from reviews.
One of the major, and unnecessary, types of finding in code review is the need
for more accurate JavaDoc and local comment blocks, if those blocks are found
Unit testing is the testing of discrete modules to ensure that their interfaces take
the correct inputs and give the correct outputs on the basis of those inputs.
Having properly implemented unit tests results in code has many benefits
compared to untested code including:
Easier to detect a broken build
Run the tests automatically at each build. If the tests are not completed
successfully, the code cannot be deployed.
The application has at least two clients
The test case and the application itself. This leads to better designed code
which is less tightly coupled.
308 Migrating Applications from WebLogic, JBoss and Tomcat to WebSphere V6
Easier to refactor
It is easier to make the decision to refactor the code, since you have test
cases that automatically verify that your application is working after the
refactoring is done.
The application is better documented
By creating unit tests that use your code, you are automatically documenting
how the code is used.
Easier to verify migration
It is easier to verify that the application works after having migrated it.
Next, we introduce two tools that can be used for automating tests, and one
which helps in assessing the amount of code that is being tested.
Rational Application Developer V6 includes support for implementing and
running unit tests implemented with JUnit. There are wizards for generating test
projects that use test templates for testing different types of modules. Templates
for simple method testing, interface testing and EJB testing are all supported. In
each case, JUnit test cases are generated and can be tweaked by the developer
JUnit is also available as a standalone package that can be downloaded and run
outside of Rational Application Developer V6, for example Ant build scripts.
For further information about JUnit, refer to the Rational Application Developer
V6 product documentation, visit the following URL:
The following sections discuss some JUnit best practices.
Code unit tests first
Planning and implementing unit tests before the actual application code is
sometimes referred to as Test Driven Development (TDD). TDD is an agile
process that provides many benefits including helping you implement code that
is properly tested and that is less tightly coupled.
Tests that are written according to the TDD process usually follow these simple
Plan the test case
What do you want to test and how? Plan the assertions that are needed to
verify that the test is successful.