什么时候/没有/在执行前写测试？

Question

我不确定“先测试”是如何运作的，我想听听关于何时以及为何采用这种方法的争论。

我听说在编写单行实现之前，经常建议编写测试和模拟内容。但是，我不禁想到它并不适合所有情况。 例如，假设我正在制作原型，我不确定一切是如何运作的。所以我开始找到我认为需要的每个步骤的示例并将它们放入我的代码中。最后，我有一个我的理论的证据，并没有花那么长时间。这基本上是“我的考验”。它不是单元测试，但它是一个测试（很可能是一个控制台应用程序）。

这几乎就是我的工作方式。我想想我想做什么并尝试去做。如果它工作，那么我最终回去编写单元测试，以便我可以陷阱回归。这与你“应该做的”不同吗？

Answer 1

总体规则是：先做最危险的项目。

首先做一下测试用例，主要是认为编码中最危险的部分是对正在创建的对象的接口和行为的误解和误解。

对于许多项目而言，这可能是正确的，并且在这些情况下TDD非常合适。

然而，在许多项目中并非如此，在这些情况下应用TDD是一个糟糕的选择。

如果您的风险最大的是可用性，请停止使用单元测试并进行一些UI原型设计。

如果您的最高风险是性能，请先做一些性能原型，不要担心接口。

此列表继续。

首先执行有风险的项目有很多好处：

• 在许多资源被浪费之前，不可避免地注定的项目会早日死亡。

• 遇到麻烦但可以挽救的项目可以及早解决项目管理问题，这样可以带来一些好处。

• 组织的业务部门在失败风险较低时会重视项目;不必要地提前取消它的可能性较小。

Answer 2

“我听说经常建议在编写单行实现之前编写测试和模拟事物....我最终会回去编写单元测试......这与你应该做的不同吗？ “？”

既然你开始回答自己的问题，那么你真的不是在问这个问题吗？

  

人们有很多理由   回答自己的问题。   有时候，这是一种争论的方式   它允许人们说“我不是在争论，我是   只是问为什么这是错误的“。

---

目标首先是测试。这是它的工作原理。

说我正在制作原型，但我不确定一切是如何运作的。

但是，我确实知道一件事。该怎么做。

1. 写下它应该做的具体例子。具体，具体的投入和产出。

2. 这是测试案例。我先做了我可以将其正式化为单元测试吗？可能不是。但是，我从验收测试案例开始。

现在，我可以将问题分解成碎片。

1. 所以我开始找到我认为需要的每个步骤的例子。

2. 对于我认为需要的每个例子，我都会写下从步骤中得到的内容和结果。

3. 这些是测试用例。我先做了他们。在许多情况下，我可以将它们形式化为单元测试。

4. 进行测试后，我会回到每个步骤的示例并将其放入我的代码中。

我做了测试，然后编码。我没有在任何编码之前进行所有测试。我首先进行了测试，但没有采用疯狂的全无测试方式。我是通过增量测试 - 一点点代码 - 一点点的方式完成的。但是一切都是先测试的。

Answer 3

这很简单，答案是在原型制作过程中。在这个阶段，你不能理解你的建筑系统是否足以正确测试，而且无论如何好的做法都说原型代码应该是丢失的代码，因此测试在这个阶段不会给你任何实际的好处。但是，从原型制作中汲取的理解将帮助您，使您在进入生产后能够进行有效的测试。

所以，如果您在原型之后进行测试，那么您的方法是正确的

Answer 4

我认为你不测试尖峰/原型的方法就好了。但有两个想法：

1. 一旦你完成了原型并且你知道自己要做什么，要么把它扔掉，先把它重新实现测试，要么为你已编写的代码编写测试。

2. 当您进行更多单元测试练习时，您可能会发现在测试中创建原型比创建控制台应用程序更快。我并不是指创建一个测试和一个单独的类与想法，我的意思是在测试方法中探索w /代码。我已经做过很多次了，我对此非常满意。当我学习新的api甚至是新语言时，测试为我提供了尝试实验的最快反馈周期。然后，一旦代码工作，我就可以将它提取到一个单独的方法/类中，成为真实系统的一部分。

Answer 5

即使你正在编写一个扔掉的原型，从原型实际做的事情来考虑它仍然是有用的，并从确认它的测试开始。确保原型可以测试也将决定解决方案的接近方式。

然后当代码被丢弃时，你仍然有测试。

我也很难从原型测试开始，但是当我设法做到这一点时，我一直很高兴我做到了。

Answer 6

我发现当我仍在构建代码的“故事”时，首先编写测试并不能很好地工作。当我不确定界面是什么样的时候，很难编写测试。我可能会编写存根代码来充实类和接口而不考虑测试。但我尽量尽快进行测试。我发现如果我在构建设计时记下我要测试的东西会有所帮助，然后当我的设计更加凝固时，我会回到我的笔记中，然后我将这些测试做成第一。这通常意味着实现和单元测试代码一起成长，而不是一个在另一个之前。

Answer 7

没有一种“正确的方法”。但是，我确实认为测试驱动开发（TDD）会对您的情况有所帮助。我发现首先编写测试有助于塑造API并使代码更清晰。当你首先编写测试时，首先考虑如何调用代码（接口或“应该做什么”），然后再考虑实现（'我该怎么做'）。

例如，想象一下创建CRM模块。您可能认为要做的第一件事就是让花费最多的客户。所以，你会写一个测试：

Assert.AreEqual（Customer1，crm.GetMostValuableCustomer（），“最有价值的客户不如预期”）;

然后您可以使用以下内容：

Assert.AreEqual（new Customer [] {Customer1，Customer2，Customer3}，crm.GetCustomerByValue（），“GetCustomersByValue（）与预期不符”）;

所以，重点是你从不同的角度考虑代码（作为消费者，而不是生产者）。我相信可以帮助我编写更清晰的代码，然后我就不必再回过头来创建回归测试了。我希望我有一个更好的例子，但希望你能看到这种方法的工作方式可能真正帮助你进行原型设计阶段。