NCrunch does have this as a feature, although the approach is somewhat different to Greg's tool.
By default, NCrunch uses test impact detection in order to establish the 'priority' of a test rather than whether or not it should be run. As NCrunch is a truely continuous test runner, it isn't necessary for a test run to fully complete before you can make a meaningful decision about whether your code is working correctly.
As an example, one project I once used NCrunch very heavily on had a total running time of around 2 hours for all tests in the solution. To run the tests manually using any other test runner was extremely painful, as it involved carefully selecting the tests that you felt were relevant to the piece of code you'd been responsible for changing. If you managed to get this wrong, your check-in would break the build. We could take a broader approach of waiting until the full 2 hours of tests finished running, though this would then increase the risk of merge conflicts (as the actively developing team was quite large). NCrunch was extremely valuable on this solution as the impact detection would always prioritise the impacted tests first, so we could just keep making changes to the code and use the risk graph or the solidity of the coverage markers to gain an indication of when it would be safe to check code in. In the rare event that a test wouldn't be run early enough to avoid checking in broken code, NCrunch would always still bring up the failed test shortly after check-in (as part of its usually continuous running) so it would be possible to take corrective action much earlier.
True continuous testing massively changes the way we approach test driven development. Instead of looking at safety of working code as being absolute on a full test run, we now have the option to look at safety as being relative based on the progress of a test run. The primary purpose of a good continuous testing tool is to give you the most relevant feedback as early as possible, so you minimise wasting time for tests to run. Although the context of Greg's blog post doesn't imply this, Greg and I actually fully agree on the concept of 'Good enough' and I feel this is an important perspective to adopt in a world full of long test pipelines and short development schedules. For this reason I have actually long considered seriously revising the concept of the risk/progress graph (i.e. the fact that it has an 'end'), though many of NCrunch's users are now very used to it and would likely object to me changing it.
But anyway, regardless of my own opinion or perspective, NCrunch is itself a tool designed to solve a very clear set of problems. So yes, it also supports the ability to run only impacted tests. You'll find an engine mode available in the top menu ('Run impacted tests only') that will do just this - or you can create your own custom engine mode that makes use of the impact flag in deciding which tests to run.
There are also other ways you can give NCrunch clues to which tests you feel are more important to the code you're changing. Any test 'pinned' to the tests window will automatically receive a large priority boost. You can also run covering tests with a high priority by using an easily accessible keyboard shortcut.
I hope this helps!
Cheers,
Remco
