在过去，编程很少涉及猜测。我会写几行代码，一眼就能 100% 确定代码做什么和不做什么。错误主要是拼写错误，但与功能无关。
我相信在过去的几年中存在这种“试错”编程的趋势:编写代码(就像在草稿中一样)，然后反复调试，直到程序的行为看起来符合要求。测试，再测试，然后再测试。 有趣的是，在我的 Visual Studio 中，“运行”按钮已被标记为“调试”的按钮所取代(= 我知道你有一些错误!)。我必须承认，在我编写的几个应用程序中，我不能保证代码没有错误。
你怎么看？或者也许我们的系统现在过于复杂(浏览器/操作系统/服务包兼容性等)，这证明在所有类型的环境中进行测试是合理的。
最佳答案
实际上，我经历过相反的情况。虽然它曾经是一个运行直到它起作用的情况，但我现在进行单元测试直到测试通过……据我所知，这似乎至少是一个合理的常见转换。
我不得不说，在我的经验中，第一次只有拼写错误的代码从来没有是常态。不同之处在于，现在我可以更快地找到问题，并且还能发现旧问题是否再次出现。我有时可以管理非常短和简单的代码而没有错误(并且在 Stack Overflow 上发帖提高了这种能力)但是大型、复杂的系统呢？见鬼不。
回答您帖子的标题 - 在我看来，“测试、测试、测试”原则是一个很好的原则……但我不会将其与重复运行整个程序联系起来。我将它与经常运行的单元测试联系起来。我很少需要使用调试器进行单元测试 - 通常失败会使原因通过检查变得很明显，因为只测试了少量代码。
关于debugging - 你如何看待无所不在的 "Test, Test, Test!"原则？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1963009/