如何在不知道其实现的情况下对堆栈ADT进行单元测试

时间:2015-01-13 01:17:56

标签: unit-testing data-structures

假设堆栈具有以下功能:poppushpeektoArray

如果我想为推送操作编写单元测试,如何在不知道底层实现的情况下完成?一种可能性是将某些内容推送到空堆栈并针对预期结果测试stack.toArray(),但这涉及一个未经测试的函数。

2 个答案:

答案 0 :(得分:1)

你无法真正单独测试这些功能。如果您要测试push(),则必须pop()以测试元素是否以正确的顺序弹出。

除非你想为它编写测试,否则你不需要使用toArray()

答案 1 :(得分:1)

你提出了一个有趣的问题。实际上,您必须根据使用模式测试ADT,而不是单独的方法。

考虑堆栈的要求:

  • 当我将项目X推送到堆栈时,我希望没有回复。

嗯,这肯定是可以测试的,但它内置于返回类型,即voidunit

没有什么可以直接观察到推动动作。相反,它是定义行为的特定行动组合。

  • 当我将一个项目X推送到一个空堆栈时,我希望X位于堆栈的顶部,下面没有任何内容。

嗯。这测试push,但正如您所指出的,如果没有其他堆栈函数,您无法真正解析后半部分。

在这样的情况下,推动时会发生什么事情?没有!您关心的是某些操作序列会产生可验证且一致的结果。

一般情况下,单元测试也是如此:何时可以单独测试每个功能。但是当这样做没有意义时,请改用行为模式。

部分原因是你无法假设推动筹码立竿见影的结果是你永远不会得到这种保证。例如,假设您的堆栈实现使用了一个花哨的缓冲区:每次推送时,它都会将元素添加到缓冲区,但不会将它放在正式堆栈上。然后,当您调用peekpop时,它会立即处理所有缓冲的项目,然后执行操作。对你而言,内部是不可见的:你关心的是总行为与堆栈的行为一致。

这就是,实质上是什么使它成为ADT。我们关心的是行为模式,而不是详细的实施。