这种方法的优点很明显：由于测试代码同被测试的方法放在一个类中，所以private等方法很容易被测试。但同时缺点也很明显，该类会被写得很复杂，估计很少会有人喜欢看这种代码，而且万一客户不需要这些代码的话，在最后部署的时候，关del测试代码，估计也是个大问题。
2、每写一个需要被测试的类，就写当前工程下新建一个相应的测试类，名字可以在被测试类后面加上Test以示区别。
这种方法的优点是结构比较清晰，在比较小的工程中使用还算不错，修改测试代码也比较方法。缺点同样是部署时删除单元测试代码比较麻烦，同时solution太大，有很多project时，有很大局限性。
3、solution有很多个工程时，专门新增加一些工程，用于写单元测试，比如有一个ClassLibrary3工程，则建一个TestForClassLibrary3工程，单元测试类放到这个工程中去。
由于是以工程为单位，所以部署起来很容易，只要把这几个工程去掉就可以了，将来再要用，也只要加上就可以了。不过操作相对来说比较繁琐，没有前2种方法便捷。
4、以上3种方法都需要在项目的solution中增加东西，但如果你的项目不允许你增加任何测试类或工程（虽然感觉很愚蠢，但的确很多公司不允许程序员这么做），或者你根本没有权限增加工程或文件，这3种方法将都不能使用，这时可以用第4种方法。比如你想测试ClassLibrary3工程下的Class1类，你可以先build你的项目，生成ClassLibrary3工程的dll文件，然后在你本地建一个测试工程，引用这个dll，就可以不需要修改你的项目了。
这种方法的最大优点是不需要修改你的项目，不过缺点也很多，不够灵活，操作复杂等。
我个人比较多用2，3，在很小的模块中有时会用1，不过比起用1来，可能使用TestDriven.NET更加方便些。
