[ Pobierz całość w formacie PDF ]
gation hierarchies, associations, and so on, to support all of the functionality of
EJB Development Process 175
the application (and therefore its testing). Of course the test data set, and the
schema it populates, will evolve over time on your project so they need to be
maintained and enhanced as your application grows and changes.
There are two general approaches to creating and maintaining a test data
set: you can write a program to generate it, or you can enter the data through
your application s user interface into a database that you would maintain and
migrate just as you would any other database (for example, a production,
training, or demo database). Both approaches have advantages and disadvan-
tages; but with the latter approach you may have the opportunity to get some
repetitions in database migration before assuming the (serious) responsibility
of maintaining and migrating a production database.
As test methods execute, they will likely cause transactional changes to the
database containing the test data set. In keeping with JUnit s philosophy, your
test methods should clean up after themselves and leave the test data set in the
same state in which they found it. Given the approach of creating a TestCase
class per target class being tested, this often means the cleanup logic has to be
invoked from the test method itself a TestCase class s tearDown() method
won t necessarily know which test method was run and thus which of the tar-
get class s methods was tested and, therefore, what needs to be cleaned up.
Who Should Write the Tests?
The developer who wrote the code being tested is the person who should write
the tests for that code. No one else has a better idea of what that developer s
intentions were as the code was being written, and therefore what tests are
indicated. No one else has a better understanding of the internal workings of
that code, and therefore its input ranges, conditional paths, and normal and
exceptional circumstances.
Some organizations suggest that junior programmers with time on their
hands be assigned to write unit tests for other people s code. We feel this is an
anti-pattern. It is likely that the resulting unit tests will not be complete or even
correct; therefore, it is likely that the target code will not be adequately tested.
Finally it is likely that productivity will decrease as a result of the unit test
developer having to ask the target code developer about the latter s intentions.
Developers should be responsible for writing their own unit tests period.
It is just a regular part of being a professional software developer.
When to Run Tests?
Perhaps a better question to ask would be how often should we run tests of a
particular granularity? We ve seen that a J2EE application s unit test suite can
test at different levels of granularity from the entire application, to a certain
layer of architecture, to a certain class within a layer, to even a certain method
within that class.
176 Chapter Seven
Depending on how your team has chosen to organize and partition work,
chances are that you are responsible for a given layer of architecture, or a given
vertical subsystem that slices through all layers. As development proceeds,
you ll likely run unit tests at the method or class level of granularity with very
high frequency because you ll be adding methods or classes to your layer, or
functionality to your subsystem, and you ll want to test it as soon as you ve
coded and compiled it. Every time you complete the implementation of a
method, or class, or development task, you will have also completed and run
the concomitant additions to your unit test suite that test the code you com-
pleted. Occasionally you ll want to run an entire layer s test suite, or perhaps
selected TestCase subclasses from the application layer or service layer test
suites that exercise a specific subsystem.
When you re ready to check your code in to the source code control system,
you should run the entire application s test suite. If you can t check in because
your project directory isn t up to date with the repository, you should run the
entire application s test suite after updating your project directory (and decon-
flicting any merges that occurred in the process).
Finally, after successfully checking in, you may want to take the opportunity
to completely readminister your development environment, starting by delet-
ing your local project directory and getting a fresh checkout from the source
code control system. And, of course, the final step in readministering your
environment is to run the entire application s unit test suite.
This goes for nondevelopment environments, as well. Any time any environ-
ment is readministered, the entire application s test suite should be run in that
environment. Thus, when code is promoted from development to the QA,
demo, or production environment, the unit test suite is run in that environment.
Basically the idea is to run tests, at the appropriate level of granularity, fre-
quently enough to ensure that the codebase deployed in the environment (and
[ Pobierz całość w formacie PDF ]