如何避免生成BUG

在编程时，通常编写一开始不构建的代码。这些通常被认为是需要立即修复的错误或错误。渐渐地，大多数开发人员学会了预测构建错误并避免它们。

在遵循 TDD 时，我想鼓励您停止避免生成错误，因为避免生成错误的方法通常意味着在尝试使用新功能或更新的代码之前，您需要先启用新功能或更改代码。这意味着您在关注细节的同时进行更改，并且很容易忽略更大的问题，例如使用新功能或更新代码的难易程度。

相反，首先以您认为应该使用的方式编写代码。这就是测试所做的。

#include "../Test.h" 

TEST


{

}

TEST

 {

	throw 1; 
	
	}

由于错误，该项目已经建成，但没有完成。这让我们知道需要修复什么。但是在进行更改之前，我展示了我们真正希望测试的样子

#include"../Test.h"

TEST("Test can be created") {

}

TEST("Test with throw can be created") 

{

throw 1; 

}

只有在我们清楚地了解测试应该是什么样子时，才进行了更改以启用多个测试。如果我没有采用这种方法，可能会找到其他解决方案来命名测试。它甚至可能奏效。但它会那么容易使用吗？我们是否能够像代码显示的那样简单地声明第二个 TEST 并立即为每个测试命名？我不知道。

但我确实知道，有很多次我没有遵循这个建议，最终得到了一个我不喜欢的解决方案。我不得不回去重做工作，直到我对结果感到满意。如果我一开始就从我想要的结果开始，那么我会确保编写直接导致该结果的代码。

所有这一切实际上只是焦点的转移。与其深入研究您正在编码的内容的详细设计，不如退后一步，首先编写测试代码以使用您打算制作的内容。

换句话说，让测试驱动设计。这就是TDD的本质。

你写的代码还不会构建，因为它依赖于其他不存在的代码，但这没关系，因为它给了你一个你会满意的方向。

在某种程度上，从这个用户的角度编写代码会给你一个目标，甚至在你开始之前就使这个目标成为现实。不要满足于对你想要什么的模糊想法。花点时间编写您希望首先使用的代码，生成项目，然后修复生成错误。

当您知道项目将无法构建时，真的有必要尝试构建项目吗？这是我有时会采用的快捷方式，尤其是当构建需要很长时间或构建失败明显时。我的意思是，如果我调用一个尚不存在的方法，我通常会在不构建的情况下编写下一个方法。我知道它将无法构建以及需要做些什么来修复它。

但有时此快捷方式可能会导致问题，例如在使用重载方法或模板方法时。您可能会编写代码以使用尚不存在的新重载，并认为代码将无法生成，而实际发生的是编译器将选择一个现有的重载版本进行调用。模板也是如此。

结果不是想要的，首先建造可以让问题立即被发现。

关键是构建项目会让你知道这些情况。如果您预计构建会失败，但它仍然可以编译，那么您就知道编译器能够找到一种可能您意想不到的使代码工作的方法。这可以带来宝贵的见解。因为当您添加预期的新重载时，现有代码也可能开始调用您的新方法。最好了解这种情况，而不是对难以找到的错误感到惊讶。

当您仍在努力构建测试时，您无需担心通过。事实上，如果你一开始让测试失败，那就更容易了。专注于预期的用途，而不是通过测试。代码构建完成后，您应该实现多少?

---

开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 N 天，点击查看活动详情”