NCrunch + Debug.Print() = Almost a REPL
I remember back in the mid-90's when I could launch a compile cycle on my C++ program and then go to lunch. It might be done by the time I returned. I'm sure that SOMEWHERE in the world there are still projects like that, but they're definitely not in the mainstream like they used to be. The days of waiting for long compile cycles are over.
In fact, it seems that we don't even have to wait on the compile cycle at all anymore to get feedback on whether the code we just wrote is working. At least not with NCrunch. If you haven't discovered NCrunch yet, I'm sorry for you, because it's now my second favorite Visual Studio extension next to ReSharper. NCrunch continually runs your tests as you type them. No need to even CTRL-SHFT-B, much less CTRL-R, A. This is almost instantaneous feedback on the last character you typed in your code. And it's even smarter than that. Before I had ever used NCrunch I used to think that it simply would save me from having to type CTRL-R, A. Not so. You'll find yourself pondering whether this is almost a new paradigm - this instantaneous feedback.
Of course, you can still write terrible tests and rob yourself of instantaneous feedback. NCrunch can run integration tests, which tend to take longer (not that integration tests are bad, they're essential!), but NCrunch's usefulness is primarily in running your quick unit tests for immediate feedback. So have NCrunch ignore those long-running tests and get instant feedback on success/failure, code coverage, and profile times of your tests. You can un-ignore your long-running tests (or just CTRL-R, A) every once in a while to confirm you haven't broken integration before pushing your changes to your main source control.
NCrunch isn't perfect, and there's plenty of room for stability improvements (or maybe I just don't know how to set it up correctly), but I'd rather have a rocket-ship that I have to get out and kick every once in a while than have a horse and buggy that plods along forever. At some point the "Tortoise and the Hare" analogy breaks down, and the NCrunch bunny definitely breaks the analogy.
Now, on to the true purpose of this post. Because of the instantaneous feedback that NCrunch gives you, you can almost treat it like a REPL. Using this technique I find myself going into the debugger even less than I did after adopting TDD. Not sure what you need to do with a specific class in the Base Class Library? Need to "spike" a test? Try simply putting one or two judicious uses of Debug.Print() and look at the NCrunch Tests window. Select your test (you have to select the "checkbox over the eyeball" toolbar button to show passing tests) and in the gray area below you'll see the debug output of your test. Not what you expected? Change your code, try a new method from the object's IntelliSense list - all things that are much harder to do when debugging. You'll get feedback faster and learn faster.
For example, I had some data that I wanted to verify inside of a SOAP Message response, but I didn't really know what data was in there. To me, it looked like angle brackets and namespaces had exploded everywhere (ah the joys of SOAP). Then I thought of Linq-to-XML. I knew little more about Linq-to-XML than the simple fact that it exists. A quick Bing of some MSDN docs as an overview of Linq-to-XML showed me the basics. So now it's time to experiment.
It was simple. Like I said, just create a test and in the NCrunch Tests window, select the test and watch the test output area as you edit the test (notice the current name of the test reflects my ignorance of what I'm wanting to test, not strict TDD, no, but that's what happens when you're "spiking"):
[TestMethod]
public void WhenCtorInvoked_ThenMessageShouldBeUhhhhhhh()
{
var context = new EnumerationContext();
var sut = new PullMessage(context, 50);
var element = sut.Message.GetBody<XElement>();
Debug.Print(element.ToString());
}
Still quite a few angle brackets, but certainly not as bad as the whole SOAP message!
Hope this helps,
Doug