One of the latest innovations in unit testing – the idea of ??continuous testing, that is, execution of unit tests as soon as you change something in the source code – that is, once you save your changes to disk, you want your unit tests are executed in background. This avoids situations where a developer or have forgotten, or for some other reason not fulfilled the necessary tests, resulting in the repository gets the code on which these tests fails. Of course, the main challenge is to determine what kind of tests should be run, when to change this or that piece of source code, because to perform a full set of tests may be too long to do it after every code change. Want to select exactly those tests on the result of which the best may affect the changes. I’m sure a couple of years it will become a standard built-in functionality in all development environments.
But until that happens, you can use the supporting tools.
I am aware of two tools of such opportunities. First, JUnitMax, has developed a Kent Beck, one of the pioneers of extreme programming (Extreme Programming, XP) and development through testing (Test Driven Development, TDD). The second instrument – Infinitest. Infinitest free and open source, and JUnitMax available by subscription (the present price is $ 2 per month price, in my opinion, ridiculous, but for some it may be reason enough to abandon the attempt to try it, it’s annoying) . Both tools are quite good, although the documentation bednovata (though you can find good instructions for using JUnixMax).
Infinitest differs in that it can work with Eclipse, as well as with IntelliJ, whereas JUnitMax only supports Eclipse. In fact Infinitest a standalone Java-based application that runs from Eclipseobychnym way through the menu Run. That is integration with the development environment is not too close, although there are detailed step by step instructions on using Infinitest in Eclipse. Unfortunately, when I was "unleashed" it on one of the modules in my project with a multi assembly through Maven, he was unable to determine where there are tests.
JUnitMax is available as a plugin for Eclipse, so that it fits into the development environment more smoothly. To experiment, I made a few trivial changes in one of my unit tests. When I saved the changes, as I suspected, JUnitMax ran some tests in the background, while an error is detected the assembly, which I totally did not expect! JUnixMax works like an invisible and makes a noise only when a test fails. But since in this case the error message is displayed the test as usual showing a compilation error, that is directly on the fields in the source code. It is very convenient – the failure of unit tests is treated as a problem of the same level of importance that a compilation error that greatly improves visibility. It also increases the productivity of labor – you do not need to remember is to run the unit tests after each save changes, and do not need to wait until the test is performed (perhaps even breaking out of this for some time, most of the work). Naturally, unsuccessfully completed the tests are marked as special flags in the project tree so that it is unlikely you’ll notice that, even if the error manifested itself where you least expected.
Of course, control over the maintenance of unit tests to date – it’s great, but more importantly the ability to run the necessary tests after it has changed some class to implement. To test I made some fixes in source code, thus making a mistake. And after a few seconds at the appropriate unit tests the red mark.
As I said earlier, the most important thing – to determine what tests need to do to you as quickly as possible know that some of the tests fails. JUnitMax uses some clever heuristics to guess, what tests should be performed in the first place, he tries to run those tests that run the fastest. But by the end of the day all your unit tests are performed after each change. This approximate method of determining the necessary tests, but overall it works fine. A more accurate technique should be based on code coverage information to determine which tests covered every line of code. It is much harder. Clover can do it, but not in real time. For example, if you are using Clover, integrated into the build system to Maven, the build process Maven can perform only the desired subset of unit tests, chosen on the basis of which parts of the code have changed, and which tests to cover these parts of the code. This is a great way to speed up the build process, but so far he has not at that stage of development that it can be smoothly integrated into the development environment, as is done in JUnitMax. Improved JUnitMax could combine these two technologies so that every time is limited to the most appropriate tests. However, the beginning – part of the story and the first steps have been taken.