api 内部的单元测试（例如，几个更复杂的映射要求、身份验证、棘手的验证规则、复杂的 if/else 逻辑等
） smoke-tests 在更粗粒度的级别上，HTTP 客户端正在与 api 通信，即测试 一体化。这些测试将向我展示：服务器可以启动，主要 api 用例可以工作。作为工具，我推荐 soap-ui。
关于数据库状态：我经常从最基本的数据开始（例如现有的 api 用户或预定义的不可变测试数据）。每个测试的测试数据应该是隔离的。如果我的测试包括更复杂的流程（例如，整个用例分布在多个 HTTP 调用上），则允许测试数据依赖于测试步骤（即 call-2 可能依赖于通过 call-2 更改的服务器状态） 1）
也许你可以对你想要测试的特定用例提供更多的输入，这样可以提供更多的帮助吗？
Question is what do you want to test. What do you think will break at the topmost api-layer (i.e. layer which is receiving HTTP request)?
Generally writing a unit-test restful-api sounds a bit like an oxymoron ;) By definition unit-tests are much smaller as using entry-point HTTP to database. It sounds more that your question is based on how to write large-tests (or acceptance, end-to-end test).
Beware that implementing such large-tests (end-to-end test) involves high effort:
Tests tend to be much slower
Maintenance costs of tests, because tests are tougher to comprehend (because of all this dependecies + test-data setups)
they are more prone to cause false-positive tests (test shows 'red' though it should be 'green'). Reason again is that more dependencies are involved in your tests, fragility is more likely.
In my experience diversity of test-granularity is king, therefore I mix/combine approaches:
unit-testing for api-internals (e.g. several more complex mapping requirements, authentication, tricky validation rules, complicated if/else logic, ...)
doing smoke-tests on more coarse grained level, HTTP client is talking to api, i.e. testing integration. These tests would show me: server could start-up, main api use-cases works. As tool I recommend soap-ui.
regarding database-state: I often start with most basic data (e.g. existing api-users or predefined immutable test-data). Test-data for each test should be isolated. If my test includes more complicated flow (e.g. a whole use-case is spread over multiple HTTP calls), test-data is allowed to depend on test-steps (i.e. call-2 might depend on server-state which got changed by call-1)
Maybe you can give more input on a specific use-case you want to test, so can give more help?
Usually, in unit tests, you try to remove all dependencies beyond the unit (usually a function/class/object) that you are testing. The classic way to accomplish this in your case (for databases) is through the use of mocks. http://en.wikipedia.org/wiki/Mock_object
Basically, you implement a "FakeDatabase" that shares the API of the actual database that returns known values.
发布评论
评论（2）
问题是你想测试什么。您认为最顶层 api 层（即接收 HTTP 请求的层）会出现什么问题？
一般来说，编写单元测试 Restful-api 听起来有点矛盾；）根据定义，单元测试比使用入口点 HTTP 到数据库要小得多。听起来您的问题更多是基于如何编写大型测试（或验收、端到端测试）。
请注意，实施此类大型测试（端到端测试）需要付出很大的努力：
根据我的经验，测试粒度的多样性是王道，因此我混合/组合方法：
也许你可以对你想要测试的特定用例提供更多的输入，这样可以提供更多的帮助吗？
Question is what do you want to test. What do you think will break at the topmost api-layer (i.e. layer which is receiving HTTP request)?
Generally writing a unit-test restful-api sounds a bit like an oxymoron ;) By definition unit-tests are much smaller as using entry-point HTTP to database. It sounds more that your question is based on how to write large-tests (or acceptance, end-to-end test).
Beware that implementing such large-tests (end-to-end test) involves high effort:
In my experience diversity of test-granularity is king, therefore I mix/combine approaches:
Maybe you can give more input on a specific use-case you want to test, so can give more help?
通常，在单元测试中，您尝试删除正在测试的单元（通常是函数/类/对象）之外的所有依赖项。在您的情况（对于数据库）中实现此目的的经典方法是通过使用模拟。 http://en.wikipedia.org/wiki/Mock_object
基本上，你实现了一个“FakeDatabase”共享返回已知值的实际数据库的 API。
Usually, in unit tests, you try to remove all dependencies beyond the unit (usually a function/class/object) that you are testing. The classic way to accomplish this in your case (for databases) is through the use of mocks. http://en.wikipedia.org/wiki/Mock_object
Basically, you implement a "FakeDatabase" that shares the API of the actual database that returns known values.