在单元测试中检查文件内容/编码是否被认为是“不良做法”？

有一点上下文：今天早些时候，我不得不更新我的另一位同事提供的一些SQL代码，由于它是一个很大的脚本，因此将其存储为单独的文件（然后在运行时读取并执行）。在执行此操作时，我不小心重新引入了几个月前的两个错误，即：

• 出于任何原因，ASCII文件都以UTF-16编码（同事通过电子邮件将其发送给我，这可能是导致该文件的原因）。
• 该脚本缺少初始SET语句（由于生产中使用了某些驱动程序，而本地没有进行全新安装，因此该脚本是必需的）。

经过大约一个小时的调试之后，我决定编写一些单元测试以确保不再发生这种情况（并在断言消息中包含一种快速修复它的方法，以便于将来的开发人员轻松修复）。

但是，当我推送此代码时，另一个同事（也是我们团队的负责人）走到我面前，告诉我，我不应该再做这些事情，因为：

“这些东西不属于单元测试”

“单元测试仅应用于检查代码流”

我现在很矛盾，因为我仍然认为自己做的没错，因为以后不会再引入此错误，但是这位同事还是一名资深人士，最终可以决定我们花时间在。我该怎么办？我这样做不对吗？是否被认为是不良做法？

您编写的测试很可能比单元测试更接近集成或回归测试。尽管这条线可能很模糊，有时会成为关于什么是单元测试或不是单元测试的棘手问题，但我还是回到您的同事那里，问您编写的测试应该在哪里，因为它们确实增加了价值，从而确保了代码的正确性。

我不会过多地关注什么是单元测试或什么是单元测试，并且意识到即使是集成测试，测试中仍然会有价值。

从技术上讲，它不是单元测试，而是更多的验证步骤。正确的方法实际上取决于您的工作流程需要。您的团队负责人对单元测试的目的是正确的。我的感觉是，这种情况下仍需要使用错误的工具来完成一项工作。因此，从此开始：

我要解决的问题是什么？

通过描述，您需要验证所有数据库脚本是否符合某些标准。

有哪些工具/过程可用来解决问题？

通常通过静态分析工具检查源代码的质量。如果您没有静态分析工具来验证SQL，则可以创建一个快速而肮脏的工具，该工具可以对传入的任何 SQL文件执行检查。检查是否有静态分析工具可以处理您正在讨论的问题，这没有什么坏处。

如果您将其作为构建基础结构的一部分，例如将其合并到Jenkins中或类似的东西，则可以将其应用于项目中的所有SQL文件。

单元测试只能解决当前文件的问题。

如何传达对工具的需求？

这很简单，您可以咨询团队负责人。他可以与产品负责人以及您一起确定投资工具的风险/回报。如果这可能是一次性的问题，那么该工具可能会过大。如果解决最大问题的工具很容易，那么仅进行健全性检查就值得。

您的团队负责人可能有一些您（或我）没有考虑过的想法，可以更正确地解决问题。

将访问文件的测试称为“单元测试”是不好的做法。

他：“这些东西不属于单元测试”

您：“说得通，但是我找不到放置它们的更好的地方。它们属于哪里？”

不幸的是，存在哪些测试以及如何组织这些测试完全取决于公司。因此，您需要了解贵公司如何处理这些测试。

如果除单元测试之外，您还没有其他方法可以运行自动化测试，那么实用的方法是使用前缀将实际上不是单元测试的单元测试标记为前缀，直到您有足够的能力来开始找出哪种类型的单元测试为止。您实际需要的测试。之后，您可以开始整理。

迈克尔·费瑟斯（Michael Feathers）在他的《有效处理旧版代码》一书中说过：

在行业中，人们经常来回讨论特定测试是否为单元测试。[...]我回到两种品质：测试运行速度快吗？它可以帮助我们快速定位错误吗？

您的测试是否可以帮助您快速定位错误并快速运行？如果是，那就去做！如果没有，那就不要！就这么简单！

话虽如此，您正在与其他人一起工作的环境中，必须与他们相处。即使您私下不同意，您也可能不得不以自己的方式来做。

我有时针对源代码文件，配置文件等编写了类似的测试。我不会称其为单元测试，因为（a）它们正在访问文件系统并且可能不是超快的（b）我不在乎是否在每次签入时都执行它们（相对于每晚CI服务器）。

您可以将它们称为集成测试；当然，它们比单元测试更接近于这种观点。

我对它们的术语是资源测试。恕我直言，如果它们在CI服务器上每晚执行，则完全有道理：成本最低，并且，如果明智地使用，显然会增加价值。一个明智的定义：如果测试正在检查引起问题的问题（例如您提到的编码）。

单元测试就是关于测试方法或代码“单元”的全部。您正在测试软件中最小的一组逻辑和代码。

稍后，当您将其与其他单元一起加入时，您将执行集成测试。

我希望您的团队领导鼓励您的主动性，并且应该提出其他建议。您绝对有正确的想法。

您的SQL就像其他任何较低代的语言（如C＃或Java）一样，都是代码，因此应经过测试。验证和确认属于所有测试级别。因此，包含了编码和SET语句，但不一定要进行独家测试。诸如行尾或括起来的常规内容通常只能使用SCM挂钩或功能。

最佳实践是进行回归测试，以确保不会再次引入过去的错误。通常，将与错误的任何解决方案一起创建测试。如果这些错误未在单元/集成或系统级别的回归测试中涵盖，然后重新引入，则是团队问题，过程问题，而不是单个问题。

问题是...语法错误，“单元”中缺少语句或逻辑块通常不会得到测试。您正在以不同组合测试设备的输入和输出，并测试可能产生的多种可能性。

回到丢失的SET语句-它们有助于告知输入和输出进行测试的多种可能性。如果缺少任何选定的SET，您会写什么测试失败？

如果您的文件成为产品的一部分，则其内容必须正确。没有理由不验证这一点。例如，如果您在某个文件夹中需要六个1024x 1024图像，则一定要编写一个单元测试来检查您是否具有正确的图像。

但是您可能不仅拥有这些文件，还拥有一些读取文件的代码。您可以为该代码编写单元测试。在上面的示例中，读取六个图像之一的函数是否在内存中返回1024 x 1024图像（或应该产生的图像）。

无论如何，它可能不是单元测试，但它是有用的测试。而且，如果您使用允许您执行有用测试的单元测试框架（不是单元测试），为什么不使用单元测试框架呢？

也许我误解了您的问题，但是对我来说，这听起来像是一个问题，不需要任何形式的专用测试即可捕获，而只需通过版本控制系统即可捕获。对代码库的任何更改都应在提交前逐个补丁进行审查。在git中执行此操作的一种简单方法是添加更改

git add -p

对于文本文件中的每个更改，工作目录都会询问您是否真的要保留它。例如，这将使您看到那些“初始SET语句” 的删除。

如果整个文件的编码发生更改，则可能会有所不同：算法将无法区分新旧文件，因此git add -p根本不会添加任何内容。这将在我进行任何提交之前执行的其他命令中可见，即

git status

在这里，你会看到以红色突出显示的文件，表明有是变化。调查这些原因为何没有git add -p迅速解决，这将使问题显而易见。

需要考虑的另一个角度：由于这两个条件是程序运行的要求，因此您是否不应该将逻辑嵌入到执行逻辑附近？我的意思是：您在读取文件和/或验证其内容之前先测试文件的存在，对吗？那么这有何不同？我认为，由于这是代码外部资源，因此应在实际使用之前在运行时对其进行验证。结果：更强大的应用程序，无需编写其他测试。

测试与任何其他代码都是相同的代码，并且如果足够复杂，也可以从...单元测试中受益。将此类前提条件检查直接添加到测试中似乎最简单。

大多数测试足够简单，不需要这样做，但是如果其中一些测试足够复杂，那么这些前提条件检查根本看不出任何根本性的错误。当然，没有它们，测试也应该失败，但是一个好的单元测试也可以告诉哪个单元失败了。

用作测试一部分且必须具有一定内容和编码的脚本可能是一个单元。它可能比其余测试具有更多的代码和逻辑。使用这种脚本进行的测试不是有史以来最好的设计，并且如果可能的话，应该将其重构为更直接的内容（除非这是集成测试）。

首先-测试的目的之一是防止代码中再次出现问题-因此，您绝对应该继续编写这种性质的测试。

其次-命名很难。是的，这些显然不是“单元测试”，但是它们可能是构建过程中理想的和必要的部分，因为它们可以保护您免受明显的错误的影响，并且因为它们可以更快地为您提供有关错误的反馈（特别是鉴于您看不到错误）。对开发人员的影响）。

因此，问题的实质（应该在您的上下文中）更多地是关于何时以及如何运行这些测试，而不是它们是什么。

过去，我已经广泛使用这种测试-他们为我们节省了很多痛苦。

单元测试是关于独立执行一个代码单元，以确认它针对正确的输入产生了正确的结果。隔离应该使被测单元和测试本身都具有可重复性，即不应依赖或引入副作用。

SQL并非完全可以单独进行测试，因此任何SQL测试都不完全是单元测试，并且除SELECT语句外几乎可以肯定会产生副作用。我们可以称其为集成测试而不是单元测试。

始终明智的做法是确保在开发周期中尽早发现可能引入的任何缺陷，并且这样做的好处是易于识别缺陷的来源，从而可以迅速发现缺陷。更正的。

有问题的测试可以更适当地从“单元测试”的主体中移出并放置在其他位置，但是如果它们正在做一些有用的事情，例如防止可能会引入几个小时的缺陷，那么就不应将其完全删除。下。