我应该多久/多久一次测试？

Question

作为一个正在进入我的第一个专业项目节奏的新手开发者，我正在努力尽快养成良好的习惯。 但是，我发现我经常忘记测试，推迟测试，或者在构建结束时进行一大堆测试而不是一次测试。

我的问题是你喜欢在大型项目上进行的节奏，以及测试适合它的地方。

Answer 1

好吧，如果你想跟随TDD人， 在开始编码之前 ;）

我和你的立场非常相似。 我想更多地进行测试，但我目前处于一个我们正在努力“解决代码”的位置，而不是“正确地获取代码”，这让我感到害怕。 所以我慢慢地尝试在我的开发周期中集成测试过程。

目前， 我测试我的代码，尝试在编写代码时破坏代码 。 我觉得很难进入TDD思维模式..它需要时间，但这就是我想要工作的方式..

编辑：

我想我应该扩展一下，这是我的基本“工作过程”......

1. 从代码，可能的对象设计，无论如何计划我想要的。
2. 创建我的第一堂课，在顶部添加一个巨大的评论，概述我对班级的“愿景”。
3. 概述基本测试场景..这些基本上将成为单元测试。
4. 创建我的第一个方法。还写了简短的注释解释它是如何预期工作。
5. 编写一个自动化测试，看它是否符合我的预期。
6. 对每种方法重复步骤4-6（注意自动化测试位于F5上运行的巨大列表中）。
7. 然后我创建了一些强大的测试来模拟工作环境中的类，显然可以解决任何问题。
8. 如果在此之后出现任何新的错误，我会返回并编写新的测试，确保它失败（这也可以作为bug的概念验证）然后修复它。

我希望有所帮助。开放评论如何改进这一点，正如我所说，这是我的一个问题..

Answer 2

在检查代码之前。

Answer 3

什么时候测试？ 当代码正常工作很重要时！

Answer 4

首先，经常。 如果我正在为系统创建一些新功能，我将首先定义接口，然后为这些接口编写单元测试。 要计算出要编写的测试，请考虑接口的API及其提供的功能，拿出笔和纸，并考虑一下潜在的错误条件或证明它正在执行正确工作的方法。 如果这太难了，那么你的API可能不够好。 关于测试，看看你是否可以避免编写测试多个特定对象的“集成”测试，并将它们作为“单元”测试。

然后创建一个接口的默认实现（什么都不做，返回垃圾值但不抛出异常），将其插入测试以确保测试失败（这测试您的测试工作！:)）。 然后写入功能并重新运行测试。 这种机制并不完美，但会涵盖许多简单的编码错误，并为您提供运行新功能的机会，而无需将其插入整个应用程序。

然后，您需要在主应用程序中使用现有功能的组合对其进行测试。 这是测试更加困难的地方，如果可能的话，应该将其部分外包给优秀的QA测试人员，因为他们有破坏性的诀窍。 虽然如果你有这些技能也会有所帮助。 正确的测试是一个诀窍，你必须认真对待。 我自己的经验来自于我自己的天真部署以及用户在愤怒中使用它时报告的后续错误。

起初，当我遇到这种情况时，我发现用户故意试图破坏我的软件并且我想将所有“错误”标记为“培训问题”，这令人恼火。 然而，在反思之后，我意识到我们的角色（作为开发人员）使应用程序尽可能简单可靠地使用，即使是白痴也是如此。 我们的角色是赋予白痴权力，这就是我们为什么得到美元的报酬。 白痴处理。

为了有效地进行这样的测试，你必须进入试图打破一切的心态。 假设用户的外壳打击按钮并且通常试图以奇怪和奇妙的方式破坏您的应用程序。 假设如果你没有发现瑕疵，那么它们将在生产中被发现给你的公司严重损失。 对所有这些问题承担全部责任，并在生产中发现您负责（甚至是部分责任）的错误时诅咒自己。

如果您完成上述大部分工作，那么您应该开始生成更强大的代码，但它有点像艺术形式，需要很多经验才能擅长。

Answer 5

要记住的一个好关键是

“早点测试，经常测试并再次测试，当你认为你完成了”

Answer 6

当我为自己一起黑客攻击时，我会在最后测试。 不好的做法，但这些通常都是小事，我会用几次就是这样。

