编写单元测试REST-ful API

Question

我正在计划为REST-ful API编写单元测试,我想知道我应该采用的方法.

我最关心的方面与数据库状态有关.我的理解是每个测试的测试目标的环境或初始状态应该是相同的,这意味着每个测试的数据库也应该是相同的.当我有一个繁重的数据库时,我如何实现这一目标？另外,如何处理数据库模式中的最终更改？

Answer 1

问题是你想要测试什么.您认为最顶层的api层(即接收HTTP请求的层)会破坏什么？

通常编写单元测试restful-api听起来有点像矛盾;)根据定义,单元测试比使用入口点HTTP到数据库要小得多.听起来更多的是你的问题是基于如何编写大型测试(或接受,端到端测试).

请注意,实施此类大型测试(端到端测试)需要付出高昂的努力:

• 测试往往要慢得多
• 测试的维护成本,因为测试更难以理解(因为所有这些依赖+测试数据设置)
• 他们更容易引起假阳性测试(测试显示'红色'虽然它应该是'绿色').原因是你的测试中涉及更多的依赖关系,更有可能是脆弱性.

根据我的经验,测试粒度的多样性是最重要的,因此我混合/组合方法:

• api-internals的单元测试(例如几个更复杂的映射要求,认证,棘手的验证规则,复杂的if/else逻辑,......)
• 在更粗糙的级别上进行烟雾测试,HTTP客户端正在与api交谈,即测试集成.这些测试将告诉我:服务器可以启动,主要api用例工作.作为工具我推荐soap-ui.
• 关于数据库状态:我经常从大多数基本数据开始(例如现有的api用户或预定义的不可变测试数据).应隔离每个测试的测试数据.如果我的测试包含更复杂的流程(例如,整个用例分布在多个HTTP调用上),则允许测试数据依赖于测试步骤(即,调用-2可能取决于通过调用而改变的服务器状态 - 1)

也许您可以对要测试的特定用例提供更多输入,那么可以提供更多帮助吗？

Answer 2

通常,在单元测试中,您尝试删除正在测试的单元(通常是函数/类/对象)之外的所有依赖项.在您的情况下(对于数据库)实现此目的的经典方法是通过使用模拟. http://en.wikipedia.org/wiki/Mock_object

基本上,您实现了一个"FakeDatabase",它共享返回已知值的实际数据库的API.