Test Driven Development & Visual Studio Team System

Recently, I was given an opportunity to give a presentation on TDD and how one may use VS2005 to accomplish this task. During the presentation I have used a standard Microsoft presentation on TDD and VSTS.
During my presentation I showed several examples on how to author: unit test, manual tests, load tests, web tests, database unit tests (stored procedures), and ordered tests. We have looked closer at: Test Manager, Code Coverage, Code Analysis and how these functionality integrates with TFS. The sample solution containing all the code can be found here.

My final thoughts on testing in VSTS:
1. Visual Studio Team System makes testing easy, great auto-generation tools allow one to generate all the plumbing without any hassle; it also provides a starting point for learning how to create tests.
2. With an exception on Windows Forms UI tests VSTS allows to generate tests that will cover all the aspects of the development and testing.
3. 100% Code Coverage does not mean that the application is bullet prove, it should be used in conjunction with Code Analysis to identify if we are comfortable the number of tests.
4. all written tests should be used in regression testing, once we start to modify existing code.
5. We have "white tests" written usually by developers that deal implementation and technology details; and "black tests" written by testers (QC/QA) that deal functional requirements of the application.

An interesting thought: From the tester's point of view we need to create a "time line". For example users does something in the system, system does something in response and based on the those results user does something else. For example user creates a task, task's work flow/state triggers additional email notifications that may provide user with additional information.

So what is the problem? The problem is that we are violating several rules: Unit Test must be simple and cover small portions of the functionality and all Unit Tests must be independent of each other. My current solution for this problem:
1. use multiple asserts in the test and
2. group relevant tests in Ordered Test.

Any thoughts on it?