Want to run your JUnit tests as soon as you change the code? That’s what infinitest strives to do. The starting point is infinitetest.org which directs you to the corporate site.
What does it do?
Infinitest installs as a plugin to your IDE. In Eclipse, it adds a bar to the bottom of your screen. I’d say I lost about an inch of real estate. Not much, but if you have a lot of other plugins, this could be a problem.
Every time you change Java code, it sees which unit tests should be re-run and changes the bar to the appropriate color:
- black – waiting for changes – when open workspace and haven’t done anything yet
- green – all is well
- yellow – no tests were affected by this change
- red – one or more tests are failing (could be from this change or a previous change)
The bar, also tells you how many “test cases” were run. They mean the number of test classes rather than the actual number of tests so this number isn’t as useful as it sounds.
Does it require a lot of configuration?
No. The entire user guide is two screens long. Configuring it took me less than two minutes – which were spent looking up the name of my integration test runner and package so infinitest didn’t run them. I also looked at the preferences and saw it had a default of half a second before giving up on a test. That’s a good length. No unit test should take that long.
What do I need to run/install it?
Infinitest runs as an Eclipse or IntelliJ plugin. I tried it in Eclipse. You install from an update site. My only concern is they don’t provide a manual zip file style local update. Now granted, neither do many other products, but they take the time to write:
If you are behind a firewall, you may have limited access to the Internet. This can cause problems accessing the update site. If you use a web proxy to connect to the Internet, make sure that you have correctly entered your proxy settings into Eclipse under Preferences->General->Network Connections.
If it’s enough of a problem to document, I think it’s enough of a problem to realize you have customers that aren’t allowed do download any plugins without having an approved body do it.
How much does it cost?
The initial install is for a 30 day trial. After that, you have to decide if you are an “individual” or “corporate” user. Once you decide you either fill out a form saying you are an individual or pay $150 per seat (perpetual license) and a license is e-mailed to you. Just copy/paste the license into your IDE and you are done.
individual – you own the copyright. In other words you aren’t selling what you write. From talking to the vendor, it sounds like open source and code I write for JavaRanch fall into this category.
corporate – code you write for someone else to make money – also known as your job.
How well did it work?
I have three Java projects in the workspace I used to test:
- JForum – The JavaRanch fork of JForum. About 200 classes and a bunch of unit tests.
- PickWinners – The program JavaRanch uses to pick winners in the book promotion. About a dozen classes and about the same number of tests. Both unit and integration tests.
- Play – this has one class and no unit tests. I use it to test out “what does this code do”
My attempts:
- Edited a file in my Play project – it ran all the test cases in JForum and PickWinners. At first, it looked like it wasn’t using dependencies, but I think this was because it was the first run and it though nothing had run yet.
- Edited the file in Play project again. This time it correctly realized no tests were affected.
- PickWinners now has 5 errors of type “Infinitest Test Failure” – All are errors accessing the database from my integration tests.
- After adding infinitest.filters, I had to clean the project to remove the failures. (This was documented in the manual page.) It does re-run tests that are still unfiltered. It took me to passes to get the right filters.
- Made another change to PickWinners – it’s still running JForum tests
- Cooked and ate dinner (in other words, a bunch of time passed)
- Tried again – all of a sudden it started picking up only the truely dependent tests. Maybe there was a learning curve? Cool.
- Almost everything I tried after dinner did pick up the correct tests based on dependencies. It (usually) found tests that use the class indirectly. It got faster and finding dependencies when I repeatedly edited the same class. I assumed it cached the result. Which is good because when doing real development, this is what happens.
What problems did I encounter?
- The JForum project doesn’t show the test failures as compiler errors. The PickWinners project does. The JForum project also complains sporadically about a class not being found that is in the same project. Note: this problem temporarily went away after I restarted my workspace. It came back after I introduced a failing test and corrected it.
- As I wrote above it usually finds the relevant tests. For example, I changed the implementation of post.setText() to use the value “hi” instead of the passed in value. I expected a whole gaggle of tests like the following to run and fail. None of them did.
@Test
public void noCodeTags() {
post.setText(“test”);
PostCommon.processText(post);
String actual = post.getText();
assertEquals(“transformed post”, “test”, actual);
} - I have to assume this won’t work for reflection based code. I don’t have any on hand. While I could write some, it doesn’t sound like it work from the vendor’s description. And if the vendor admits it won’t work, I’m inclined to believe them.
Final thoughts
I like the emphasis on “keeping the bar green.” If you always see it on the screen, it reminds you it exists. I haven’t had it installed for long, but I’m already used to it being there and relying on it. Even if it isn’t perfect, it’s great to have present.
It worked well enough to be useful on my home projects. I’m not sure how well it would function in my work environment where compiles involve a lot more code. The “find the proper tests phase” was noticeable at home. It could be better at work (faster machine) or worse (much bigger workspace.)
