8

人们在 TDD 中总是说

我们应该在编写实际代码之前编写junit。

不知何故，我无法以正确的精神理解这一点。我希望这意味着您只需编写带有正确签名的空方法，并且您的测试用例最初预计会失败

在 TDD 方法中说我需要获取客户列表。

根据我的理解，我将编写如下所示的空方法

public List<CustomerData> getCustomers(int custId){

return null;
}

现在我将编写 junit 测试用例，在其中我将检查大小为 10（我实际上期望的）。这是正确的吗？

基本上我的问题是在 TDD 中，我们如何在编写实际代码之前编写 junit 测试用例？

4

4 回答 4

7

通常，您会在代码框架旁边编写测试。最初，您可以编写一个非功能性实现（例如 throw an UnsupportedOperationException），这将触发测试失败。然后你会充实实现，直到你的测试最终通过。

你需要对此保持务实。显然，至少在您的被测单元编译之前，您无法编译您的测试，因此您必须在测试的同时进行最少量的实现工作。

看看最近的 Dobbs 博士的社论，它准确地讨论了这一点以及实用主义在这方面的作用，尤其是这种实践的专家（Kent Beck等人）

TDD 的一个关键原则是，如果没有先编写失败的单元测试，就不要编写代码。但实际上，如果您与 TDD 的主要倡导者（例如推广该技术的 Kent Beck 和曾向数千名开发人员教授该技术的 Bob Martin）交谈，您会发现他们都编写了一些代码而不编写测试第一的。他们不——我应该强调这一点——将这些时刻视为信仰的失误，而是作为聪明的开发人员必要的实用主义。

于 2013-06-06T11:43:19.223 回答
7

我希望这意味着您只需编写带有正确签名的空方法

是的。对于大多数现代 IDE，如果您编写的方法名称在您的测试中不存在，它们会为您创建一个存根。

在 TDD 方法中说我需要获取客户列表。什么是正确的方法？

你的例子并不完全在那里。你想测试一个长度为 0 的数组，但你已经返回了它：你应该先 return null，测试显然会失败。

然后修改方法，使测试成功。

然后为客户添加创建一个测试方法。测试失败。修理它。冲洗。重复。

因此，基本上：使用 TDD，您开始并编写您知道会失败的测试，然后修复您的代码以使其正常工作。

推荐阅读。

于 2013-06-06T11:45:12.583 回答
4

这是部分正确的。

使用 IDE（Eclipse、IntelliJ），您可以创建测试。在该测试中调用一个方法（不存在）并使用重构工具创建一个具有适当签名的方法。

这是一个让使用 TDD 更轻松、更有趣的技巧。

根据您的说法，Now i will write junit test case where i will check the size as 0. Is this Right?您应该编写一个测试fails，并提供正确的实现。

于 2013-06-06T11:42:11.153 回答
0

我想先去写测试，写测试的时候想想函数的签名。

这与编写签名然后编写测试相同，但是在编写测​​试时发明函数的签名会很有帮助，因为您将获得有关函数责任的所有信息，并且您将能够提出正确的签名。

于 2020-12-23T18:39:25.983 回答