Hi Ed,
I've come to rely on NCrunch for my dev workflow now. It's partly TDD, and partly not: I'm not strict. The part I depend on however is 'confidence'.
Like Steve mentioned, it's all about confidence for me. I use my test based workflow for mainly two types of confidence:
* confidence that I'm building the right thing, and
* confidence that I'm not breaking already-delivered things.
Like most developers, I can get distracted easily so I use NCrunch to aid in my focus on delivering only the minimum to satisfy my task/story/work at the given moment throughout the day. If you adopt the agile way of doing things, then you necessarily subscribe to 'reducing waste'. NCrunch helps me do that in a number of ways.
When I start on a piece of work, I usually create a test file and knock out a few comments which roughly describe the assertions I want to make in English reading statements. These things positively assert the completion state of the task while exercising various paths. They're usually written in terms of the 'consumer': human user via UI or API client in the case of an API endpoint. I then write my empty test which must fail. I usually write the method name similar to the comment it replaces. To make the test fail, it needs to be picked up as a test and should not pass. So i add [Fact] or [Test] and through a NotImplimentedException in the body. Now NCrunch goes to work and I get a red marker.
Next I want to start implementing my test which might look something like
https://github.com/cotts...re-is-the-silver-bullet
I subscribe to Subcutaneous Tests (sub-c):
https://github.com/cotts...e-is-the-silver-bullet. If they're easy to write then they're a great way to get lots of coverage and high confidence. I don't agree with Jay however when he says that tests should be sub 1ms. I believe confidence is a product of test value (what it's testing; loosely: coverage) and test run time. ie, a slower, higher value test can give you more confidence than a faster low value test. Sub-c tests and very high value and that's where your tooling is very important.
To get fast feedback and therefore confidence from tests that typically take between 5-10s to complete, you need to parallelise your tests. And to successfully parallelise tests, they need to be sufficiently isolated from each other. This is another toipc in itself however I have gone to some effort in this package
https://github.com/cottsak/ControllerTests to show how it can be done. Also: xunit has a very particular view to test isolation which is why I prefer that framework to NUnit. more here
https://github.com/cotts...ontrollerTests/issues/2
Once I have a failing and implemented test (still red in NCrunch) I begin to implement the code to pass it. I do this one test at a time. I also write some of the real production code (usually contracts/interfaces) while building out the failing tests. This is why i said I'm not strict TDD; it's not always pragmatic to be black n white.
Within seconds of my completing the minimum code to pass the test, I get a green light from NCrunch. Sure it's not near-instant (in the case of <1ms tests) but it's frikin' fast. I don't have to remember to run tests and I don't have to save file and rebuild. I've started with tests driven from my requirements so it's simply a matter of converting those requirements to more tests, then passing them in order to complete my task. NCrunch is a guidance tool for this workflow and is a lot better integrated than alternatives.
The MS test runner can't do parallel tests like NCrunch. Where it does support it, it's testing framework dependant. eg, I can do parallel tests in DNX on VS15 but only because they're xunit and only according to xunit's internal parallel test configuration. NCrunch will give me a greater parallel control in this case. More
https://github.com/cotts...ob/master/notes.md#cons
The Resharper test runner is nicer in some ways to the VS one but it still can't do parallel tests.
In addition, like others have said, the code coverage and markers add a lot of value to various testing workflows (including mine) which can't be understated. I should also point out that the static code analysis that supports the code coverage in NCrunch also allows for another great feature which speeds up sub-c tests even more - rather than running all tests after a change, NCrunch is able to analyse and identify only the the tests that are impacted by your code change, thus running only a limited set and getting results back to you faster. more
https://www.ncrunch.net/...n/concepts_engine-modes "Run Impacted Tests Automatically, Others Manually"
I know my scenario is pretty specific but I'm hoping this insight helps you decide what potential value the product could deliver for you. have fun.
