Question

如何测试一个没有返回值的方法

Answer 1

但是我们知道，一个方法应该要么有返回值要么又可以观察到的副作用，否则这个方法就可以被视作什么事情都没有做。所以，如果一个方法没有返回值，那么我们就应该根据它的可观察的副作用来进行测试。 举一个例子，测试向堆栈中压入元素的方法push()。假设Stack类的push()方法不会返回任何值。我们可以采取以下步骤来测试push()方法： 1、建立一个空的堆栈； 2、判断该堆栈的栈顶是否是要压入的元素； 3、将一个元素压入堆栈； 4、判断堆栈顶部的元素是否是刚才压入的元素。用Java语言翻译过来就是： public class PushToStackTest extends TestCase { public void testStackPush { Stack stack = new Stack(); assertFalse(stack.pop().equals("item")); stack.push("item"); assertEquals("item", stack.pop()); } }大家会注意到，这个测试方法中用到了Stack类的另外一个方法pop()，我们测试过pop()吗？如果要对pop()进行测试的话，显而易见我们必定要使用到 push()。我们既然没有通过对 push()的测试，怎么能够保证可以正确的测试pop()呢？既然我们不能测试pop()的正确性，怎么能够断定testStackPush()是正确的呢？唔，这是一个“鸡生蛋蛋生鸡”的问题。从这个循环怪圈里面跳出来，记住，我们真正要测试的是对象的行为，而不是对象的方法！在testStackPush()中我们要测试的是向堆栈压入元素的行为，而不是Stack类的push()方法。在测试中，我们可能要用到Stack的 push()、pop()、clear()、peek()，使用这些方法都是为了测试是否能够正确地压入一个元素。所有的这些方法组合在一起，来实现一种功能、一种行为。 可能存在这么一种情况，单个方法的实现代码是错误的，但是它们组合起来却实现了正确的行为。这种情况，我们是否认为这是一种软件缺陷呢？答案可能会令人吃惊：不。因为对于JUnit用户来说，应当认为测试就是标准、就是规格说明书。正因为如此，JUnit程序员需要书写足够全面的测试代码来测试对象的行为，保证不会因为偶然的情况使得有缺陷的代码逃过单元测试。 另外说一个话题，大家可以在上面所示的Java代码中看到JUnit中只有判断期望值和实际值相等的断言方法，却没有相反的方法：assertNotEquals()。当然，在某些JUnit的扩展项目中我们可以找到这个方法，例如在JUnit-addons 中，但是这还没有成为JUnit的一部分。现在也有很多JUnit社区在呼吁将assertNotEquals()添加到JUnit中去。