说我有一个很酷的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"}, {...}, ...}
现在，让我们说我想设置一些示例数据，并在某个指定的创建日期范围内针对GET /帐户资源编写一些测试。
例如，我想以某种方式将以下帐户插入系统
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 /帐户资源？还有另一种方式我没想到那更优雅吗？
答案 0 :(得分：1)
有很多方法可以做到这一点，而且你已经找到了一些可靠的解决方案（尽管可能并不完美）。
在测试设置中，我会启动像HSQLDB这样的内存数据库（还有其他数据库）并执行插入操作。测试配置会将适当的数据库配置注入服务提供者类。运行测试，然后在拆卸时关闭数据库。
这个post至少为持久性方面提供了一个很好的例子。
顺便说一句，请勿更改服务的API，以帮助促进测试。也许我误会了，你也不是，但我想我会提到以防万一。
希望有所帮助。
答案 1 :(得分：0)
对于它的价值，这些天我主要在大多数系统级别（黑盒）测试中使用第二种方法。
我创建具有安全要求的后门admin /测试api，只有我的系统测试才能访问。这些超强大的api使我可以播种数据。我尝试尽可能地限制这些api的范围，以使它们不会与特定的实现细节过度耦合，但足够灵活以允许指定所需的种子数据所需的内容。
我之所以喜欢Vidya提供的数据库解决方案这种方法，是因为我的测试没有与特定的数据存储技术结合在一起。如果我决定从mongo切换到发电机或类似的东西；使用管理api使我不必更新所有测试，而只需更新管理api / impl。