功能测试应该只断言响应吗？

Question

我有一些关于测试的困惑问题。

我们使用Slim 作为系统的框架。据我所知，Unit Test 是最低限度的测试。例如，测试类或方法是否按预期工作。

为了测试系统的其他功能，比如系统提供了一个API来搜索产品信息，这个搜索功能的设计思路如下：

1. 客户端将关键字发布到 API 条目。例如。 /search
2. 处理请求并将SearchService注入控制器。
3. 将关键字设置为SearhService。
4. 将关键字推入数据库。例如。 search_history。
5. 将搜索结果取回控制器，并响应客户端。

这就是search API 的设计方式。

我们为Search API 创建了一个功能测试，称为SearchTest。我们就是这样做的：

1. 使用Slim提供的$this->runApp()方法向API入口发送请求。
2. 设置多个测试用例来测试不同类型的场景，例如“未提供关键字”、“无搜索结果” ...等
3. 按预期断言返回值或 HTTP 状态的响应。

有些问题令人困惑：

• 发送请求并声明响应，仅此而已吗？我们是否误解了所谓的“功能测试”？
• 我们不应该关心它是如何工作的，我们只需要发送请求并断言响应，对吗？
• 如果不是，我们应该检查依赖关系还是使用的组件按预期工作？例如，我们是否应该连接到数据库，并检查关键字推送是否成功？

Answer 1

自动化测试（以及一般测试）在软件工程中被认为是一种很好的做法。然而，关于测试方法和类型分类的边界是什么，存在很多热议。

从这个意义上说，正确实施测试方法的一种实用方法是向那些您认为在您的软件开发环境中受人尊敬的人学习，并确保您采用的做法对你愿意达到的目标。 尽量保持一致。

仅供参考，lets take this definition.

功能测试是指验证代码的特定操作或功能的活动。这些通常可以在代码需求文档中找到，尽管一些开发方法来自用例或用户故事。功能测试倾向于回答“用户可以做到这一点”或“这个特定功能是否有效”的问题。

考虑到这种方法，您希望您的测试让您确信用户能够执行您的应用程序提供的某些功能（或特性）。 （在这里）如何提供该功能并不重要，只要站在用户的角度思考“我是否从这个操作中得到了我所期望的？”,该问题的答案应该提示您测试的断言。

非功能测试是指可能与特定功能或用户操作无关的软件方面，例如可扩展性或其他性能、特定约束下的行为或安全性。测试将确定断点，即极端的可扩展性或性能导致执行不稳定的点。非功能性需求往往是那些反映产品质量的需求，尤其是在用户的适用性方面。

如果您想测试如何执行某个函数，可能是单元测试可以帮助您执行这些断言。

但同样，请记住，并不是从名称中严格限制您的测试应该执行的内容，而是要知道哪种分类最适合您正在执行的断言类型（这有助于您更好地构建测试并让您清楚地了解您在测试什么）。 尽量保持一致并专注于测试您真正需要自信的事情。