Nov 09 2009
NetBeans Unit Test Creation better than Eclipse? And where should unit test live?
I seem to work on a variety of Java applications and find that unit testing is one of the most varied (implementation-wise) pieces of the development process. These applications, created by different development staffs, many which have evolved over the pass few years are all very unique… kind of makes me wonder why? That is a topic for another post!
One debate I always seem to encounter is around where to actually save the unit tests? Should we do in-package testing or rely on the public API. My preferences are pretty simple:
- Unit test should not be stored with the code, but rather created under a secondary source root. On my early projects, I created a sub-package under each package, called test, to manage the relevant files (tests and data). I later realized that I could simplify the Ant build process and enable in-package testing by creating a separate source tree. I have seen projects commingle the actual source code, unit tests, and even the test data files, all within the single source tree. This defaults the testing strategy to in-package testing, and discourages (or even prevents) API testing. I find this approach rather messy and unclear. This approach also complicates the Ant build process; at some point during the process, the unit tests, supporting classes and files should be separated from the actual deployable content.
- I like to name my secondary source root tdd. I know it is not widely practiced, but my hope is that if the developers see that TDD directory every time the open up their IDE, the concept might actually wear off! Maybe someday, one developer (hopefully more) will actually be challenged to write their unit tests first. With Eclipse and jUnit 4.x annotations, I seem to always start with my unit test, and sometimes even refactor code from the unit test into the actual class; kind of a high-bread TDD process, but the thought is always there!
- I also prefer the public API testing strategy verses in-package testing. This line of thinking always takes me back to the Testability Explorer. The concepts behind this metric enforce the idea public API testing and is worth a quick read. Add the Spring Framework to the mix, enabling dependency injection and I see little need for in-package testing. This is typically accomplished by creating a “test” package as the root of the secondary source tree, with sub-packages reflecting the package hierarchy of your classes to be tested. I truly believe that defaulting to in-package testing allows the developers to be very sloppy and even unaware that they are testing a specific internal implementation, rather than externalized behavior presented by the API… This is VERY bad practice in my opinion.
- If there is a need for in-package testing, then the sub-package structure of the classes to be tested can be recreated under the secondary source tree, maintaining a clean separation between the source and test cases. These test should be considered an exception to the norm, rather than common practice. I would hope for a 90-10 or 80-20 ratio, with a majority of the test falling under the test package root (in-package is the minority).
I am kind of tied to Eclipse as my IDE, but do play with NetBeans every so often. I think I could switch to NetBeans, my only real requirement is that the IDE must have Emacs key bindings; some habits are just too hard to break! NetBeans looks like an pretty good tool and seems to be very responsive on my Ubuntu box; I especially like the way it manages plug-ins. One interesting thing that NetBeans does (maybe a little better than Eclipse), is manage unit testing. NetBeans will automatically create the secondary source tree, but seems to default to in-package testing. It is very easy to add the additional test package into the package structure to enable API testing. I also like the way that NetBeans separates the Test Libraries from the regular Libraries. I’m not sure how well this would work when you use a tool like Ivy, but does make it more obvious, as to which libraries are used for execution verses unit testing… If you do happen to generate a unit test from an existing class, NetBeans will generate more code than Eclipse. I’m not sure how useful this code is, but it does try to create the object under test, invoke the get() methods and perform assertions on the returned values. Might be more noise that it is worth, and anyway, you should be writing the unit test first!
The bottom line is that Unit testing should be easy and valuable. If it becomes too hard or complicated, it might be time to re-address how the unit test strategy is being implemented.



This was making me crazy the other night… I did not spend too much time on it, thinking is was just me. But, after upgrading my laptop and encountering the exact same problem, I knew there was more too it. It seemed like only the cancel buttons actually worked; all of the next and finish buttons did absolutely nothing, other then beep! I soon realized that I could use the tab key and press enter to move to the next screen; but that did not make me very happy.
It also 

The Eclipse developers did a really nice upgrade to the Plug-in manager in the new Galileo release. Managing plug-in sites seems much easier and cleaner with the new Available Software Sites menu option in the main preferences area. Not really a new feature, but seemingly more obvious, is the ability to import and export update sites to and from your team mates. I have exported my settings and linked them to the XML file icon on the left. Simply download the XML file and import them into Eclipse and you are ready to go. I can’t believe I never used this feature in the previous versions!
This is not a new feature either, but one that I always seem to forget! I just hit the Check for updates option every so often; not nearly as convenient! You can find this option under the Install/Update preferences panel as well.

I have to give credit to a co-worker who overheard me complaining about Eclipse one day… Ever since upgrading to the Ganymede version of Eclipse, the launch buttons for executing and debugging applications and unit tests were tied to the currently active editor. This was so annoying, I could not believe the Eclipse developers changed this behavior. Every time I clicked on the button, Eclipse would ask me what I wanted to do…. No, I don’t want to execute the XML file I was looking! No, I don’t want to execute the random Java file that I just fixed; I want to run the last unit test! 
I might be in the minority, but I’m just not that excited by this release of Eclipse. I started using the RC3 version for real last week, and have had no issues at all; it seems very solid. I attempted to use with the first couple release candidates, but they did not seem to play well with the Subversion plug-ins. I’m sure it was user error; it could not have been that messed up! For whatever reason, Eclipse completely toasted my work area (multiple attempts) after every commit. Needless to say, I did not even bother using them. I have Eclipse integrated with the Spring IDE, Checkstyle, PMD, and Ivy plug-ins. I heavily use the Web Tools Platform for deploying web applications to Tomcat. At least for what I have been doing lately, there is nothing to get me really excited. I think the best part is, that everything still just works! I notice a new little feature every so often, but nothing that says that’s a keeper! I have been using the
years and was glad to see they finally implemented this feature within Eclipse. It works pretty well, but they only implemented half of the functionality! With the Implementors plug-in, you can click on the interface method and ask to see all of the concrete implementations. You can, sort of, get the same functionality through the type hierarchy view, but not as nicely. After seeing the Open Implementation feature, I thought this was a new feature too; I did not know that you could just click on a URL and have it open up in the browser, kind of handy!
I was looking for a development build of the IvyDE plug-in for Eclipse tonight and I stumbled across the 

If you have successfully converted your project, you will see a small globe appear on the project folder icon. You can now add the project to the Servers view and easily deploy the project in your locally configured runtime environment. I have glossed over some of the WTP setup, but will cover that in another post. I thought it was important to explain Facets; I had previously wasted significant time, manually converting projects to Dynamic Web projects. Unfortunately, the manual approach only worked about 50% of the time. Once I learned about Facets, it made my life a lot easier!
I only played with Galileo for about 10 minutes and I am already very intrigued. Based on my last post, I wanted to see if I could get Ivy and Eclipse to work better together and explore the new features. The first difference appears to be the way that plug-ins are installed and managed. Eclipse 3.4 significantly changed the way plug-ins were installed and it looks like they are changed again. Plug-in management was never as smooth as NetBeans. NetBeans provides a fully integrated solution for searching through available plug-ins, with click and go installation. The new Eclipse implementation looks promising, maybe not as polished as NetBeans, but a step in the right direction. As shown to the right, you can now view all of the available plug-ins in a much more controlled and usable approach. Managing additional software sites is much cleaner than before too.
art using it for my daily work and try to find more interesting new features to report on!