Background compilation vs background unit test runner

A few months ago I posted about how to get background compilation in Visual Studio by using Resharper. It's really remarkable how background tools like these can improve your productivity. Sure, you'll have to learn to ignore the red wiggly lines until you're done typing. In that respect it is no different than the spell checking in Word or Firefox. But once you know when to check the results and when to ignore them, background compilation with "in code" feedback is a real time saver. I probably would have worn out my ctrl-shift-B combo long ago without it.


This week I noticed that even though compilation is automatic, you still have to start unit tests manually. And while they're running, you have to wait for the unit tests to complete before you can continue working on your code. And if you have a substantial set of tests, like the good test-driven developer, running them may take a few minutes. So running the tests is quite disruptive to the development process.

And as you probably know, if something breaks the flow of your development process you probably won't do it as often as might be useful. Why are continuous build systems so good? Because they work automatically when you check something into your version control system. Why is background compilation so good? Because it works automatically as you're making changes to the code.

So why can't we then have the unit tests running in the background? Sure, it'll eat up some resources. But it's not like my machine needs all its megahertz's to keep up with my typing anyway. And I can only imagine how great it would be to automatically see a purple line appear under some code I just changed that broke one of the unit tests.

Sounds like cool stuff to me. Does anyone know if this already exists?