在一个更大的项目中，我在编写一个类之前编写测试，并在每次更改该类之后运行测试。

Answer 7

我经常测试。 在我完成函数内部的循环之后，我运行程序并在循环顶部点击一个断点，然后运行它。 这只是为了确保流程完全符合我的要求。

然后，一旦一个函数完成，你就可以完整地测试它。 您可能希望在调用函数之前设置断点，并检查调试器以确保它完美运行。

我想我会说：“经常测试。”

Answer 8

我最近才将单元测试添加到我的常规工作流程中，但是我编写了单元测试：

• 表达每个新代码模块的要求（在我编写接口之后但在编写实现之前）
• 每当我想到“它做得更好......到我完成的时候”
• 什么东西坏了，量化错误，并证明我已经修复它
• 当我编写显式分配或释放内存的代码时 - 我厌恶寻找内存泄漏......

我在大多数构建上运行测试，并且始终在运行代码之前。

Answer 9

从单元测试开始。 具体来说，请查看TDD，测试驱动开发。 TDD背后的概念是先编写单元测试，然后编写代码。 如果测试失败，您将返回并重新编写代码。 如果它通过，你继续下一个。

我采用混合方法来进行TDD。 我不喜欢编写任何测试，所以我通常首先编写一些代码，然后将单元测试放入。这是一个迭代过程，一个你从未真正完成的过程。 您更改代码，运行测试。 如果有任何失败，修复并重复。

另一种测试是集成测试，它在过程的后期出现，通常可以由QA测试团队完成。 在任何情况下，集成测试都需要测试整个部件的需求。 这是您关注测试的工作产品。 这个更难以处理b / c它通常涉及自动化测试工具（例如Robot，例如）。

另外，看一下像CruiseControl.NET这样的产品来做连续构建。 CC.NET是不错的b / c它会在每次构建时运行你的单元测试，立即通知你任何失败。

Answer 10

我们不在这里做TDD（虽然有些人提倡它），但我们的规则是你应该检查你的单元测试你的更改。 它并不总是会发生，但很容易回过头来查看特定的变更集，看看是否编写了测试。

Answer 11

这里有很多很棒的答案！

我尝试在有意义的最低级别进行测试：

• 如果单个计算或条件很难或很复杂，请在编写时添加测试代码并确保每个部分都有效。 完成后注释掉测试代码，但留在那里记录您如何测试算法。

• 测试每个功能。

  • 每个分支至少锻炼一次。
  • 练习边界条件 - 代码改变其行为的输入值 - 捕获“一个一个”错误。
  • 测试有效和无效输入的各种组合。
  • 查找可能破坏代码并测试它们的情况。

• 使用与上述相同的策略测试每个模块。

• 测试代码体整体，以确保组件正确交互。 如果您一直在努力进行低级测试，那么这基本上是一种“置信度测试”，以确保在组装过程中没有任何损坏。

由于我的大部分代码都是针对嵌入式设备的，因此我特别注意稳健性，各种线程，任务和组件之间的交互以及资源的意外使用：内存，CPU，文件系统空间等 。

一般来说，越早遇到错误，就越容易隔离，识别和修复它 - 而且你花费的时间越多，而不是追逐你的尾巴。*

**我知道，-1是免费的缓冲区指针引用！*

Answer 12

我发现，如果我等到编写一些新功能进行测试结束时，我会忘记许多我认为可能会破坏该功能的边缘情况。 如果你正在为自己学习，这是好的，但在专业的环境中，我发现我的流程是经典的形式：红色，绿色，重构。

红色 ：编写测试以使其失败。 这样你知道测试是针对正确的变量断言的。

绿色 ：以最简单的方式让您的新测试通过。 如果这意味着硬编码，那没关系。 这对于那些只想立即工作的人来说非常棒。

重构 ：现在您的测试通过了，您可以放心地更改代码。 你的新改变打破了你的考验？ 太棒了，你的改变有一个你没有意识到的含义，现在你的测试告诉你了。

这个节奏让我随着时间的推移加快了我的发展，因为我基本上有一个历史编译器，用于我认为需要检查的所有事情才能使功能正常工作！ 这反过来又带来许多其他好处，我不会到这里来......