使用不同的Spring属性进行集成测试 [英] Using different Spring properties for integration tests

问题描述

我正在使用Selenium测试一个使用Spring开发的Web应用程序来检查Web应用程序是否为用户显示了正确的内容，并且他能够执行规范中的所有操作。

I am testing with Selenium a web application developed with Spring to check that the web application displays the right stuff for the user and that he's able to do everything that is in the specification.

其他开发人员正在使用内存中的假Hibernate数据库（HSQLDB）进行单元测试。显然，我必须使用程序使用的真实数据库进行测试。 Spring应用程序上下文的JDBC参数由Spring在运行时加载（或编译时用于构建WAR文件）。 Spring使用org.springframework.beans.factory.config.PropertyPlaceholderConfigurer找到的属性来配置webapp和测试的应用程序上下文，XML配置文件由测试和webapp共享。

The other developers are using a fake Hibernate database in memory (HSQLDB) for unit testing. I have to use the real DB used by the program for testing, obviously. The JDBC parameters for the Spring application context are loaded by Spring at runtime (or compile time for building the WAR file). Spring use properties found by org.springframework.beans.factory.config.PropertyPlaceholderConfigurer to configure the application context for the webapp and the tests, and the XML configuration files are shared by the tests and the webapp.

根据Maven配置文件，单元测试或集成测试，属性需要有所不同。

The properties need to be different depending on the Maven profile, unit tests or integration tests.

我尝试了几种方法，但没有成功：

I tried several approaches, without success:

• 使用较低级别的SQL查询开发自己的DAO。这是浪费时间和最后的解决方案。由于外键约束和数据库模型的更改，并且鉴于应用程序具有非常可靠（经过单元测试）的DAO集，它确实是最愚蠢的选项。



• 使用Maven过滤器并在那里定义JDBC属性。问题是属性在主应用程序和单元测试之间共享，因为tomcat：redeploy目标包括单元测试。然后，应用程序无法连接到真正的数据库。



• 在不同的文件夹中具有不同的属性。 Spring根本不关心配置文件的Surefire配置中定义的其他资源，无论是使用 testResources 还是资源。奇怪的是，这种方法非常适用于为主应用程序中的每个环境提供不同的JDBC参数。我们在src / main / resources中有几个文件夹，其中包含覆盖src / main / resources中默认属性的属性。它对src / test / resources的工作方式不同。我甚至不知道如何找到这种行为的原因。



• 让Spring根据用户定义的Maven参数加载不同的属性文件。相同的属性用于主应用程序和单元测试。当它无法找到属性文件时Spring也会抱怨（强迫我创建带有空文件的目录只是为了让构建完成）。

• developing my own DAO's using lower-level SQL queries. It's a real waste of time and solution of last resort. Because of the foreign key constraints and database model changes, and given that the application has a pretty solid (unit-tested) set of DAO's, it's really the dumbest option.
• using Maven filters and define the JDBC properties there. The problem is that the properties are shared between the main application and the unit tests, because the tomcat:redeploy goal include unit tests. The application then cannot connect to the real DB.
• having different properties in different folders. Spring doesn't care at all about the additional resources defined in the profiles' Surefire configuration, either with testResources or resources. The strange thing is that this approach works perfectly well for having different JDBC parameters for each environment in the main app. We have several folders in src/main/resources which contains properties overriding the default properties in src/main/resources. It just doesn't work the same way for src/test/resources. I don't even know how I could find the cause of this behavior.
• have Spring loading different property files based on user-defined Maven parameters. The same properties are used for the main app and the unit tests. Spring also complain when it cannot find the properties files (forcing me to create directories with empty files just to get the build completing).

为什么当前的构建配置与开发人员配置文件（开发人员，测试服务器......）+测试配置文件（单元测​​试）同时运行且属性没有相互覆盖？因为Maven会在启动单元测试时使Spring查看src / test / resources，并在启动构建目标时查看src / main / resources。不幸的是，没有像这样的集成测试的默认配置。

Why is the current build configuration, with the developer profile (developer, test server...) + the test profile (unit tests) activated at the same time running and the properties not overriding one another? Because Maven will make Spring look at src/test/resources when the unit tests are launched and src/main/resources when the build goal is launched. Unfortunately, there is no default configuration for integration tests like this.

推荐答案

我们这样做的方法是选择属性归档变量，因此Spring中的属性占位符如下所示：

The way we do it is base the selection of the properties file off a variable, so property place holder in spring looks like this:

<context:property-placeholder location="classpath:db.${TARGET_ENV}.properties" />

然后您可以选择将TARGET_ENV定义为环境变量或使用-DTARGET_ENV将其传递给maven = ...

And then you have a choice of defining TARGET_ENV as an environment variable or passing it to maven using -DTARGET_ENV=...

这篇关于使用不同的Spring属性进行集成测试的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！