什么是单元测试，你是怎么做的？ [复制]

Question

许多帖子的完全重复：

What is unit testing?
What Makes a Good Unit Test?
New to Unit Testing
Unit Testing - definitions
Learning Unit Testing
How to properly mock and unit test
Unit Testing: Beginner Questions
And many more ...
另外，谷歌site:stackoverflow.com "how do you" unit-test

我已经阅读了一些关于单元测试的问题，但我不完全知道它是什么或你是如何做到的。我希望有人能告诉我以下内容：

• 究竟什么是单​​元测试？它是内置在代码中还是作为单独的程序运行？还是别的什么？
• 你是怎么做到的？
• 应该什么时候完成？是否有时间或项目不这样做？一切都是可单元测试的吗？

非常感谢您的帮助。

Answer 1

单元测试涉及将您的程序分解为多个部分，并对每个部分进行一系列测试。

通常测试作为单独的程序运行，但测试方法会有所不同，具体取决于语言和软件类型（GUI、命令行、库）。

大多数语言都有unit testing frameworks，您应该为自己寻找一个。

测试通常会定期运行，通常是在每次更改源代码之后。越频繁越好，因为越早发现问题。

Answer 2

究竟什么是单​​元测试？是吗 内置在代码中或单独运行 程式？还是别的什么？

From MSDN：单元测试的主要目标是获取应用程序中最小的可测试软件，将其与代码的其余部分隔离，并确定其行为是否完全符合您的预期。

本质上，您正在编写少量代码来测试代码的各个部分。在 .net 世界中，您可以使用 NUnit 或 MBunit 之类的东西，甚至 Visual Studio 中的内置测试工具来运行这些小段代码。在 Java 中，您可能会使用 JUnit。本质上，测试运行者将构建您的项目，加载并执行单元测试，然后让您知道它们是通过还是失败。

你是怎么做到的？

单元测试说起来容易做起来难。要熟练掌握它需要相当多的练习。您需要以一种易于单元测试的方式来构建代码，以使您的测试有效。

应该什么时候完成？是否有时间或项目不这样做？是 一切都可单元测试？

你应该在有意义的地方做。并非所有东西都适合单元测试。例如，UI 代码很难进行单元测试，而且您通常不会从中获得什么好处。然而，业务层代码通常非常适合测试，这是大多数单元测试的重点。

单元测试是一个庞大的话题，要充分了解它如何最大程度地使您受益，我建议您准备一本有关单元测试的书，例如“Test Driven Development by Example”，它可以让您很好地掌握概念以及如何将它们应用到代码中。

Answer 3

什么是单元测试？很难定义。在技​​术层面上，您构建函数来调用代码库中的函数并验证结果。基本上，你会得到一堆像“assert(5+3) == 8”这样的东西，只是更复杂（如 DataLayer(MockDatabase()).getUser().name == "Dilbert"）。 在工具视图级别上，您添加一个自动化的、特定于项目的检查，如果一切仍然像您假设的那样正常工作。如果您重构并实现复杂的算法，这将非常非常有用。 结果通常是一堆文档和更少的错误，因为代码的行为是固定的。

我为所有边缘情况构建测试用例，并以类似于分代垃圾收集器的工作方式运行它们。当我实现一个类时，我只运行涉及该类的测试用例。完成该课程的工作后，我会运行所有单元测试以查看一切是否仍然有效。

您应该尽可能多地进行测试，只要测试代码很容易保持未经测试即可。鉴于此，不，并非所有内容都可以以理智的方式进行测试。想想用户界面。想想航天飞机或核弹的驱动程序（至少不是纯 JUnit 测试；））。但是，有很多代码是可测试的。数据结构是。算法是。大多数应用程序逻辑类都是。所以测试一下！

HTH。特达

Answer 4

我发现说明它的最简单方法是查看一些代码。 NUnit 网站上的这个入门页面很好地介绍了内容和方法

