何时使用调试与单元测试？

Question

我有点困惑有什么更好的使用调试或写单元测试？这是一般还是有些情况下调试比单元测试更好？还是应该使用它们？

感谢

Answer 1

调试将帮助您诊断非工作代码。

单元测试提供以下信息：

1. 确定你的代码的工作，无论是常见的场景和边缘情况的重复的手段。他们可以让你自信地重构你的代码，它仍然有效。
2. 该代码的可证明的规范。在没有书面规范的情况下，您的单元测试是您的代码规范。敏捷世界尤其如此。
3. 有助于构建结构良好的代码。因为你想单独运行单元测试，所以你必须编写你的测试类来接受不同的（有时是模拟的）数据源，汇等。通过鼓励这些抽象和关注的分离，你的代码将变得结构良好（你可以当然，在没有单元测试的情况下编写结构良好的代码）

您的单元测试应该反复运行（通常作为构建过程的一部分）。如果你确实破坏了它们（通常是由于编程错误），然后是时候打开调试器来确定问题并相应地修正代码（或者修改测试）。

Answer 2

如果你能重现bug的单元测试，使用单元测试。它会在错误得到解决后继续使用，并在未来“保护”代码。

如果您很难找到有问题的代码，那么调试可能是更好的解决方案。但是，当你知道问题出在哪里时 - 写一个测试，确保它失败并修复错误。

调试需要更多时间，这是“一次性”解决方案。当你有选择单元测试时，更喜欢单元测试。

Answer 3

单元测试用于确保代码按预期工作。当您需要查找代码无法按预期工作时，会使用调试。

Answer 4

调试和写入单元测试是两回事。理论上讲，你的开发应该由覆盖不同场景的单元测试来驱动。当你意识到代码有问题并尝试在运行时看到不同变量的值时，你可以调试，因此基本上只有在出现问题时才能进行调试。

Answer 5

另一种观点：

总是千方百计，你可以做的单元测试。理想的做法是单独测试每个组件，然后进行组件协作的集成测试。

然而，你在谈论的是一个不同的问题：如果有什么事情发生，你应该怎么做，去尝试编写一个单元测试或运行调试器。这些并不是真正的选择。如果出现问题并且您可以在单元测试中看到该行为，那就很理想。但是你仍然需要找到行为的原因。现在你的选择是在添加日志记录和运行调试器之间进行的，并且我跟那些说使用日志记录的人投票，直到你不能。调试器时间不会为代码添加长期价值。日志记录会。

Answer 6

我认为这个问题可以用比某些答案暗示的更深的方式来看待...虽然可能更适合编程堆栈交换。

一是如何调试和单元测试互动

• 单元测试第一可以防止调试

• 当事情是足够硬的调试方法之一是停止调试您的问题，并开始单元的一些意见使用相似类型的有问题的输入来测试相关的事物。您可能想尝试简化首先导致问题的输入（假设您的系统是确定性的！）

• 与上述类似，您可以通过系统跟踪有问题的代码，并开始单元测试，用相同的输入

单元测试可以被认为是“提前调试”或“悲观调试”，假设你将会有个bug，因此试着调试它立竿见影。如果您在考虑实际问题时这样做，那更像是猜测代码的特定部分中存在错误，并且您可以通过猜测输入中断来引发错误。