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

Question

人们总是在TDD中说过

我们应该在编写实际代码之前编写junits.

不知何故,我无法以正确的精神理解这一点.我希望这意味着你只需要用正确的签名编写空方法,并且你的测试用例最初会失败

用TDD方法说我需要获得客户列表.

根据我的理解,我将编写如下的空方法

public List<CustomerData> getCustomers(int custId){

return null;
}

现在我将编写junit测试用例,我将检查大小为10(我实际上是在期待).这是正确的吗？

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

Answer 1

通常你会将代码与代码的骨架一起编写.最初,您可以编写一个非功能性实现(例如,抛出一个UnsupportedOperationException),这将触发测试失败.然后你会充实实现,直到最后你的测试通过.

你需要务实这一点.显然,在至少测试的单元编译之前,你无法编译测试,因此你必须在测试的同时进行最少量的实现工作.

看看这个最近的Dr Dobbs编辑,它正好讨论了这一点以及实用主义在这方面的作用,尤其是这种实践的专家(Kent Beck 等)

TDD的一个关键原则是,如果没有首先编写失败的单元测试,就不会编写代码.但事实上,如果你与TDD的主要倡导者(例如推广该技术的Kent Beck,以及向成千上万的开发人员教过它的Bob Martin)谈话,你会发现他们都写了一些代码而没有编写测试第一.他们没有 - 我应该强调这一点 - 将这些时刻视为信仰的失误,而是智慧开发者的必要实用主义.

Answer 2

我希望这意味着你只需用正确的签名写出空方法

是.对于大多数现代IDE,如果编写测试中不存在的方法名称,他们将为您创建存根.

用TDD方法说我需要获得客户列表.什么是正确的进行方式？

你的榜样并不完全存在.你想测试一个0长度的数组,但你已经返回了它:你应该先返回null,测试显然会失败.

然后修改方法以使测试成功.

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

所以,基本上:使用TDD,你开始并编写你知道将失败的测试,然后修复你的代码以便它们工作.

推荐阅读.