从哪里开始编写单元测试[关闭]答案

【问题标题】：Where to start writing unit tests [closed]从哪里开始编写单元测试[关闭]
【发布时间】：2013-10-10 20:41:48
【问题描述】：

我的老板决定为我已经研究了一段时间的 Java 程序编写单元测试是个好主意。该程序是您相当典型的混乱，但它并不大。我以前从未使用或编写过任何单元测试，并且从我所读过的关于该主题的所有内容来看，预先存在的项目并不是最好的起点。不过我真的没有选择，所以我有一些问题。

我的主要问题是：我已经阅读了很多关于单元测试应该做什么、它们的范围应该是什么、如何在 TDD 过程中编写生产代码等方面的内容。我还没有找到任何会说话的人关于代码实际应该去哪里。我是否在生产代码类中自己编写测试？我是否将它们全部放在一个单独的 .java 文件（或多个文件）中？我是否将它们放在项目中自己的目录中？如果我使用后一个选项中的任何一个，我将如何访问私有对象和方法以测试它们？我觉得这应该是一个相当明显的问题，但我就是不知道。

还有一个次要问题：我已经看到很多关于使用 TDD 的令人信服的论据，我想在我的个人项目中尝试一下。无论我的第一个问题的答案是否适用于启动全新的项目？或者我会为现有项目而不是新项目实施不同的单元测试吗？

【问题讨论】：

数以百万计的搜索结果准确地回答了您提出的问题 - 在 SO 上再次询问似乎很浪费时间。
你有问题，分离测试是一个小问题。主要问题是代码不会被编写来进行测试，为了测试它，你必须改变它，而且你没有单元测试来证明你为测试它所做的改变没有破坏它。如果它很小，请将您当前的代码视为概念证明，重新开始并使用 TDD 执行，即正确。
向预先存在的项目添加测试很好——很好，甚至。这似乎需要更多的工作，因为您必须进行初始推动，而不是逐步建立它。您可能会发现，在此过程中，您必须重构类以使它们更小、更模块化，这甚至可能使代码不那么混乱。

标签： java unit-testing

【解决方案1】：

测试不在生产代码中，您可以将它们放在单独的子目录中。如果您了解 Maven，该项目会强制执行标准目录结构，因此您的生产代码位于 src/main/java 下，属性文件位于 src/main/resources 下，而测试则位于 src/test/java 下Java 代码使用的文件位于 src/test/resources 下。 Maven 确保 src/test 中的任何内容都不会进入它构建的工件。（使用 ant 的本地构建通常会遇到这个问题，因为您必须真正考虑事情的发展方向，并努力将测试和代码分开，否则一切都会被抛到一起。）

即使您不能使用 maven，也值得复制目录结构以遵循共同商定的模型。

您应该能够通过在测试中实例化它们并调用它们的方法来测试您的对象。如果您编写了很多没有测试的代码，那么您可能以难以测试的方式编写它，例如使用单例。您可能需要重新编写一些现有代码以使其更易于测试。

【讨论】：

我的问题中忘记了一个字。我将如何访问 private 类和方法？我也很好奇：这个通用约定对于其他语言是否相同（我有一个用 C# 编写的私人项目）？
@DementedDr：简短回答：你没有。实际上，直接访问这样的实现细节的测试可能是一个问题，因为如果您的实现发生变化，您必须对测试进行大量返工。编写测试的一个棘手的事情是弄清楚如何使它们足够具体以使其有用，同时保持它们的可维护性。很多时候，对于一个足够复杂而值得测试的实现私有的东西可以重构为一个单独的类并单独执行。 C# 原则上应该类似，但目录结构可能不同。

【解决方案2】：

我将从您的错误开始。当您要修复错误时，请编写一个显示错误的测试。当您修复错误时，您的测试应该通过。顺便说一句，预计一半的错误会出现在您的测试中。

当您编写如此微不足道的测试时，它们不会失败，但它们确实会失败，您会看到进行测试的价值。在用户看到之前，当它们更容易修复时，会更早地发现各种问题。

【讨论】：

【解决方案3】：

如果您以前从未使用过 TDD，您会发现本教程非常有用：

Junit Tutorial

【讨论】：

【解决方案4】：

开始测试项目永远不会太晚，您不必担心。

您需要学习 TestNG 或 JUnit 4 for java。

您应该在单独的目录中为您的测试创建单独的 java 文件。您的测试类名称应以 Test 结尾，例如：对于 MyClass.java 主代码，您编写一个 MyClassTest.java 测试类。

其他部分的问题，请访问：What is unit testing and how do you do it?

【讨论】：

【解决方案5】：

将测试添加到没有测试的现有遗留代码的方法是将它们添加到您更改的任何部分。

即使您决定程序在没有良好的单元测试覆盖率的情况下无法继续运行，您也会这样做，因为它会从 0% 覆盖率上升到更高的数字。请记住，带有 1 次测试的系统比带有 0 次测试的系统有更多的测试！

您将遇到的主要问题是程序各部分之间的现有接口不适合测试。通常这是一种紧密耦合，需要设置几乎所有的子系统，然后才能执行简单、隔离的测试。

解决这个问题的一个好方法是使用模拟来模拟难以解耦的部分的依赖关系

【讨论】：