unit testing success
Wed, Sep 19, 2007
Following on from my previous post about unit testing Sakai, I’ve managed to get a simple test up and running. Rest and time away from the keyboard are always a good bet for a solution to a new problem.
What the problem was, was classloaders, that ol' Sakai cherry. The clue was in org.sakaiproject.test.SakaiTestBase and its setting up of the URLClassLoader with the jars in the tomcat directories in which Sakai is running. I’d tried adding these jars to the tomcat classloader, WebappClassLoader but that caused all sorts of maven runtime errors, while it was fine in IDEA, again, due to classloader issues. Setting up the tomcat jar paths in URLClassLoader before loading the SpringCompMgr via WebappClassLoader solved the problem.
However, all this just reaffirmed my hatred of maven! It truly is a load of unadulterated pish! Take this for example. There was a bug in the test that threw a NullPointerException, which I could see in IDEA. When I ran the test in maven, I got diddly-squat back from that heap of crap:
Tests in error: test(org.sakaiproject.content.chh.fedora.ResourceTest)
and maven insisted I run it with the -e switch for more information, which I duly did:
[INFO] ———————————————————————— [ERROR] BUILD FAILURE [INFO] ———————————————————————— [INFO] There are test failures. [INFO] ———————————————————————— [INFO] Trace org.apache.maven.BuildFailureException: There are test failures. … Caused by: org.apache.maven.plugin.MojoFailureException: There are test failures.
Hooray, there are test failures! I know that, you halfwit build system. Maven still didn’t hint at what the problem was. I had to debug the test in IDEA to see that.
I think maven should stick to dependency management and a real build system, like Ant, take care of the real work.