人们总是在TDD中说过
我们应该在编写实际代码之前编写junits。
不知何故，我无法以正确的精神理解这一点。我希望这意味着你只需要用正确的签名编写空方法，并且你的测试用例最初会失败
在TDD方法中说我需要获取客户列表。
根据我的理解，我将编写如下的空方法
public List<CustomerData> getCustomers(int custId){
return null;
}
现在我将编写junit测试用例，我将检查大小为10（我实际上是在期待）。这是对的吗？
基本上我的问题是在TDD中，我们如何在编写实际代码之前编写junit测试用例？
答案 0 :(得分：7)
通常，您会将测试与代码框架一起编写。最初，您可以编写一个非功能性实现（例如抛出UnsupportedOperationException），这将触发测试失败。然后，您将充实实施，直到最终测试通过。
你需要务实这一点。显然，你不能编译你的测试，直到至少你的被测单元编译，所以你必须在你的测试中做少量的实现工作。
查看this recent Dr Dobbs editoral，其中正好讨论了这一点以及实用主义在这方面的作用，尤其是这种做法的专家（Kent Beck et al ）
TDD的一个关键原则是没有第一次写作就不会编写代码 失败的单元测试。但实际上，如果你跟校长谈话 TDD的倡导者（如Kent Beck，推广该技术， 和鲍勃马丁，他已经教过成千上万的开发人员），你 发现他们都写了一些代码而没有先编写测试。 他们没有 - 我应该强调这一点 - 将这些时刻视为失误 信仰，而不是智慧的必要实用主义 显影剂。
答案 1 :(得分：6)
我希望你只需要用正确的签名写空方法
是。对于大多数现代IDE，如果编写测试中不存在的方法名称，他们将为您创建存根。
在TDD方法中说我需要获取客户列表。什么是正确的进行方式？
你的榜样并不完全存在。你想测试一个0长度的数组，但是你已经返回了它：你应该首先返回null，测试显然会失败。
然后修改方法以使测试成功。
然后为客户添加创建测试方法。测试失败。修理它。冲洗。重复。
所以，基本上：使用TDD，你启动并编写你知道将失败的测试，然后修复你的代码以便它们工作。
答案 2 :(得分：4)
这是部分正确的。
使用IDE（Eclipse，IntelliJ）可以创建测试。在该测试中，调用一个方法（不存在）并使用重构工具创建一个具有适当签名的方法。
这是一个让TDD更轻松，更有趣的技巧。
根据Now i will write junit test case where i will check the size as 0. Is this Right?，你应该编写一个fails的测试，并提供适当的实现。
答案 3 :(得分：0)
我觉得先写测试，写测试的时候想想函数的签名。
这和写签名然后写测试是一样的，但是在写测试的时候发明函数的签名会很有帮助，因为你将拥有关于函数职责的所有信息，你将能够来加上正确的签名。