Most developers don't run tests after they change code. This is mostly about habit, but also about perceived inconvenience, I imagine. There's an easy way to get around that... make VS smart enough to have tests automatically run in the background when the code they're testing is changed (and obviously recompiled). To do this, there might need to be a way to specify what class members are tested in each test method, but that'd be good anyway. I find myself putting that in all test method comments, anyway. Whether that's added via a code comment or attribute, I don't care; although, the latter makes a little more sense.

As I mentioned yesterday, I like the idea of check-in policies, but they are pretty annoying for those of us who like to check-in as much as possible. Why? Because you always have to rerun code analysis and tests before checking code in. Most of the time, this isn't a big deal. If I make a minor change like correct spelling in comments, I have to rerun both. Tell me what test is going to change based on a comment. None. Admittedly, some code analysis rules check for that, but is that really going to provide you much of anything? I just want check-in policies to have some sort of logic to identify whether or not there's any value in running them.