A couple of posts ago I mentioned the incompatibility between Lombok and the AspectJ Eclipse plugin. Of course, JUnit tests also suffer from the incompatibility. Today I've been looking for a solution to that problem.
The incompatibility is caused by both AspectJ and Lombok extending the Java editor at the same time and in the same way, so there is little hope this bug is going away soon. I suspect both plugins use the same Eclipse extension point, and the corresponding classes are derived from the same JDT's base classes. No matter what the reason is, you have to choose either AspectJ or Lombok, and my team chose Lombok.
We avoided the trouble by simply not installing AspectJ. Liferay requires us to use a build script anyway, and we simply included a few lines calling the
However, if we start the JUnit test cases inside Eclipse using the menu command Run as -> JUnit Test, our avoidance strategy fails. The tests only know the classes generated by Eclipse. But that's the wrong version, the version without the woven aspects. Our application relies heavily on the aspects, so there's no way to get the bar green! Most tests will crash immediately.
Currently, three solutions crossed my mind:
-
We could look for a project builder that weaves the aspects when Eclipse compiles the code. We could even write one ourselves (that doesn't seem to be too difficult, as you can read here or here).
-
We could run the class JUnitCore directly and pass it the fully qualified name of the JUnit test case class. If you are willing to write a few lines of code, you can add the automatic detection of every test case and a window showing the green or red bar.
-
You do without the green bar and use a dedicated build script to run your tests.
We decided to use the build script because we have got a lot of experience writing build scripts. A simple build script running every test case in the directory "JUnitTests" looks as follows:
The test results won't win a beauty contest, but there is a nice plugin called grepconsole you can use to make the result more expressive by coloring it. For example, you can color the "Tests run" line red if there are failures and green otherwise. Most of the remaining lines are less important and can be given a gray color. I use it extensively to improve the readability of the console output.
Our complete script also includes the commands to compile and weave the code (and packaging jars and wars, deleting directories and a lot more). A sketchy version of the script might look like this: