3. 对已有代码编写单元测试的难度非常大
因为我们做的是控件产品，在兼容性方面的要求很多时候会很苛刻。有时候一个产品发布之后，发现了Bug，下一个版本也要保证这个Bug原封不动的表现在那里（这时候，我们会说这是我们产品的一个Design）。因此，对代码的重构就会成本很高。因此，要想在不破坏原有结果的情况下进行单元测试的难度就非常大了。这一点，也许有我们产品的特殊性所在。但是，我觉的目前现实中的很多项目其实和我们的项目的要求还是很像吧。
4. 当单元测试很多的时候，组织和命名会比较有挑战。
我一直没有建立起来一套好的单元测试命名体系。目前在项目中的组织方式是：两个平行的工程，产品工程使用 InternalVisibleToAttribute为测试工程提供Internal成员的访问权限。两个工程保持相似的组织方式。但是，当一个被测类型很庞大的时候，测试代码就很难组织好了。
5. 目前很少遇到单元测试影响重构的情况
不好的单元测试或过度测试都会对重构带来不好的影响，在我参与的上一个项目中就出现过这种情况。当时，项目突击了一段时间的单元测试。硬任务，每人必须写nnn个单元测试。后来，产品升级的过程中，就不断的删除原有的单元测试。那是因为后来没有人将单元测试作为指标了。否则，可能很多有价值的重构都会不做了。因为修改单元测试太费劲了。这一点对我造成了阴影。以至于我在当前项目的前期没有很高调的推动单元测试。这是这个项目过程中我最大的遗憾之一。
也许是因为，单元测试覆盖率较低；也许是因为我们没有拿单元测试再作为指标，因此大家写的单元测试的质量更高了。总之在当前这个项目的升级中，似乎很少发现维护单元测试付出较大的情况。
6. 单元测试对重构的帮助不如预期
正如前面所说，我目前负责的项目中，较大的重构发生次数并不多。小规模的重构中确实有单元测试帮助我发现问题的情况。但是，远不像我的预期那么多。这一点，应该说和单元测试的覆盖率较低有关。
7. 目前的现状下，很多平台的限制，使能够单元测试的部分很少。
虽然我很有意识的推动单元测试，并且在实际开发中使用单元测试。但是，目前的情况，在WinForm平台下的开发中进行单元测试的桎梏还是很多。也许和我们的产品特性有关，实际过程中，我经常发现，能够测试的代码不是那些经常出问题的代码。而经常出问题的代码，往往因为和平台关系太密切，而无法切割出来进行单元测试。
ASP.NET MVC在一开始设计的时候就考虑了可测试性，因此，这一方面应该更好一些。但是，至少我目前没有看到微软在其他平台下的可单元测试方面的努力。这是我在使用单元测试过程中最郁闷的地方。
以下最后两点属于我的想法，目前的项目中因为前面的一些约束，导致我还无法证明我的想法是正确的或错误的。列在这里也仅供大家参考了。
8. 单元测试可以作为开发Leader掌控设计的一种工具
和聪明的人在一起工作的最大困难就是你没有办法控制项目的设计。聪明人并不一定出好的设计。但是，你又没有办法说服他采用你的设计。我觉得，单元测试是一个开发Leader掌控设计质量的很好的工具。因为它可以成为一个简单的指标：“你别给我说你的设计有多么好，如果你的设计不可测试，那么抱歉，你不能放入产品代码。”，反过来说，如果你的设计可测试，那么意味着，即使你的设计再烂，它也是可以替换的。总有一天，我会把它从产品里面干掉的。
说说而已，其实大多时候，我也不确定我的设计是好的。但是，我相信，可测试≈低耦合≈好的设计。我相信，当项目复杂到一定程度的时候，建立一些这样简单粗暴可测量的规矩，对产品的健康发展很有帮助。
9. 单元测试可以帮助开发人员设计出更好的结构
因为那个简单粗暴可测量的规矩，迫使开发人员降低自己设计的耦合度。从而产生更好的设计。
最后，来和老赵探讨一下他的问题。我的观点是：
10. 单元测试不需要对private成员进行。如果需要，那么抽象Strategy类。并对Strategy类进行测试。这个不属于过度设计。
因为，我认为需要测试的方法一定具有以下几个特点中的至少一个：
* 它有出错的可能。
* 它具有的复用的可能。
* 它具有变化的可能。
对于第一点，我认为应该是可以通过对public成员的测试来完成对该private方法的测试的。而二三两点，正是抽象的用武之地。抽象的重要目的就是在封装变化和复用。如果这个函数具有了变化和复用的可能性，我们就应该将它抽象为一个独立的对象，并且对他进行测试。这是一个更好的设计，而不应该归入过度设计的范畴。
如果不符合上面的二三两点，我觉的对这个private成员的测试就属于过度测试的范畴了。是应该杜绝的。因为，你的测试代码很可能没有起到保证质量的作用，而是成为了将来重构的桎梏。因为，理论上重构的过程不需要保持私有成员的行为不变。但是，你的单元测试又要求私有成员的行为不变。这个其实就是我上文中提到的“单元测试影响了重构进行”的情况。
