Java Reference
In-Depth Information
The code in this listing is a simple implementation, but it's enough for our needs. We
want our code not only to compile but also to pass the tests.
JUnit best practice: use TDD to implement The Simplest Thing That Could
Possibly Work
The Simplest Thing That Could Possibly Work
is an Extreme Programming (XP)
principle that says overdesign should be avoided, because you never know what
will be used effectively. XP recommends designing and implementing the minimal
working solution and then
refactoring
mercilessly. This is in contrast to the
monu-
mental methodologies
, which advocate fully designing the solution before starting
development. When you're developing using the TDD approach, the tests are writ-
ten first—you only have to implement the bare minimum to make the test pass in
order to achieve a fully functional piece of code. The requirements have been fully
expressed as test cases, and you can let yourself be led by the tests when you're
writing the functional code.
F
INISHING
THE
C
ACTUS
SERVLET
TESTS
At the beginning of the previous subsection, we mentioned that we need to write
three methods:
getCommand
,
executeCommand
, and
callView
. We implemented
getCommand
in listing 14.5. The
executeCommand
method is responsible for obtain-
ing data from the database. We defer this implementation until section 14.5, “Test-
ing
EJB
s.”
That leaves the
callView
method, along with the servlet's
doGet
method, which
ties everything together by calling our different methods. One way of designing the
application is to store the result of the
executeCommand
method in the
HTTP
servlet
request. The request is passed to the
JSP
by the
callView
method (via servlet
for-
ward
). The
JSP
can then access the data to display by getting it from the request (possi-
bly using a
useBean
tag). This is a typical
MVC
Model 2 pattern used by many
applications and frameworks.
We still need to define what objects
executeCommand
will return. The
BeanUtils
package in the Apache Commons (
http://commons.apache.org/beanutils/) in
cludes
a
DynaBean
class that can expose public properties, like a regular JavaBean, but we
don't need to hardcode getters and setters. In a Java class, we access one of the dyna
properties using a map-like accessor:
DynaBean employee = ...
String firstName = (String) employee.get("firstName");
employee.set("firstName", "Petar");
The
BeanUtils
framework is nice for the current use case because we retrieve arbi-
trary data from the database. We can construct dynamic JavaBeans (or DynaBeans)
that we use to hold database data. The mapping of a database to DynaBeans is covered
in the last section.
