In fact, I have had the odd experience of building large chunks of functionality with tests and main line code, and then not see them work in my browser, because I forgot to save and compile. (F6 fixed that quickly). What NCrunch does is squirrel your unsaved files to a folder in AppData, and run them there while you type out code. Getting that level of continuous instant feedback really changes the way you write code. For example:
- You get used to seeing green dots on the left. Their absence makes you feel a little skittish (don't refactor this! who knows what will break). And the motivation to get stuff green becomes very strong (let see if calling this works.. isolate, isolate, there, it's green!)
- You become creative about breaking things. Earlier today I was working with code that generated user names from a first and last name column, and I had to add a bit of additional logic. I wanted to see if the current logic was covered meaningfully by tests, so I changed:
userName = firstName + lastName; to
userName = firstName;//+lastName;
just to see if anything would happen. Red lights a second later (semicolon, whack, whack, red, just like that) showed me that the current logic was covered, taking me to the test I needed to modify. Friction free.
- Being able to jump from code to covering tests with a right click equally removes the friction of adding tests, since you can see at a glance what is already in place.
- If a single test is failing, the red dots provide a beadcrumb trail through the executing code. This often leads to very rapid troubleshooting, since you can see at a glance whether, for example, an if block is being entered. Exceptions are called out with a red X, again making it a lot faster to pin down where code is failing.
- The ability to tactically ignore tests can be useful when trying to fix a number of failures. Recently, in a code review session, we reviewed 12 tests that were failing. We ignored 11 of them, so that our red dots were meaningful (they corresponded to a single test). Then we analyzed the code under tests, and realized what was wrong with the test. A few keystrokes to change the test, and we had green. Then we unignored the other 11 tests, and they went green as well
I recently did a deep dive through the documentation, and learned there was a lot more to the tool than I had realized.
- You can set up grids of workstations, and run unit tests on this grid. I cajoled two of my neighbors at work to turn this feature on, and now my unit tests are divided up and run where CPU cycles are available. We are still experimenting with this feature, but it looks very promising. Running unit tests for your team while you eat lunch down the street sounds pretty effective. http://www.ncrunch.net/documentation/guides_distributed-processing
- There is a command line tool that can be used on CI servers, that produces very nice HTML test and code coverage reports.
- The test engine does analysis of which tests are most likely to be impacted by recent code changes, and runs those tests first.
- There are a number of syntax options for managing concurrency of integration tests (each thread runs in its own process, so there is no issue with static methods and values). You can specify that a given test requires exclusive or inclusive access to a resource, such as a file on disk, a database, etc.
In short, there is a lot to this tool. The CI and distributed capabilities look very promising indeed. This website is NCrunch.net. And to give a feeling for the rhythm of feedback, here's a short example of NCrunch responding to a line of code being commented out: