单元测试难题

Question

我希望将单元测试作为项目回归测试的一种手段。

然而，我的问题是该项目基本上是一个美化的DIR命令 - 它对结果执行正则表达式测试和MD5过滤器，并允许指定许多标准，但整个事情旨在处理来自它运行的系统。

我也是一个单人开发团队，我质疑由我编写的代码测试的价值。

在这种情况下，单元测试是否值得？如果是这样，这样的测试怎么可能完成？

编辑：MD5和Regex函数不是由我提供的 - 它们分别由Crypto ++库和Boost提供。因此，通过测试它我没有获得多少收益。我将大部分代码简单地输入到库中，然后打印出结果。

Answer 1

test-after的值，你问的方式，在某些情况下确实可以受到限制，但单元测试的方法，从描述中将正则表达式测试和MD5过滤器分离成一段代码，并抽象输入的输入，以便在生产中从系统提供，并在单元测试期间，您的测试类传入该输入。

然后，您将收集您打算支持的不同方案的样本，并通过执行每个方案的不同单元测试来提供这些方案。

如果您必须更改代码以处理新方案，我认为单元测试的价值将会出现。您将确信在进行更改时旧方案不会中断。

Answer 2

  

在这种情况下单元测试是否值得？

不一定：特别是对于单人团队而言，我认为自动测试大于“单位”的东西可能就足够了......“ Should one test internal implementation, or only test public behaviour? 的详细信息“

Answer 3

单位测试仍然可以在单人秀中提供价值。它使您对模块的功能和正确性（在某种程度上）充满信心。但是可能需要一些设计考虑因素来帮助使测试更适用于您的代码。模块化有很大的不同，特别是如果与某种依赖注入相结合，而不是紧耦合。这允许协作者的测试版本用于单独测试模块。在您的情况下，模拟文件系统对象可以返回可预测的数据集，因此可以评估您的过滤和标准代码。

Answer 4

回归测试的价值通常在自动化之前无法实现。一旦完成，事情变得容易多了。

这意味着您必须能够从已知位置开始（如果您在文件上生成MD5，则必须每次都使用相同的文件）。然后得到一个成功的运行，你可以保存输出 - 这是基线。

从那时起，回归测试只是一个按钮式工作。开始测试，收集输出并将其与已知基线进行比较（当然，如果输出发生变化，您需要手动检查，或者在将其保存为新基线之前使用其他独立脚本）。

请记住，回归测试的想法是捕获新代码引入的任何错误（即，回归软件）。它不是要测试新代码的功能。

自动化程度越高，即使作为一个人的开发团队，也越好。

Answer 5

当你编写代码时，你是否在测试时进行了测试？这些测试可以写入自动脚本中，这样当你必须在2个月内完成更改时，你可以重新运行所有这些测试，以确保你没有退步。

根据我的经验，回归的几率会急剧增加，具体取决于在完成第1版并开始编码第2版之后的时间，因为您通常会忘记在不同条件下它的工作方式的微妙细微差别 - 您的单元测试是编码这些细微差别的一种方式。

Answer 6

对文件系统进行集成测试是值得的。只要确保它做了它需要做的事情。

Answer 7

1. 单人测试场景中的单元测试是否有价值？绝对可以！没有什么比能够绝对自信地重构您的代码更好的了，你没有破坏任何东西。

2. 如何对此进行单元测试？模拟系统调用，然后测试其余逻辑。

Answer 8

  

我质疑由我编写的代码测试的价值

嗯，现在确实如此，但是在一年之内，你将成为一名经验更长的开发人员，开发人员可以根据您现在编写的软件进行开发，而不是经验丰富，知识渊博的开发人员（相比之下）。难道你不想要那些经验不足的人（你一年前）编写的代码经过适当的测试，这样你就可以放心地做出改变吗？