Welcome Jeanne!

I’m pleased to announce the addition of Jeanne Boyarsky as a full-time partner to this blog. As regular readers may be aware, Jeanne has been a long time contributor helping to fill in the gaps of time when I’ve been too busy to write regular articles. Jeanne and I met as moderators of the JDBC forum on The JavaRanch Big Moose Saloon, frequently regarded as the best Java discussion and assistance forum on the web. We’ve been friends for many years now and I hold Jeanne’s mastery of Java in the highest regard. Let’s all give her a warm welcome!

product review: infinitest

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:

  1. JForum – The JavaRanch fork of JForum.  About 200 classes and a bunch of unit tests.
  2. 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.
  3. Play – this has one class and no unit tests.  I use it to test out “what does this code do”

My attempts:

  1. 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.
  2. Edited the file in Play project again. This time it correctly realized no tests were affected.
  3. PickWinners now has 5 errors of type “Infinitest Test Failure” – All are errors accessing the database from my integration tests.
  4. 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.
  5. Made another change to PickWinners – it’s still running JForum tests
  6. Cooked and ate dinner (in other words, a bunch of time passed)
  7. Tried again – all of a sudden it  started picking up only the truely dependent tests.  Maybe there was a learning curve?  Cool.
  8. 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?

  1. 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.
  2. 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.

    public void noCodeTags() {
    String actual = post.getText();
    assertEquals(“transformed post”, “test”, actual);

  3. 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.)

not sure how well it would work in my work environment where compiles involve a lot more code

should i use git over subversion

I’ve heard good things about GIT and decided to see whether to use it over Subversion for a project.

The first few benefits of GIT I encountered:

  • Distributed nature/connectivity – you have access to the whole repository even if you don’t have network/internet connectivity
  • Bisect command – to see when a bug introduced
  • Disk space – GIT compresses data well so the whole repository doesn’t take up as much space as one would expect

Disadvantages of GIT:

  • Since it is so new, the tooling isn’t as mature as I’d like it to be before relying on a project.  (This may not be a project for work, but it’s not just version control on my own machine either.)  See below about GIT clients.

Things I’m not sure about yet:

  • Branch handling – “You can commit to your local repository without messing up things for your co-worker” – This seems like it flies in the face of continuous integration.  I want people to be committing to a shared space frequently so we find out about integration issues as early as possible.  This sounds like “developer branches” which I feel are a step backwards.
  • Audit – Where is the official copy?  If everyone has a copy of the repository, which is the official copy for auditing/protection against hackers/etc.

Git clients

  1. Command line.  The command line looks solid.  There is even a command comparison if you use Subversion.  You just download and install.
  2. GUI. (SmartGit) – While this is still in beta, it seems ready.  The official statement is “SmartGit is in pre-release state, but we consider its feature set (for the first release) rather complete. ”  It has been in public milestone status since August (2009.)  When I installed it, SmartGit said it “expires 12/30/09”.  I suppose this is so you don’t stay on the milestone build too long.
  3. Eclipse plugin. (EGit) – While you can get this from the Eclipse update site, it says “are only made available to help the EGit development team use the plugin to develop itself. ”  I tried anyway to see what would happen.  It installed, but I couldn’t find a perspective/view that had to do with GIT.

While the GUI is available for all operating systems (Windows, Linux, Mac’s OS X, etc), it is still technically in beta.

My conclusion

Git looks like it will be really good one day.  For playing with a version control tool. I think it is great.  However, I don’t think it’s a point to recommend using for the project I was thinking of for several reasons.  The two main ones are:

  • The GUI support isn’t there yet.  This project has a lot of new developers on it so I think a good GUI is critical.
  • I’m not yet comfortable with the idea of source control being so distributed.  If something is on one person’s machine, it doesn’t really exist.  Just like “if it isn’t in SVN it isn’t done.”

Further reading:

See the official GIT/SVN comparison