当我是一名专业程序员时，我从未接受过软件工程方面的正式培训。由于我经常在这里访问，所以我注意到了尽可能编写单元测试的趋势，并且随着我的软件变得越来越复杂，我认为自动化测试是帮助调试的一个好主意。
但是，我的大部分工作涉及编写复杂的SQL，然后以某种方式处理输出。例如，您将如何编写测试以确保SQL返回正确的数据？然后，假设如果数据不受您的控制（例如，第三方系统的数据），那么您如何能有效地测试您的处理例程，而不必手写大量的伪数据？
我能想到的最佳解决方案是对涵盖大多数情况的数据进行查看。然后，我可以将这些视图与SQL连接起来，以查看它是否返回正确的记录，并手动处理视图以查看我的函数等是否正在执行应有的功能。尽管如此，它似乎过于油腻和胡扯。特别是找到要测试的数据...
Answers:
测试与数据库相关的所有内容的重要规则是将其与应用程序的其余部分完全隔离。
的 端口和适配器架构是一个非常好的例子。通过应用程序的适配器，该数据库被视为外部插件。所有第三方子系统也是如此。为了测试您的应用程序的行为方式并解释第三方子系统的响应，我知道如何进行测试的唯一方法是对单个子系统的响应进行存根。我并不一定意味着您必须手动编写所有数据对象。您可以轻松地采用使用数据驱动测试的方法。
关于测试应用程序与数据库的交互方式，您可以伪造数据库适配器以使用内存数据库。
现在测试您的数据库查询。首先，应该将复杂查询分解为更简单，更简单和可预测的查询。对于胖类或胖函数，您将执行相同的操作。有一些工具可以帮助您测试数据库，例如 Dbunit。我有时采用的一种简单方法是使用特性测试的概念。因此，我将数据库置于已知状态，运行我必须编写的所有查询，然后将输出保存在一个位置（文件，内存）中，并认为此输出是正确的输出。下一次运行会将它们的输出与此输出进行比较，因此肯定可以为我提供我需要的回归测试。实际上，不能保证第一个输出是正确的，但是可以通过这种方式解决回归问题。如果您的查询分解得很好，则可以针对处于已知状态的数据库分别对其进行测试。
这是一个有趣的问题，因为数据库通常是在应用程序单元测试期间被伪造的部分。希望提供程序可以对数据库引擎本身的逻辑进行很好的测试，但是查询，模式和存储过程当然是需要测试的代码，并且需要对其进行保护以防止回归。这通常留给不是TDD的集成测试。
视图可能是一种困难的方法，因为视图并没有真正让测试先进行红光，绿光自动测试，这是TDD中首选的每个测试的一个方面。同样，对于视图，您不能在代码之前先编写测试。更好的方法是编写存储过程，在其中可以在过程中添加“断言”逻辑（例如，使用“ if”语句）以测试输出是否失败。您只需在每个单元测试中测试一件事即可隔离该单元，而SP方法将更适合于此。同样，使用SP，您可以在开发初始代码时以及随后在重构时测试回归时将它们的整个套件作为脚本运行。
另外，请注意测试必须是可重复的，并且您将需要一些脚本来初始化和拆除数据库状态，以确保每个单元测试的状态都相同。
如果您对不受您控制的数据有疑问，这是一个困难的领域。我认为您最好使用假数据来模拟它，并尽可能地对异常和边缘条件进行测试以进行单元测试。否则，它将更多地属于集成测试的类别（这也是一件好事）。对于集成测试，您可以针对第三方数据运行测试，并让其生成初始输出，对于后续测试（例如，重构之后），请确保这些输出重复初始已知输出。
在某些时候，您将需要测试数据。如果您使用的是第三方系统，则该架构已经创建，但是您需要解决将来的更改。希望您可以从升级文档中获得这些更改，但是您可能不得不自己比较数据库版本。
预期结果集可以保存在数据库表或外部文件/电子表格中。我什至看过CHECKSUM使用或比较。测试视图/存储过程时，您将失败，因为它们不存在。然后，创建具有足够代码以至少执行（SELECT -1 as [wrong_data];）的对象，由于与结果集不匹配，将失败。一旦它们匹配，您就拥有了绿灯。
我已经开始与项目所有者合作，并要求他们在电子表格中模拟报表，并尝试为我提供部分数据（您可以将结果数据放在测试表中。）。起初有些推迟，但是他们意识到我要创建一个报告，并且无论如何他们都必须对其进行验证。从长远来看，这节省了时间。如果他们要提出更改请求，则可以重做电子表格。现在他们可以回答以下问题：“添加...会有多困难？”