I have muli moduled maven based application. There are several change sets in each module. I want to write integration tests in one of them. I know it's bad idea but, i have business log constraints.
In considered module i have code that uses repositories from 2 others modules. During tests i have to initialize tables from change sets in different modules. I don't know how to use absolute path to change sets or how to use liquibase config.
I tried use include or includeAll tags, but in classpath where tests run i can't call change sets out of module.
Hope for your ideas.
you should be able to create liquibase instance in your junit by passing absolute file paths. You can refer liquibase tests in github for more info
new Liquibase(changeLogFile, FileSystemResourceAccesor, database);
https://github.com/liquibase/liquibase/blob/master/liquibase-integration-tests/src/test/java/liquibase/dbtest/AbstractIntegrationTest.java#L890
Related
We are trying to use spring-test's SpringExtension to write integration tests for our Spring and Hibernate-based Tomcat web application. Our sessionFactory bean configuration has the property configured mappingJarLocations with a sample value as /WEB-INF/lib/company-common*.jar which contains hibernate mapping files. In both actual deployment and Eclipse dev deployment, this works fine as the docBasePath (in Servlet environment) is appended to this pattern and the files are getting resolved. But this is not the case while running JUnit test cases either in a local or a CI environment.
We tried our best to use the provided support by having few overridden implementations of WebTestContextBootstraper, GenricXmlWebContextLoader, XmlWebApplicationContext, and WebDelegatingSmartContextLoader but had to finally give up as we cannot override the final method org.springframework.test.context.web.AbstractGenericWebContextLoader.loadContext(MergedContextConfiguration) to provide the custom implementation of XmlWebApplicationContext. Our current approach is to manually create the application context and use it in the tests.
Here is the project structure:
Project_WebApp
|--src/**
|--WebContent/**
|--pom.xml
When the app is packaged as Project_WebApp.war, the dependencies are inside WEB-INF/lib from the root of extracted war. When deployed as a webapp in Tomcat using Eclipse, the dependencies are copied to <Eclipse_Workspace_Dir>/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/Project_WebApp/WEB-INF/lib. In both cases, the dependencies are available at <Resource_Base_Path>/WEB-INF/lib and Resource_Base_Path has no relation to Project_WebApp base directory.
Questions:
Did any one use SpringExtension in a scenario similar to above? If so can you suggest any alternative approaches?
Instead of /WEB-INF/lib/company-common*.jar, we tried a classpath-based pattern but didn't work as the obtained class path resources don't match the pattern. Is there anything else to try here?
I would like to test that a spring
#Configuration class
can handle missing files on the classpath. E.g. when using PropertySourcesPlaceholderConfigurer. But this is just a specific example, the question is really about how to test classes that interact with the classpath (e.g. read a file located in src/main/resources in a maven project).
So in essence I would like to create a spring context where I control the classpath in the test set up code.
The test needs to be a JUnit test.
Hope below may help you
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(locations = {"classpath*:/testApplicationContext.xml"})
public class YourTestClass{
you have to create a spring context for your test and you can include the production one into it. you can replace classpath*: with a absolute location.
Regards, Rajib.
This work if it's a maven project:
move the classpath file that you want to test the absence from to a separate pom jar module, and include it wherever needed.
move the classpath test to a separate pom jar module named missing-classpath-file-test, but don't include the module with the file that you want to simulate as missing. I will be missing from the classpath only for that test.
When running missing-classpath-file-test, the file will not be on the classpath, and the error you need to reproduce is achieved.
Concerning the question on the comment bellow, with the class loaders that come with application servers and the one used on a junit test it's not possible to programmatically change the classpath.
I've read some questions here about how to set a property (most of them talked about the version number for an application) from a maven plugin.
It seems there's no easy way of doing this and the best solution I found is to have a filter.properties file which is updated from the plugin and used by the main pom file to filter the desired resources.
I tried another solution after I read this from the Maven documentation (Maven filter plugin):
Variables can be included in your resources. These variables, denoted
by the ${...} delimiters, can come from the system properties, your
project properties, from your filter resources and from the command
line.
I found interesting that variabled can be read from system properties. So, I modified my plugin to set a system property like this:
System.setProperty("currentVersion", appCurrentVersion);
However, filtered resources don't seem to read this value.
Could anybody tell me what's wrong with this approach?
UPDATE: I'm running my plugin in the validate phase.
Thanks a lot.
Don't set it as System Property, set it as Maven Project property
// inject the project
#Parameter(defaultValue = "${project}")
private org.apache.maven.project.MavenProject project;
// and in execute(), use it:
project.getProperties().setProperty("currentVersion", appCurrentVersion);
See:
Mojo Developer Cookbook
MavenProject javadoc
An edit suggested using Properties.put() instead of Properties.setProperty(). While technically, Properties implements Map, this usage is discouraged explicitly in the Properties javadoc.
Maven sets properties in initialize phase. I assume that in that phase maven loads system properties. And after that maven doesn't load system properties again. If you try to add a system property after this phase than it's not loaded.
Try to run your plugin in validate phase.
Here's the facts :
I have 2 jars that contain JPA entities in my webapp,
and entities from one jar (jar A) has references of entities in another jar (jarB)
I put the <jar-file>/WEB-INF/lib/MyJarB.jar</jar-file> in the persistence.xml of jar A
But i dont want to hardcode the /WEB-INF/lib/MyJarB.jar because i could be testing the entities in a test environment, and would love to have another way of specifying entities jar dependencies other than hardcoding the path.
I tried the <jar-file>MyJarB.jar</jar-file> and <jar-file>./MyJarB.jar</jar-file>, but both failed.
Please share your thoughts.
Create another persistence.xml for pure testing only and put it in project B itself or another sub-project which contains test classes.
I recommend NOT putting the persistence.xml together with your JARs, because the persistence definition is the application concern. Therefore it would be better to have a persistence.xml in your web module, declaring both JARs:
<jar-file>/WEB-INF/lib/MyJarA.jar</jar-file>
<jar-file>/WEB-INF/lib/MyJarB.jar</jar-file>
In case you have tests in your web module, and you want to use another persistece definition, just create an alternate persistence.xml, say in src/test/resources, and just use that one to instantiate your EntityManagerFactory.
I'm using maven war plugin to build war package.
Before package is build test are executed. To preinitialize my database with sample data I use spring bean. I would like to have different data in my db for tests and different when application starts.
I was thinking that maybe it is possible to use two different spring initializer classes in 'test' and 'war' phases but I don't know how to achieve this.
You have to put the different classes you need into src/main/java or src/test/java or may be supplemental application.xml into src/main/resources or src/test/resources. The test initializer can be done by a Test class which initializes first before all tests are running (take a look at testng which has this kind of feature).
Your tests should not be using the production Spring context (xml) files.
Instead, if you need to access an ApplicationContext in your tests (or if you are using a base testcase class like AbstractTransactionalJUnit4SpringContextTests), set up a test-context.xml context which points to the test database configuration and the test data scripts.