我正在编写一些测试代码，用于使用 Castle Windsor DI、域驱动设计（应用程序/域服务、存储库、域模型）、NHibernate 和（很可能）MOQ 进行模拟测试 ASP.NET MVC Web 应用程序。可以测试的可能性是无穷无尽的，因为基本上所有东西都可以测试。
一些可能性例如：
有很多东西（这么多层——控制器、服务、存储库）似乎几乎不值得测试，因为它们通常非常简单。
对于较小的应用程序，尚不清楚什么会带来最大的好处，但它会增长，并且相同的模式将用于更复杂的应用程序。
对于那些具有类似应用程序的人，您在进行什么单元测试？
如果您没有足够的时间或不熟悉编写测试，则域模型和应用程序服务是单元测试的第一公民。这些测试涵盖了最重要的部分（流控制的应用程序服务和业务规则的域模型）。当我开始学习编写测试时（当时不知道 TDD），它们是我唯一测试的部分。
然后一切都可以在采用tdd之后进行测试。您将需要涵盖持久性、消息传递和其他集成点的集成测试（主要用于测试配置）。
“单元测试什么”问题的最佳答案是......一切 - 根据TDD :)
但是，确保正确配置的组件能够很好地协同工作是集成测试或冒烟测试的一部分。
TDD 中建议的场景是与代码并行编写测试，因此两个代码同时增长。您的问题可能在于您已经拥有代码并且没有单元测试。在这种情况下，有两种可能：
1）您的组件分离良好。然后您可以为每个组件的公共接口编写单元测试，旨在实现高覆盖率（使用一些覆盖率工具测量）。
2）您的组件纠缠在一起。然后我建议尽可能多地编写集成测试，同时以高覆盖率为目标。这将比情况 1) 更难，因此最好测试最典型和关键的场景，然后重构代码以放松一些耦合，然后继续执行步骤 1)。