我有一个关于测试驱动开发的问题，我正在努力学习。
我一直在审查我公司的一个团队交付的一个项目，看看他们在测试中包含了什么样的东西。
基本上，对于解决方案中的每个项目，都有一个相应的测试项目。这包括数据层中的项目。我发现该项目中的测试实际上是在访问数据库，并根据检索到的数据进行断言。
事实上，服务层中的类的测试也会影响数据库。
这在TDD中正常吗？如果没有，并且那些正在测试的类除了检索数据之外什么也没做，那么测试它们的最佳方式是什么？我敢说，他们应该接受测试吗？如果TDD有助于推动设计，可以说他们应该这样做。
TDD之王怎么说？
在TDD中，从大多数测试中访问数据库是正常的吗？是的，不幸的是，这比应该的更正常。但这并不意味着这是正确的。
TDD:有多种风格
- 由GOOS推广的Outside In TDD
- 自底向上TDD，这是一种"老"风格，您可以首先开发"叶子"组件
当您使用Outside In方法时，通常会以一些粗粒度测试开始，以充实系统的行为。这些很可能会进入数据库。没关系。
然而，您不能仅从复杂应用程序的边界来正确测试基本正确性，因为所需测试用例的组合爆炸是令人望而却步的。实际上，您必须编写数以万计或数十万个测试用例。
因此，即使使用Outside In方法，您也应该在单元级别编写大多数测试这些测试不应该访问数据库。
如果您使用自下而上的样式，那么在大多数情况下不应该访问数据库。
简而言之，TDD意味着测试驱动开发，而不一定是单元测试驱动开发，所以只需要一些测试就可以访问数据库。然而，这种测试往往缓慢而脆弱，因此应该只有少数测试。测试金字塔的概念很好地解释了这一点。
如果你想了解更多，你可能想看我的Pluralsight课程
- 外部测试驱动开发
- 高级单元测试