A test or a set of tests has to be selected in the TestView window, but at least rerunning them is easier.
Also: there is the bug 'running' tests forces a build of the test project, but not the dependencies, so always do a 'Build' before using the keyboard shortcuts. For this, I use
which builds the active project (and its dependencies)
I haven't really looked into it, but I'm still not convinced that the deployment/setup for MS Test on something like CC.NET will be any better. Of course with 2008 you should be using it's test server for automated builds right? No thanks. CC.NET, NAnt/MSBuild and NUnit/MbUnit works fine and continues to get better. We'll see when we get the full VS2008 product where things are at, but I suspect it'll be as if you stepped into a time machine and went back to when were we all struggling with getting Cruise and .NET working.
vsts is not great, but it has worked acceptably for us. Integration with TFS is critical to us and vsts has decent out-of-the-box support. Looking forward to better performance though, and simpler publishing to TFS would be nice.
our setup for 5-10 person projects:
* vsts covers most needs. some custom extensions used.
* vs.net _db for pro_ post-deploy scripts to pre-populate database for some testing that needs the real db.
Product automation build/test
- kick off only. no special tasks.
* visualbuild pro
- complex build, package and deploy actions
* custom scripts and helpers
- test-run preparation, farm out to test
machines, scheduling etc.
- systray apps to monitor and kick off tests.
* compuware testpartner
- old automation system.
- we consider it deprecated.
- our new automation is based around vsts.
- mstest.exe and custom wrappers.