[ Pobierz całość w formacie PDF ]
Server in this environment >
dir= ${env.WL_HOME} >
EJB Development Process 165
location= ${env.WL_HOME}/lib/weblogic.jar />
value= ${weblogic.admin.domain} />
value= ${weblogic.admin.server.name} />
value= ${weblogic.admin.password} />
in this environment >
classname= weblogic.Admin >
SHUTDOWN -username ${weblogic.admin.username} -password
${weblogic.admin.password}
/>
The Initialize Database Target
When you readminister a J2EE application environment, you ll typically need
to reinitialize, or perhaps update, the database in that environment. Perhaps
your application requires certain reference data to function correctly. Perhaps
your development process benefits from certain example data always being
available for testing and debugging and new development purposes. Perhaps
you develop and test new functionality against an imported copy of a produc-
tion database, and apply migration scripts to implement schema and data
migration. All of these scenarios require the database in an environment to be
properly initialized before the application can be run.
Assuming an RDBMS, database initialization conceptually consists of two
steps. For the migration scenario, the steps are importing the database of
record, and running the migration scripts. For the nonmigration scenario, the
steps are loading the schema, and loading the reference/example data. The
steps for both scenarios can be implemented by Ant build file targets. The fol-
lowing Ant script shows the implementation assuming Oracle as the RDBMS
in use:
data into DB >
166 Chapter Seven
executable= ${env.ORA81_HOME}/bin/sqlplus >
${database.username}/${database.password}@${database.name}
@createtables.sql />
classname= com.mycompany.mysystem.persistence.DataGenerator
fork= yes >
${database.username} ${database.password}
weblogic.jdbc.oci.Driver />
a dump file >
line= ${database.username}/${database.password}@${database.name}
file=exp.${database.username}.${app.version}.${date}.dmp
owner=${database.username} consistent=y buffer=102400 compress=n />
DB dump (set import.file, import.fromuser) >
executable= ${env.ORA81_HOME}/bin/sqlplus >
${database.username}/${database.password}@${database.name}
@droptables.sql />
${database.password}@${database.name}
file=${import.file} fromuser=${import.fromuser}
touser=${database.username} analyze=no />
EJB Development Process 167
appropriate update scripts >
executable= ${env.ORA81_HOME}/bin/sqlplus >
${database.username}/${database.password}@${database.name}
@migrate.sql />
The Test Targets
Last but not least, it is convenient to implement a target in your Ant build file
to run your unit test suite. This gives you the opportunity to ensure that any
necessary preconditions for running your test suite (for example, started
servers) have been met. Your target will also, once again, encode a required
classpath in this case, the classpath required to run your top-level test suite.
We will have much more to say about unit testing in the following section;
meanwhile, the following example shows a template Ant build file target for
running your unit test suite, assuming JUnit as the unit test framework:
srcdir= test/java
destdir= build/classes
classpathref= classpath.compilation.test
/>
project s test suite >
168 Chapter Seven
classpathref= classpath.runtime.test >
As can see, the test target depends on compilation of the test suite, and
we ve introduced classpaths to use for compiling and running the test suite.
The observant reader may also notice that we compile the test suite classes into
the same directory as the code they re testing. This begs the question of where
to locate your test suite within your project directory and within your set of
Java packages, which are two of the many points on using JUnit that we ll
address in the next section.
Unit Testing with JUnit
Unit testing it s one of those things (like JavaDoc ing) that we all know we
should do, but that tend to get left behind in the race to revenue. Unfortu-
nately this haste leaves us exposed; the lack of a unit test suite is one example
of technical debt (Brown, 2000) that projects and organizations get into.
Let s face it: developing and maintaining and repeatedly running a worth-
while unit test suite costs a nontrivial amount of time and money. But the
appropriate way to view this cost is as an investment in the effectiveness of
your development organization, both now and in the future. As it is made, this
investment pays recurring dividends by reaffirming the confidence of develop-
ers, managers, and customers in the correctness of your application s codebase.
It is a significant milestone on a new project to be able to show successful
execution of a service layer test suite, since this also validates the domain and
persistence layers. Going forward, every time you merge new functionality
into your codebase your unit test suite will tell you whether you have broken
previously working functionality. Later, any time you have to merge code lines
that may have been forked off to support parallel development (of production
bug fixes versus new features, or next-release functionality versus future- [ Pobierz całość w formacie PDF ]
zanotowane.pl doc.pisz.pl pdf.pisz.pl ocenkijessi.opx.pl
Server in this environment >
dir= ${env.WL_HOME} >
EJB Development Process 165
location= ${env.WL_HOME}/lib/weblogic.jar />
value= ${weblogic.admin.domain} />
value= ${weblogic.admin.server.name} />
value= ${weblogic.admin.password} />
in this environment >
classname= weblogic.Admin >
SHUTDOWN -username ${weblogic.admin.username} -password
${weblogic.admin.password}
/>
The Initialize Database Target
When you readminister a J2EE application environment, you ll typically need
to reinitialize, or perhaps update, the database in that environment. Perhaps
your application requires certain reference data to function correctly. Perhaps
your development process benefits from certain example data always being
available for testing and debugging and new development purposes. Perhaps
you develop and test new functionality against an imported copy of a produc-
tion database, and apply migration scripts to implement schema and data
migration. All of these scenarios require the database in an environment to be
properly initialized before the application can be run.
Assuming an RDBMS, database initialization conceptually consists of two
steps. For the migration scenario, the steps are importing the database of
record, and running the migration scripts. For the nonmigration scenario, the
steps are loading the schema, and loading the reference/example data. The
steps for both scenarios can be implemented by Ant build file targets. The fol-
lowing Ant script shows the implementation assuming Oracle as the RDBMS
in use:
data into DB >
166 Chapter Seven
executable= ${env.ORA81_HOME}/bin/sqlplus >
${database.username}/${database.password}@${database.name}
@createtables.sql />
classname= com.mycompany.mysystem.persistence.DataGenerator
fork= yes >
${database.username} ${database.password}
weblogic.jdbc.oci.Driver />
a dump file >
line= ${database.username}/${database.password}@${database.name}
file=exp.${database.username}.${app.version}.${date}.dmp
owner=${database.username} consistent=y buffer=102400 compress=n />
DB dump (set import.file, import.fromuser) >
executable= ${env.ORA81_HOME}/bin/sqlplus >
${database.username}/${database.password}@${database.name}
@droptables.sql />
${database.password}@${database.name}
file=${import.file} fromuser=${import.fromuser}
touser=${database.username} analyze=no />
EJB Development Process 167
appropriate update scripts >
executable= ${env.ORA81_HOME}/bin/sqlplus >
${database.username}/${database.password}@${database.name}
@migrate.sql />
The Test Targets
Last but not least, it is convenient to implement a target in your Ant build file
to run your unit test suite. This gives you the opportunity to ensure that any
necessary preconditions for running your test suite (for example, started
servers) have been met. Your target will also, once again, encode a required
classpath in this case, the classpath required to run your top-level test suite.
We will have much more to say about unit testing in the following section;
meanwhile, the following example shows a template Ant build file target for
running your unit test suite, assuming JUnit as the unit test framework:
srcdir= test/java
destdir= build/classes
classpathref= classpath.compilation.test
/>
project s test suite >
168 Chapter Seven
classpathref= classpath.runtime.test >
As can see, the test target depends on compilation of the test suite, and
we ve introduced classpaths to use for compiling and running the test suite.
The observant reader may also notice that we compile the test suite classes into
the same directory as the code they re testing. This begs the question of where
to locate your test suite within your project directory and within your set of
Java packages, which are two of the many points on using JUnit that we ll
address in the next section.
Unit Testing with JUnit
Unit testing it s one of those things (like JavaDoc ing) that we all know we
should do, but that tend to get left behind in the race to revenue. Unfortu-
nately this haste leaves us exposed; the lack of a unit test suite is one example
of technical debt (Brown, 2000) that projects and organizations get into.
Let s face it: developing and maintaining and repeatedly running a worth-
while unit test suite costs a nontrivial amount of time and money. But the
appropriate way to view this cost is as an investment in the effectiveness of
your development organization, both now and in the future. As it is made, this
investment pays recurring dividends by reaffirming the confidence of develop-
ers, managers, and customers in the correctness of your application s codebase.
It is a significant milestone on a new project to be able to show successful
execution of a service layer test suite, since this also validates the domain and
persistence layers. Going forward, every time you merge new functionality
into your codebase your unit test suite will tell you whether you have broken
previously working functionality. Later, any time you have to merge code lines
that may have been forked off to support parallel development (of production
bug fixes versus new features, or next-release functionality versus future- [ Pobierz całość w formacie PDF ]