[dna-issues] [JBoss JIRA] Commented: (DNA-521) Define infrastructure for testing with multiple DBMSes
Randall Hauch (JIRA)
jira-events at lists.jboss.org
Wed Sep 16 16:54:23 EDT 2009
[ https://jira.jboss.org/jira/browse/DNA-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12486170#action_12486170 ]
Randall Hauch commented on DNA-521:
-----------------------------------
The parent POM file was changed to define a new profiles for each database configuration, and each profile defines the dependencies and properties for the JPA Source objects used in the unit and integration tests.
For the most part, I followed Hibernate's example. Hibernate's POM is such that the database profile is specified explicitly on the Maven command (e.g., 'mvn -Poracle9i ...'), and thus is able to define a 'default' database profile that is used when no other profile is specified. However, this means that if ANY other profile is explicitly used on the command line (e.g., 'mvn -Pintegration ...'), the default database profile is not used, and in effect NO database profile is used. This causes a locking up of the build process.
jBPM's approach of using a property to refer to the database profile is actually superior in this respect, since there is a default database profile that is run when the "database" property is not set. Thus, the database profiles and the other profiles remain orthogonal and independent. Yet another advantage to this approach is that it encourages specifying only one database profile. The cost is a bit more verbosity in the parent POM. So, 'mvn -P integration clean install' still runs the integration builds as before (using the HSQLDB database), and to use a different database simply set the 'database' property to the name of the database profile. For example, 'mvn -P integration -Ddatabase=oracle9i clean install' runs the integration tests against the 'oracle9i' database.
Note that it still is possible to specify the database via the '-P' flag, but then be sure to always include a database profile when using another profile. For example, "mvn -P integration,oracle9i ..." does work.
The JPA unit tests were changed to read a resource file and set the JpaSource bean properties using the values in that resource file. This resource file is simply a properties file where the values are substituted by Maven during the build with the properties in the selected profile. Thus, each database profile can actually set any and all of the JpaSource bean properties (tho some integration tests explicitly override some of the property values, since they are related to the tests being run). A number of database profiles has been added, but these will be updated as we acquire database instances in the QA lab.
The integration tests that use a JPA connector all work in a similar manner, except that the integration tests already load the DNA configuration from an XML file. Here also the XML file (and the 'dna-integration-test/pom.xml' file) was changed so that Maven would substitute the properties in the database profile.
The short summary is this: simply change or add the appropriate database profile in the parent POM file, and then specify the DBMS that should be used by including the '-Ddatabase=dbprofilename' parameter on the command line. That's it.
> Define infrastructure for testing with multiple DBMSes
> ------------------------------------------------------
>
> Key: DNA-521
> URL: https://jira.jboss.org/jira/browse/DNA-521
> Project: DNA
> Issue Type: Task
> Affects Versions: 0.6
> Reporter: Randall Hauch
> Assignee: Randall Hauch
> Fix For: 0.7
>
>
> We need to support easily testing the different aspects of DNA (primarily integration testing, but including the JPA connector testing) on different DBMS systems. There are several ways of doing this, but one seemingly attractive way is to define a Maven profile for each DBMS to define the dependencies, custom repositories for drivers, and Maven properties that define the database connection information. Each project can then be done in a database-agnostic manner, where database-related information (e.g., connection properties, driver names, etc.) can be placed in a property file within the project's "/src/test/resources" area and defined in terms of the Maven properties. Then the Maven build (or just test runs) can be executed by supplying the desired DBMS profile; ideally, the normal build process would be completed, and then the tests can be run using the different DBMS profiles.
> The jBPM4 project defines the profiles in their parent POM [1], while the Hibernate project defines them is their "testsuite" project's POM [2]. I actually like how jBPM defines it in the parent POM, but I like how Hibernate's POM defines and organizes their profiles. Also note Hibernate's use of one DBMS profile (currently HSQLDB) as the default, meaning that all tests would normally pick that up. Also, an example of a Hibernate test resource file that picks up the Maven properties is at [3].
> [1] https://anonsvn.jboss.org/repos/jbpm/jbpm4/trunk/pom.xml
> [2] https://anonsvn.jboss.org/repos/hibernate/core/trunk/testsuite/pom.xml
> [3] https://anonsvn.jboss.org/repos/hibernate/core/trunk/testsuite/src/test/resources/hibernate.properties
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the dna-issues
mailing list