Question

我是测试的业余爱好者，正在尝试学习如何编写更好的测试。现在，我有以下伪代码情况：

function doSomething() {
    context = prepare();
    result = doActualWork(context);
    notify(result);
}

您可以想象prepare()，doActgualWork()和notify()是一些复杂的函数，内部有许多较小的函数，但是它们被包含单元测试以及集成和集成的测试所覆盖。有些涉及HTTP / IO模拟。

现在，当涉及到此doSomething()函数时，我对应该如何确切地对其进行测试感到困惑。我认为值得测试的一件事是接口匹配：context返回的prepare()可以输入doActualWork()，但是它正在测试实际的实现。

另一种方法也可以在给定输入后给出正确输出的情况下进行测试，因为底层功能非常复杂，所以我需要模拟所有HTTP / IO，这听起来有点怪异，因为我通常都会进行大型测试准备工作很多的案例，而函数调用和断言只是最后几行。

以这种方式这样做是不合适的。

感谢您的帮助和指导。谢谢。

Answer 1

您已经在以正确的方式看待这个测试问题。

这段代码不适合单元测试：通过单元测试，您尝试在小的独立软件块中查找错误。但是，在此示例代码中哪些错误可能与其他组件无关？这里的错误与“我以正确的参数顺序为参数调用适当的值，以正确的状态调用其他函数，是否处于正确的状态（例如，已初始化）以及返回值和预期的副作用等问题有关”他们是吗？”所有这些问题都与集成测试有关。

此外，集成测试还有另一个方面，即不着重于交互，而是着眼于整个组件-有时称为组件测试，子系统测试等。这是关于查找以下错误：“是正确的版本集成的组件是从组件就位所需的所有功能”等。

这两种类型的测试对于本示例代码都是有意义的，并且两者都将在正确版本中实际存在依赖组件的情况下执行。是否仍对间接依赖项使用一些模拟（例如，对依赖组件内部发生的http请求的模拟）是另外一回事。

相比之下，为prepare()，doActualWork()和notify()的调用创建双打/嘲笑只是为了能够为doSomething()创建单元测试以任何方式帮助您。由于您实现了这些模拟，因此它们只会反映出您对这些功能的潜在误解。

如何测试使用一些经过良好测试但复杂的功能的功能？

1 个答案: