编辑＃2:是否有人有一个好的方法来测试客户端-服务器应用程序的“中间”，我们可以在其中拦截请求和响应，根据需要伪造客户端或服务器，并提供 api 的自文档？
在很多情况下，Cucumber 可能是一个很好的解决方案，但这并不是我想要的。这个中间层应该与客户端/服务器实现无关。 (例如，黑匣子)。
我们的客户端-服务器模型是带有 Flex 客户端的 ruby-on-rails 服务器，使用 RESTish 接口(interface)，以 JSON 作为数据格式。因此，客户端向服务器发布的任何内容通常都是单个 JSON 参数。服务器执行该操作并使用纯 JSON 模型进行响应。
我们在服务器上进行了标准 Rails 测试，并且正在努力在客户端上完成适当的 FlexUnit 测试(这是一个不断变化的目标)。然而，我的团队对当前测试模型的有效性存在争论，因为服务器上的每个更改似乎都会破坏 API 的一部分。这告诉我，API 通信存在问题(团队成员之间、代码中的 self 文档等)，并且缺乏适当的 API 健全性测试。
所以我一直在质疑我们是否需要一个模拟客户端来在纯 JSON 级别测试服务器(没有富客户端的所有其他复杂性)，并且可能需要一个模拟服务器来执行相同的操作富有的客户。这有两个目的:记录 API 并提供对 API 本身更彻底的测试。
引起争论的原因是，rails 人员声称 Rails 集成测试足以测试所有服务器请求，而中间测试环境只是多余的。
所以这里的问题是，考虑到我们的情况，应该如何 self 记录 API，以及我们应该如何测试 API 本身？
编辑:
我们有像/foo/444/bar.js 这样的路由，但参数实际上可以是任何复杂的 JSON 字符串，具体取决于操作，例如:
json={
"foo":{
"x":1,
"y":2
},
"bar":[1,2,3,4,5]
}
但除了手动编辑的 API 文档之外，没有 self 文档。 Rails Controller 通常只是反序列化并将更改直接应用于模型。如果有通用的测试来告诉我们什么时候发生了变化以及预期会发生什么，那就太好了。
最佳答案
我刚刚开始研究这个名为 Maxq 的 Web 功能测试工具，我认为它有可能解决您的问题，Maxq 充当 Web 客户端和服务器应用程序之间的代理服务器。 它位于 Junit 之上，这意味着您可以通过断言对服务器应用程序的调用的行为和响应来为您的 API 进行适当的单元测试。 它基本上捕获并记录您从 Web 客户端发出的所有请求以及您从服务器返回的响应，它还能够生成您的请求的测试脚本，您可以使用该脚本在任何服务器上回放和测试。
你应该尝试一下http://maxq.tigris.org/
关于ruby-on-rails - 测试 JSON 客户端-服务器 api 的推荐方法是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1376479/