Just as a follow-up to the answer given by limc, here's what I was able to do.
I'm using Spring and Hibernate so I was able to take my Spring data config file and turn it into this:
<bean id="sessionFactory" name="sessionFactory"
class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
<property name="dataSource" ref="dataSource" />
<property name="mappingResources">
<list>
...hbm files...
</list>
</property>
<property name="hibernateProperties">
<props>
<prop key="hibernate.dialect">${db.dialect}</prop>
<prop key="hibernate.show_sql">false</prop>
<prop key="hibernate.format_sql">true</prop>
<prop key="hibernate.use_sql_comments">false</prop>
<prop key="hibernate.hbm2ddl.auto">${ddl.create}</prop>
</props>
</property>
</bean>
With that in place, I was able to propertyConfigurer configuration to fill in the placeholders, that looks like this:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:aop="http://www.springframework.org/schema/aop"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop.xsd">
<bean id="propertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location">
<value>classpath:test-messages.properties</value>
</property>
</bean>
</beans>
I have one of those files for my testing and one more for my production code. The one shown above is my testing version and references the file test-messages.properties, that looks like this:
db.dialect=org.hibernate.dialect.HSQLDialect
ddl.create=create
This actually works very nicely as I can reuse virtually all of my production config files by utilizing the placeholders and the propertyConfigurer construct. The only extra files I need for my test environment are the propertyConfigurer config files and the properties files they point to.
Thanks, limc!
As an aside, I do see the issue that limc mentioned. This system is designed to be deployed to connect to a SQL Server database in production, which will not be created via hbm2ddl. So, if there's an error in my HBM files, my tests might all work just fine while I may still get failures in production.
On one hand, I'm very unhappy about that but, on the other, I can actually run test cases against a DB in a fully self-contained way. As it stands with this solution, someone could check this project out of source control and immediately run the test cases without having to do any sort of DB setup. I like that, too. Unfortunately, I haven't yet found a really great way of having both.