...
It
...
is
...
important
...
to
...
run
...
your
...
unit
...
tests
...
against
...
multiple
...
versions
...
of
...
OpenMRS.
...
Fortunately,
...
Maven
...
helps
...
facilitate
...
this
...
through
...
the
...
use
...
of
...
configurable
...
properties
...
and
...
build
...
profiles.
...
The Html Form Entry module has been modified to allow unit testing against different version of OpenMRS. Some examples from that module are listed below, but also take a look the the module poms themselves for the full gory details.
In the standard module pom configuration, the version of OpenMRS to use is specified as a maven property which can we overriden at the command line. The following pom snippet defines the OpenMRS version to use as 1.6.3. This version is referenced elsewhere throughout the module poms.
| Code Block |
|---|
<properties> <openMRSVersion>1.6.3</openMRSVersion> </properties> |
To
...
change
...
the
...
OpenMRS
...
version,
...
you
...
can
...
simple
...
override
...
this
...
property
...
on
...
the
...
command
...
line
...
using
...
the
...
-D
...
parameter:
...
| Code Block |
|---|
mvn \-DopenMRSVersion=1.7.1 test |
This
...
works
...
for
...
the
...
simplest
...
cases,
...
but
...
things
...
quickly
...
become
...
more
...
complex.
...
Compiling and testing against OpenMRS 1.8
...
and
...
higher
...
requires
...
a
...
different
...
dependency
...
structure
...
than
...
earlier
...
versions
...
of
...
OpenMRS.
...
You can configure your module poms using *maven profiles. *As an example. here is a pom that has been configured to have build profiles for both 1.6 and 1.8:
First, configure all the common dependencies between 1.6 and 1.8 as normal:
| Code Block |
|---|
<dependencyManagement> <dependencies> <dependency> <groupId>org.openmrs.api</groupId> <artifactId>openmrs-api</artifactId> <version>${openMRSVersion}</version> <type>jar</type> <scope>provided</scope> </dependency> <dependency> <groupId>org.openmrs.web</groupId> <artifactId>openmrs-web</artifactId> <version>${openMRSVersion}</version> <type>jar</type> <scope>provided</scope> </dependency> </dependencies> </dependencyManagement> |
Then
...
create
...
to
...
separate
...
profiles
...
to
...
define
...
the
...
version-specific
...
dependencies.
...
Note
...
that
...
the
...
OpenMRS
...
version
...
property
...
is
...
specified
...
within
...
the
...
profiles
...
as
...
well.
...
| Code Block |
|---|
<profiles> <profile> <id>openmrs-1.6</id> <properties> <openMRSVersion>1.6.3</openMRSVersion> </properties> <dependencyManagement> <dependencies> <dependency> <dependencyManagement> <dependencies> <dependency> <groupId>org.openmrs.test</groupId> <artifactId>openmrs-test</artifactId> <version>${openMRSVersion}</version> <type>jar</type> <scope>test</scope> </dependency> </dependencies> </dependencyManagement> </profile> <profile> <id>openmrs-1.8</id> <properties> <properties> <openMRSVersion>1.8.2</openMRSVersion> </properties> <dependencyManagement> <dependencies> <dependency> <dependencyManagement> <dependencies> <dependency> <groupId>org.openmrs.api</groupId> <artifactId>openmrs-api</artifactId> <version>${openMRSVersion}</version> <type>test-jar</type> <scope>test</scope> </dependency> <dependency> <groupId>org.openmrs.web</groupId> <artifactId>openmrs-web</artifactId> <version>${openMRSVersion}</version> <type>test-jar</type> <scope>test</scope> </dependency> <dependency> <groupId>org.openmrs.test</groupId> <artifactId>openmrs-test</artifactId> <version>${openMRSVersion}</version> <type>pom</type> <scope>test</scope> </dependency> </dependencies> </dependencyManagement> </profile> </profiles> |
You'll
...
have
...
to
...
modify
...
your
...
api
...
and
...
omod
...
poms
...
in
...
a
...
similar
...
way.
...
Check out the Html Form Entry poms in the github respository to see how it's done.
Now to test/compile against 1.6 or 1.8 you specific a profile on the command line using the -P parameter:
| Code Block |
|---|
mvn -Popenmrs-1.6 clean install |
Beyond
...
this
...
step,
...
you
...
may
...
find
...
other
...
customizations
...
required
...
to
...
get
...
test
...
scripts
...
to
...
run
...
against
...
different
...
versions
...
of
...
OpenMRS.
...
Different versions of OpenMRS require/use
...
different
...
versions
...
of
...
the
...
logic
...
module,
...
so
...
unit
...
tests
...
that
...
test
...
logic
...
must
...
have
...
the
...
proper
...
logic
...
dependency.
...
One way to do this is to specify the logic version as a maven property, and then define that version in a specific build profile:
| Code Block |
|---|
<!- snippet from the html form entry omod pom \--> <dependency> <groupId>org.openmrs.module</groupId> <artifactId>logic</artifactId> <version>${logicVersion}</version> <scope>provided</scope> </dependency> <\!-\- snippet from the main html form entry omod pom \--> <profile> <id>openmrs-1.6</id> <properties> <openMRSVersion>1.6.3</openMRSVersion> <openMRSMinorVersion>1.6</openMRSMinorVersion> <logicVersion>0.5</logicVersion> </properties> .... </profile> |
If
...
you
...
have
...
defined
...
test
...
datasets
...
within
...
your
...
module,
...
another
...
problem
...
you
...
may
...
run
...
into
...
is
...
that
...
a
...
dataset
...
is
...
only
...
compatible
...
with
...
a
...
specific
...
version
...
of
...
OpenMRS
...
due
...
to
...
data
...
module
...
pages.
...
One way to get around this is to create a .properties file that sets the dataset xml file to use via a maven property, and then use this .properties file within the test scripts.
| Code Block |
|---|
<!- openMRSMinorVersion is a maven property defined in a build profile (see above) \--> drugOrderElementDataSet =drugOrderElement-openmrs-${openMRSMinorVersion}.xml htmlFormEntryServiceDataSet =HtmlFormEntryService-data-openmrs-${openMRSMinorVersion}.xml regressionTestDataSet =RegressionTest-data-openmrs-${openMRSMinorVersion}.xml |
Again,
...
the
...
full
...
example
...
can
...
be
...
found
...
by
...
looking
...
at
...
the
...
Html
...
Form
...
Entry
...
module
...
code
...
in
...
the
...
github
...
repository.