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