在编写实际代码之前在测试驱动开发中编写junit？答案

【问题标题】：Writing junits in Test Driven Development before writing actual code?在编写实际代码之前在测试驱动开发中编写junit？
【发布时间】：2013-06-06 11:38:37
【问题描述】：

人们总是在 TDD 中说

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

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

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

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

public List<CustomerData> getCustomers(int custId){

return null;
}

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

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

【问题讨论】：

标签： java junit tdd

【解决方案1】：

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

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

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

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

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

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

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

Recommended read.

【讨论】：

我对此的修改后的理解是，假设我希望我的数据库中有 10 条记录，那么我希望测试用例检查 10 大小（现在一旦我实施我的实际方法，它应该自动修复测试用例）。对吗？
是的。当然，一种危险是测试 2、3 等。您应该测试行为。此外，模拟在这里会有很大的帮助。例如，您可以创建一个返回 10 个对象的数据类的模拟，并用它来测试您的类的行为。根据个人经验，我发现我使用 TDD 的次数越多（现在几乎一直如此），我就越容易设计东西，这是一个相当大的好处……
如果这可以帮助，此刻，我写了一个简单的类来测试，提交here。之后，我将测试空值，然后实际添加该值。现在，唯一的测试失败了。

【解决方案2】：

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

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

查看this recent Dr Dobbs editoral，它准确地讨论了这一点以及实用主义在这方面的作用，尤其是这种实践的专家（Kent Beck 等）

TDD 的一个关键原则是不先编写代码就不要编写代码失败的单元测试。但事实上，如果你和校长谈谈 TDD 的倡导者（例如普及该技术的 Kent Beck，和 Bob Martin，他已经将它教给了成千上万的开发人员），你发现他们俩都写了一些代码，没有先写测试。他们不——我应该强调这一点——将这些时刻视为失误信仰，而是作为聪明人的必要实用主义开发者。

【讨论】：

正如您所说的“如果您与 TDD 的主要倡导者（例如推广该技术的 Kent Beck 和曾向成千上万的开发人员教授该技术的 Bob Martin）交谈，您会发现两者他们中的一些人在没有先编写测试的情况下编写了一些代码。”您能否指导他们编写一些代码而不先编写测试的示例。基本上我想知道在哪里画线

【解决方案3】：

部分正确。

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

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

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

【讨论】：

【解决方案4】：

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

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

【讨论】：