http://www.nunit.org/index.php?p=quickStart&r=2.5

一切都是可测试的吗？一般来说，如果它计算了一些东西，那么是的。 UI 代码是另一个需要处理的问题，因为模拟用户点击按钮很棘手。

你应该测试什么？我倾向于围绕我知道会很棘手的事情编写测试。复杂的状态转换、关键业务计算等等。一般来说，我不太担心测试基本的输入/输出内容，尽管纯粹主义者无疑会说我在这方面错了，一切都应该测试。像许多其他事情一样，没有正确的答案！

Answer 5

关于“如何做”部分：

我认为ScalaTest 的介绍很好地说明了不同风格的单元测试。

关于“何时做”部分：

单元测试不仅仅是为了测试。通过进行单元测试，您还可以强制软件设计成为可单元测试的东西。许多人认为这种设计在很大程度上是 Good Design(TM)，而不管测试带来的其他好处。

所以进行单元测试的一个原因是强制你的设计成为一种希望更容易维护的东西，如果你没有为单元测试而设计它。

Answer 6

什么...

一种针对一系列测试自动测试代码的方法，旨在强制执行预期结果并管理变更。

从这个意义上说，“单元”是代码中对测试有意义的最小原子组件，例如，通常是某个类的方法。此过程的一部分是构建存根对象（或“模拟”），它允许您将单元作为独立对象使用。

如何...

几乎总是，单元测试过程内置于 IDE（或通过扩展）中，这样它在每次编译时都会执行测试。存在许多用于帮助创建单元测试（实际上是模拟对象）的框架，通常命名为 fooUnit（参见 jUnit、xUnit、nUnit）。这些框架提供了一种正式的方式来创建测试。

作为一个过程，测试驱动开发 (TDD) 通常是单元测试的动机（但单元测试不需要 TDD），它假设测试是规范定义的一部分，因此要求首先编写它们, 编写代码只是为了“解决”这些测试。

当...

几乎总是。非常小的一次性项目可能不值得，但前提是您非常确定它们确实是一次性的。理论上每个面向对象的程序都是可单元测试的，但是一些设计模式使这变得困难。众所周知，单例模式是有问题的，相反，依赖注入框架非常面向单元测试。

Answer 7

什么是单元测试？

单元测试只是验证各个代码单元（主要是函数）是否按预期工作。通常你自己编写测试用例，但有些可以自动生成。

测试的输出可以像控制台输出一样简单，也可以是 GUI 中的“green light”，例如NUnit，或其他特定于语言的框架。

执行单元测试被设计为简单，通常测试以函数的形式编写，它将确定返回值是否等于您编写函数时所期望的值（或您期望的值 当你最终编写它时——当你首先编写测试时，这称为Test Driven Development）。

你如何进行单元测试？

想象一个你想测试的非常简单的函数：

int CombineNumbers(int a, int b) {
    return a+b;
}

单元测试代码如下所示：

void TestCombineNumbers() {
    Assert.IsEqual(CombineNumbers(5, 10), 15); // Assert is an object that is part of your test framework
    Assert.IsEqual(CombineNumbers(1000, -100), 900);
}

当您运行测试时，您会被告知这些测试已通过。现在您已经构建并运行了测试，您知道这个特定的功能或单元将按照您的预期执行。

现在假设另一个开发人员出现并更改 CombineNumbers() 函数以提高性能或其他原因：

int CombineNumbers(int a, int b) {
    return a * b;
}

当开发人员运行您为这个非常简单的函数创建的测试时，他们会看到第一个 Assert 失败，他们现在知道构建已损坏。

什么时候应该进行单元测试？

它们应该尽可能多地进行。当您在开发过程中执行测试时，您的代码会自动设计得比您只是编写函数然后继续前进的情况更好。此外，Dependency Injection 等概念将自然地演变到您的代码中。

最明显的好处是知道在进行更改时，如果其他单个代码单元都通过了测试，则不会受到它的影响。