关于单元测试的几个问题

在调用类之前编写单元测试的方法 Test-Driven Development (TDD)并在2000年代早期由KentBeck推广,其思想是编写一个描述所需功能的测试。最初,此测试将失败。当你写你的课时,测试通过了。您重构测试以添加更多所需的功能,然后重构类以通过此新测试。考试一通过,你的班级就达到了目标。当然,这也超出了课堂范围。

至于要编写什么类型的测试,这取决于您是测试公共API还是私有API。公共API应该有更广泛的测试来确保输入格式良好,特别是如果您不完全信任API的用户。私有API(仅由代码调用的方法)可能在没有这些测试的情况下就可以逃脱惩罚——我怀疑您可以信任自己的开发团队,不要向他们传递坏数据。

Test Driven Development 是一个相当普遍的概念。基本的想法是,您试图只编写满足软件某些需求所必需的代码。所以,您为需求编写一个测试,然后编写代码使测试通过。

我个人不使用TDD,但我认识这样做的人。我个人的想法是,如果你在做一些更为应用程序驱动的事情,比如数据库或用户界面,这是非常有用的。但是,对于算法更重的东西(比如物理模型),我发现它打破了我的思路,阻碍了我的前进。

首先编写单元测试是很常见的做法。一个很大的好处是,您不仅要编写代码将通过的测试,而且要编写定义什么是重要的、您试图实现什么以及您希望确保什么不会发生的测试。它可以帮助你充实你的设计。此外,您还可以在编码之前与外部涉众一起审查该规范。

至于写什么测试,根据你的时间,这有点主观。我不会去疯狂的审查代码的场景,它将永远不会面对。也就是说,输入使代码“永远看不见”的东西是令人惊讶的。所以,更多的测试是更好的,但在某一点上回报肯定会减少。

你正在编码的语言很重要。动态语言需要更多的测试,因为编译器捕获的问题更少,而错误可能更难跟踪(因为它们可以从最初的输入问题传播得更远)。至少,这是我的观点。

它还可以改变输入的来源。公众应该被认为是恶意的(即网络),员工应该被认为是不称职的,甚至是同事(和你自己!)应该被认为至少是粗心的。但当你接近你的内心世界时,危险就降临了。

有人真的遵循这种方法吗?

对。

这在纸上看起来是个好主意,但实际上是吗?

对。

您是否应该编写单元测试来查看您的方法如何处理错误/恶意输入?

对。

那些永远不应该将这种类型的输入传递给它们的函数呢?你在什么地方画这条线?

当它从软件转向精神病时。

如果您愿意,您可以为不可能的情况编写测试。然而,你在浪费你的时间和你的雇主在一个明显的方式。

为编写测试 定义 用例。就是这样。

您不会根据自己的想象来编写随机的测试用例。

如果…怎么办? 如果是 定义 用例不完整?真倒霉。您可以为官方的、契约的、公共的接口编写测试——仅此而已。

如果设计不充分,并且您意识到给定的接口充满了不完整的规范、矛盾和安全漏洞,该怎么办?这与测试无关。这只是编程。坏的设计就是坏的设计。

如果一些恶意的反社会者拿走了您的代码,并以超过(或不符合)定义的规范的方式使用它,该怎么办?真倒霉。反社会者获胜。他们能够把你的代码放在你没有测试过的不可能的情况下。因为他们聪明,给他们买杯啤酒。

测试前和测试后的心态有差异。以前写测试是 设计 ,因为您正在设计代码的接口并定义预期的行为。然后编写通过测试的代码,验证您的设计。在开发结束时,您正好已经有了一套测试!

在测试之后,您需要小心避免编写现有代码将通过的测试的陷阱。这是一个不同的焦点,你不会像之前的版本测试那样从中得到那么多。

已经有相当多的答案了,但我想再多想想第二个问题。

如果将UnitTest代码设置为“数据驱动”,那么不管代码是测试“坏”输入还是“好”输入。重要的是,您有足够大的数据集来覆盖这两个方面。