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

Question

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

由于

Answer 1

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

单元测试提供以下内容：

1. 一种可重复的方法，用于确定您的代码是否正常工作，包括常见方案和边缘情况。它们将允许您对代码进行重构，并确信它仍然有效。
2. 可证明的代码规范。如果没有书面规范，您的单元测试 是您的代码规范。在敏捷世界中尤其如此。
3. 帮助构建结构良好的代码。因为你想独立运行单元测试，你必须编写你的测试类来接受不同的（有时是模拟的）数据源，接收器等。通过鼓励这些抽象和关注点分离，你的代码将变得结构良好（你可以，当然，编写结构良好的代码而不进行单元测试）

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

Answer 2

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

Answer 3

如果您能够在单元测试中重现该错误，请使用单元测试。它将在错误解决后继续使用，并在将来“保护”代码。

如果您很难找到违规代码，那么调试可能是更好的解决方案。但是，一旦你知道问题出在哪里 - 写一个测试，确保它失败然后修复bug。

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

Answer 4

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

Answer 5

另一个观点：

始终对您可以做的所有事情进行单元测试。理想的做法是单独测试每个组件，然后对组件协作进行集成测试。

你所谈论的是一个不同的问题：如果出现问题，你应该怎么做，去尝试编写单元测试或运行调试器。这些并不是真正的选择。如果出现问题，你可以在单元测试中看到这种行为，这是理想的。但你仍然必须找到行为的原因。现在你的选择是在添加日志记录和运行调试器之间，我和那些说使用日志记录的人投票直到你不能。调试器时间不会为代码添加长期值。记录确实。

Answer 6

我认为这个问题可以比一些答案更深入地看待......虽然可能更适合编程堆栈交换。

首先评论调试和单元测试如何交互

• 首先进行单元测试可以防止调试

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

• 与上述类似，您可以通过系统跟踪有问题的代码，并开始使用相同的输入对调用链下方的内容进行单元测试

单元测试可以被视为＆＃34;提前调试＆＃34;或者＆＃34;悲观的调试＆＃34;，假设你有一个bug，所以试着马上调试它。如果你在考虑到实际问题的时候这样做，那更像是猜测某段代码中存在一个错误，你可以通过猜测输入错误来引出它。