作为一个正在进入我的第一个专业项目节奏的新手开发者，我正在努力尽快养成良好的习惯。但是，我发现我经常忘记测试，推迟测试，或者在构建结束时进行一大堆测试而不是一次测试。
我的问题是你喜欢在大型项目上做什么节奏，以及测试适合它的地方。
答案 0 :(得分：6)
好吧，如果你想跟随TDD人员，在你开始编码之前;）
我和你的立场非常相似。我想更多地进行测试，但我目前处于一个我们正在努力“解决代码”的位置，而不是“正确地获取代码”，这让我感到害怕。所以我慢慢地尝试在我的开发周期中集成测试过程。
目前，我测试代码，尝试在编写代码时破坏代码。我觉得很难进入TDD思维模式..它需要时间，但这就是我希望工作的方式..
我认为我应该扩展这个，这是我的基本“工作过程”...
我希望有所帮助。开放评论如何改善这一点，正如我所说，这是我的一个关注点。
答案 1 :(得分：2)
在检查代码之前。
答案 2 :(得分：1)
首先经常。 如果我正在为系统创建一些新功能，我将首先定义接口，然后为这些接口编写单元测试。要计算出要编写的测试，请考虑接口的API及其提供的功能，拿出笔和纸，并考虑一下潜在的错误条件或证明它正在执行正确工作的方法。如果这太难了，那么你的API可能不够好。 关于测试，看看你是否可以避免编写测试多个特定对象的“集成”测试，并将它们作为“单元”测试。
然后创建一个接口的默认实现（什么都不做，返回垃圾值但不抛出异常），将其插入测试以确保测试失败（这测试你的测试工作！:)） 。然后写入功能并重新运行测试。 这种机制并不完美，但它将涵盖许多简单的编码错误，并为您提供运行新功能的机会，而无需将其插入整个应用程序。
然后，您需要在主应用程序中使用现有功能的组合对其进行测试。 这是测试更加困难的地方，如果可能的话，应该将其部分外包给优秀的QA测试人员，因为他们有破坏性的诀窍。虽然如果你有这些技能也会有所帮助。 正确的测试是一个诀窍，你必须认真对待。我自己的经验来自于我自己的天真部署以及用户在愤怒中使用它时报告的后续错误。
起初，当我遇到这种情况时，我发现用户故意试图破坏我的软件并且我想将所有“错误”标记为“培训问题”，这令人恼火。然而，在反思之后，我意识到我们的角色（作为开发人员）使应用程序尽可能简单可靠地使用，即使是白痴也是如此。我们的角色是赋予白痴权力，这就是我们为什么得到美元的报酬。白痴处理。
为了有效地进行这样的测试，你必须进入试图打破一切的心态。假设用户的外壳打击按钮并且通常试图以奇怪和奇妙的方式破坏您的应用程序。 假设如果你没有发现瑕疵，那么它们将在生产中被发现给你的公司严重损失。对所有这些问题承担全部责任，并在生产中发现您负责（甚至是部分责任）的错误时诅咒自己。
如果您完成上述大部分工作，那么您应该开始制作更强大的代码，但这是一种艺术形式，需要很多经验才能擅长。
答案 3 :(得分：1)
要记住的一个好关键是
“早点测试，经常测试并再次测试，当你认为你完成了”
答案 4 :(得分：1)
何时测试？当代码正常运行时很重要！
答案 5 :(得分：0)
当我为自己一起黑客攻击时，我会在最后测试。不好的做法，但这些通常都是小事，我会用几次，就是这样。
在一个较大的项目中，我在编写一个类之前编写测试，并在每次更改该类之后运行测试。
答案 6 :(得分：0)
我经常测试。在我完成函数内部的循环之后，我运行程序并在循环顶部点击一个断点，然后运行它。这只是为了确保流程完全符合我的要求。
然后，一旦一个函数完成，你就可以完整地测试它。您可能希望在调用函数之前设置断点，并检查调试器以确保它完美运行。
我想我会说：“经常测试。”
答案 7 :(得分：0)
我最近才将单元测试添加到我的常规工作流程中，但是我编写了单元测试：
我在大多数版本上运行测试，并且始终在运行代码之前。
答案 8 :(得分：0)
从单元测试开始。具体来说，请查看TDD，测试驱动开发。 TDD背后的概念是先编写单元测试，然后编写代码。如果测试失败，您将返回并重新编写代码。如果它通过，你继续下一个。
我对TDD采用混合方法。我不喜欢编写任何测试，所以我通常首先编写一些代码，然后将单元测试放入。这是一个迭代过程，一个你从未真正完成的过程。您更改代码，运行测试。如果有任何失败，请修复并重复。
另一种测试是集成测试，它在过程的后期出现，通常可能由QA测试团队完成。在任何情况下，集成测试都需要测试整个部件的需求。这是您关注测试的工作产品。这个更难以处理b / c它通常涉及自动化测试工具（如机器人，例如）。
另外，看一下像CruiseControl.NET这样的产品来做连续构建。 CC.NET是不错的b / c它会在每次构建时运行你的单元测试，立即通知你任何失败。
答案 9 :(得分：0)
我们不在这里做TDD（虽然有些人提倡它），但我们的规则是你应该检查你的单元测试你的更改。它并不总是会发生，但很容易回过头来查看特定的变更集，看看是否写了测试。
答案 10 :(得分：0)
我发现如果我等到编写一些新功能进行测试结束时，我会忘记许多我认为可能会破坏该功能的边缘情况。如果你正在为自己学习，这是好的，但在专业的环境中，我发现我的流程是经典的形式：红色，绿色，重构。
红色：编写测试以使其失败。这样你知道测试是针对正确的变量断言的。
绿色：以最简单的方式让您的新测试通过。如果这意味着硬编码，那没关系。这对于那些只想立即工作的人来说非常棒。
重构：现在您的测试通过，您可以放心地更改代码。你的新改变打破了你的考验？太棒了，你的改变有一个你没有意识到的含义，现在你的测试告诉你了。
这种节奏让我加速了我的发展，因为我基本上有一个历史编译器，用于我认为需要检查的所有事情才能使功能正常工作！反过来，这会带来许多其他好处，我不会在这里得到......
答案 11 :(得分：0)
这里有很多很棒的答案！
我尝试在有意义的最低级别进行测试：
如果单个计算或条件很难或很复杂，请在编写时添加测试代码并确保每个部分都有效。完成后注释掉测试代码，但留在那里记录您如何测试算法。
测试每个功能。
使用与上述相同的策略测试每个模块。
整体测试代码体，以确保组件正确交互。如果您一直在努力进行低级别测试，那么这实际上是一项“信心测试”，以确保在组装过程中没有任何损坏。
由于我的大部分代码都是针对嵌入式设备的，因此我特别注意稳健性，各种线程，任务和组件之间的交互以及资源的意外使用：内存，CPU，文件系统空间，等
一般来说，越早遇到错误，就越容易隔离，识别和修复它 - 而且花费的时间越多，而不是追逐你的尾巴。*
**我知道，-1是免费的缓冲区指针引用！*