我有一个关于测试驱动开发的问题，这是我想要学习的东西。
我一直在审查我公司团队提供的一个项目，看看他们在测试中包含了哪些内容。
基本上，对于解决方案中的每个项目，都有相应的测试项目。这包括数据层中的项目。我发现该项目中的测试实际上是在访问数据库并根据检索到的数据进行断言。
实际上，Services层中的类测试也会访问数据库。
这在TDD中是否正常？ 如果没有，并且如果被测试的那些类除了检索数据之外什么都没做，那么测试它们的最佳方法是什么？ 我敢说，他们应该接受测试吗？如果TDD有助于推动设计，可以说他们应该。
那里的TDD国王说了什么？
答案 0 :(得分：3)
从TDD中的大多数正常测试中击中数据库？是的，不幸的是，它应该比它应该更正常。但这并不意味着它是正确的。
TDD有各种风格：
当您使用Outside-In方法时，您通常会启动并进行一些粗粒度测试，以充实系统的行为。这些可能很好地打击了数据库。没关系。
但是，由于combinatorial explosion of required test cases is prohibitive，您无法仅从复杂应用程序的边界正确测试基本正确性。你真的必须编写数万或数十万个测试用例。
因此，即使使用Outside-In方法，您也应该在单元级别编写大部分测试。 这些测试不应该打到数据库。
如果您使用的是自下而上的样式，则在大多数情况下不应该使用数据库。
简而言之，TDD意味着测试驱动开发，不一定是单元测试 - 驱动开发，因此可以通过一些测试来访问数据库。然而，这样的测试往往是缓慢而脆弱的，所以应该只有少数几个。 Test Pyramid的概念很好地解释了这一点。
如果您想了解更多信息，可能需要观看我的Pluralsight课程