With Infinitest every time you make a change in your code, the JUnit tests will be executed. How cool is that? Infinitest will run in IntelliJ or Eclipse.
I wrote a more generic post on CT that forks this post: Continuous Testing while developing, CDT?.
I tried it in a very small Groovy project, and it worked. Of course, Groovy compiles to Java, but in an IDE things get complicated.
Unfortunately on a large Java project it did not seem to work, and the web site does not have enough information to determine what the issue is. For example, the status line is showing that it is running a test (unrelated to the recently changed code) and it shows “(400 remaining)”, remaining what?
Whether this plug-in works does not negate the concept of Continuous Testing as discussed below.
I installed the plugin using the update site. Made no configuration changes. Then I changed my code, and nothing happened, just a status at the bottom that one test case ran. In fact, I changed the Unit test code to force a failure.
Then I noticed that Eclipse’ Problems view had red ‘x’. Hmmm, I didn’t make any compile related changes. Opening the Problems view showed the actual test failure. Ah, now I get it. The status bar is just like the JUnit status, red or green.
I thought the plugin would reuse the JUnit view in Eclipse. It doesn’t, instead it adds any failures to the Problems view. Thinking about it, that is the correct approach. When your coding the only distraction you need is to know if a change to code broke something, comparable to a compile just getting compile errors.
Bringing up a new view, especially the JUnit view would be heavy weight. When you focus on testing then the full JUnit view is more useful. But maybe this should be a configuration choice?
Anyway, the workflow is just code as usual. The status message at bottom of the IDE will be Green or Red depending on the test run. When red, the Problems view will show the test failure. Unfortunately clicking on the error line will not bring you to the failing test, but this could be that this is a Groovy Project.
We don’t edit code then invoke a compile step anymore. Our IDEs do that automatically. Then why have to invoke our unit tests manually? This “Continuous Testing” (CT) approach enables a smoother Test-Driven Development (TDD), maintenance, or refactoring, work flow.
Is there any evidence of this? Some papers on CT are found here.
If you search for the term ‘continuous testing’ there is not much. Usually it appears in the context of Continuous Integration servers. Perhaps its time to make CT more visible so that it’s more available as a development practice.
Great videos on the CT as implemented in Mighty-Moose, a product for Microsoft Visual Studio, are found at continuoustests.
Mighty Moose Demo, a CT product for Visual-Studio.
Mentioning this to any developer will give you immediate “buts”: But my tests take too long; it would be distracting; I change code constantly;…… I sometimes think developers are driven by a little motor in them, but … but … but … buuuut.
The only thing I see in Infinitest to address these concerns is the use of a filters configuration file. You can add multiple regex to avoid tests that you don’t want to run all the time.
I’d like the opposite too. The ability to easily define what I am interested in testing, inclusion filters. On a large code base you may be concentrating on a few packages, so it should be easy to just add those to a filter without having to drag out the “Mastering Regular Expressions” book.
Though Infinitest is good, why isn’t running a configuration on configured type of changes supported in Eclipse? Is there is a direct way to invoke the JUnit plugin via adding a new custom “builder” to Eclipse? A builder in Eclipse is triggered by resource changes. So, on source code change this builder would have to run an associated ‘JUnit run configuration’.
May 1, 2014: While looking at the Infinitest source I noticed they use AssertJ. Another great library. So many cool things. So why is code bug ridden? Just joking.
May 6, 2014: Tried Infinitest in a larger project. Did not work.
Eclipse Kepler Service Release 2
Groovy Plugin 2.9.0
Groovy compiler 2.2