问题
说我有一个很酷的REST资源 /account .
我可以创建新帐户
POST /account
{accountName:"matt"}
这可能会产生一些json响应，如：
{account:"/account/matt", accountName:"matt", created:"November 5, 2013"}
我可以通过调用以下方式查找在日期范围内创建的帐户：
GET /account?created-range-start="June 01, 2013"&created-range-end="December 25, 2013"
这可能也会产生类似的东西：
{accounts: {account:"/account/matt", accountName:"matt", created:"November 5, 2013"}, {...}, ...}
现在，让我们说 I want to set up some sample data and write some tests against the GET /account resource within some specified creation date range .
例如，我想以某种方式将以下帐户插入系统
name=account1, created=January 1, 2010
name=account2, created=January 2, 2010
name=account3, created=December 29, 2010
name=account4, created=December 30, 2010
然后打电话
GET /account?created-range-start="January 2, 2010"&created=range-end="December 29,2010"
并验证仅返回帐户2和3 .
我应该如何插入这些示例帐户来编写测试？
可能的解决方案
1）我可以使用控制反转并允许用户指定新帐户的创建日期 .
POST /account
{account:"matt", created="June 01, 2013"}
但是，即使创建的字段是可选的，我也不喜欢这种方法，因为我可能不希望我的用户能够设置其帐户的创建日期 . 我当然需要能够进行测试，但将这些功能作为公共API的一部分似乎对我来说是错误的 . 也许我想给在某一天之前加入的任何人提供5美元的积分 . 如果他们可以指定创建日期，则用户可以对系统进行游戏 . 不好 .
2）我可以添加一个或多个测试配置资源
PUT /account/creationDateTimestampProvider
{provider="DefaultProvider"}
要么
PUT /account/creationDateTimestampProvider
{provider="FixedDateProvider", date="June 01, 2013"}
这种方法使我能够在安全性限制下锁定这些资源，这样只有我的测试上下文可以调用它们，但它也必然会对系统产生副作用，这可能会让管理变得很麻烦，特别是如果我有一堆后门配置资源 .
3）我可以直接与数据库交互，完全绕过REST api来设置我的样本数据 .
INSERT INTO ACCOUNTS ...
GET /account?...
然而，这可以让我进入使用REST api可能不允许我进入的状态，并且随着db模型的发展，维护这些sql脚本也可能是一种痛苦 .
那么......我如何测试我的GET /帐户资源？还有另一种方式我没想到那更优雅吗？
1 回答
有很多方法可以做到这一点，你已经提出了一些可靠的解决方案（尽管可能并不完美） .
在测试的设置中，我会启动内存数据库，如HSQLDB（还有其他数据库）并执行插入操作 . 测试配置会将适当的数据库配置注入服务提供者类 . 运行测试，然后在拆卸时关闭数据库 .
这个post至少为持久性方面提供了一个很好的例子 .
顺便说一下，不要仅仅为了促进测试而更改服务的API . 也许我误会了，你不管怎么说，但我想我会提到以防万一 .
希望有所帮助 .