Geek Answers Handbook

Unit test using Google reflection library fails only when running Maven

I use the Google Reflection Library to request specific resources in the classpath. These resources are located in the same place as the classes in my project.

I wrote some unit tests that succeed when executed as a unit test in Eclipse, but when I try to run them with Maven (e.g. with maven install ), they do not work properly. After some debugging, apparently the problem is that when executed with Maven, the Reflections library cannot find the URL of the class where the resources are located.

I came to this conclusion by examining how Reflections defines the class URLs that should be checked. As an example, the following method shows how Reflections finds the available class path URLs specified by the class loader (the original Reflections method was slightly simplified):

 public static Set<URL> forClassLoader(ClassLoader... classLoaders) { final Set<URL> result = Sets.newHashSet(); for (ClassLoader classLoader : classLoaders) { while (classLoader != null) { if (classLoader instanceof URLClassLoader) { URL[] urls = ((URLClassLoader) classLoader).getURLs(); if (urls != null) { result.addAll(Sets.<URL>newHashSet(urls)); } } classLoader = classLoader.getParent(); } } return result; }

In short, it moves through the classloader hierarchy, requesting the URLs of each individual classloader.

When in Eclipse I call the previous method from unit test with something like this:

  ClassLoader myClassClassLoader = <MyClass>.class.getClassLoader(); //<MyClass> is in the same classpath url than the resources I need to find Set<URL> urls = forClassLoader(myClassClassLoader); for(URL url : urls) { System.out.println("a url: " + url);

as expected, I see (among many other URLs) the URLs of the classes that are configured as part of my project:

 file:<MY_PROJECT_PATH>/target/classes/ file:<MY_PROJECT_PATH>/target/test-classes/

and Reflections works like a charm (the resources that need to find reflections are in file:<MY_PROJECT_PATH>/target/classes/ ).

However, when the test was run by Maven, I realized that these URL entries are not in the set returned by the forClassLoader method, and the rest of the Reflections methods do not work properly for this problem.

It’s “amazing” that if I write this when unit test runs maven:

 ClassLoader myClassClassLoader = <MyClass>.class.getClassLoader(); url = myClassClassLoader.getResource("anExistingResource"); System.out.println("URL: "+url); //a valid URL

I see that the class loader can still resolve the resource I'm trying to find. I am puzzled by the fact that when running with Maven, the forClassLoader method forClassLoader not include the paths to my project in the returned set of URLs, although at the same time it can resolve resources located at such URLs (!).

What is the reason for this behavior? Is there any workaround that I can try to make the Reflections library when called as part of the unit test executed by Maven?

+6
source share
4 answers

You are probably using M2Eclipse, which in itself adds stuff to the classpath. The Maven command line works differently. You may find some options that will help .

+3
source

I decided. Publishing a solution in case someone finds the same problem in the future.

When performing unit tests on a project, Maven does not (explicitly) include all of its dependencies in the pathpath. Instead, it declares a dependency on jmp tmp located in "target / surefire / surefirebooter_NUMBER_THAT_LOOKS_LIKE_TIME_STAMP.jar". This banner contains only a manifest file that declares the class path for the project.

The forClassLoader method in the Reflections library does not return a set of URLs with an effective class (i.e. entries in the classpath in the manifest files are ignored). To overcome this, I simply implemented this simple method:

 public static Set<URL> effectiveClassPathUrls(ClassLoader... classLoaders) { return ClasspathHelper.forManifest(ClasspathHelper.forClassLoader(classLoaders)); }

The forManifest method (also part of the Reflections library) adds to the set of URLs of the path sent as a parameter, missing class path entries declared in the manifest files of any jar files contained in the set. Thus, the method returns a set of URLs with an effective class of the project path.

+4
source

I had the same problem. Adding the following URL did the trick for me.

 ConfigurationBuilder cb = new ConfigurationBuilder(); cb.setUrls(...); cb.addUrls(YourClassName.class.getProtectionDomain().getCodeSource().getLocation());
+2
source

There are several problems you can create that make failfire fail.

  • there is a naming convention; the test suite should be called "TestBlaBla" or "BlaBlaTest"; beginning or ending with the word "Test".

  • as mentioned earlier, the class path in Maven is more limited than in Eclipse, since Eclipse (stupidly) does not separate the compilation class path from the test class path.

  • Surefire can run test cases from different test suites in any order. When you run multiple test suites that initialize some common database (such as an in-memory database or JNDI context) that can create conflicts when the test suites begin to influence each other. You need to take care to properly isolate the test kits. The tricks I use are to use separate in-memory databases for the sets, and I initialize the general things behind a unit test instead of each set of tests.

3 hardest to debug, I can tell you; whenever something works in Eclipse and not in Maven, I naturally believe that I am doing something wrong in isolating the test suite.

0
source

More articles:


All Articles