What is the recommended test method for a client JSON server?

Question

Edit # 2: Does anyone have a good method of testing the “middle” of a client-server application where we can intercept requests and responses, fake a client or server as needed, and which provides self-documentation api?

Cucumber can be a good solution in many cases, but this is not quite what I am looking for. And this middle tier should be an agnostic client / server implementation. (e.g. black box).

---

Our client-server model is a ruby-on-rails server with a Flex client using the RESTish interface with JSON as the data format. Thus, everything that the client sends to the server is usually a single JSON parameter. The server does this and responds with a clean JSON model.

We have standard rail testing on the server, and we are working on getting proper FlexUnit tests on the client (this is a moving target). However, my team discusses the effectiveness of the current testing model, since each change on the server seems to break part of the API. This tells me that there is a problem with the API (between team members, self-documentation in the code, etc.) and the lack of proper testing for API compliance.

So, I wondered if we needed a mock client to test the server on a pure JSON level (without all the other complexities of a rich client) and, possibly, a mock server to do the same with a rich client. This will serve two purposes: document the API and provide more thorough testing of the API itself.

The reason the debate is because the rail guy claims that testing rail integration is enough to test all server requests, and the environment-based testing environment will simply be redundant.

So, the question here, given our situation, how should we relate to API self-documentation and how should we test the API itself?

EDIT:

We have routes like / foo / 444 / bar.js, but the parameters can be almost any complex JSON string, depending on the action, for example:

json={ "foo":{ "x":1, "y":2 }, "bar":[1,2,3,4,5] } 

but, apart from manually edited API documents, there is no self-documentation. The rail controller often simply deserializes and applies the changes directly to the model. It would be nice to have general tests to tell us when they changed and what was expected.

Answer 1

I just started to learn this Maxq web-based functional testing tool, and I think that it can solve your problem, Maxq acts as a proxy server between your web client and the server application. It sits on top of Junit, so you can do proper unit testing for your API by validating the behavior and call responses to the server application. It basically captures and records all the requests that you make from the web client, and the responses that you return from the server, it also has the ability to generate test scripts of your request, which you can use to play and test on any server.

You should try http://maxq.tigris.org/

Answer 2

You can think of it as two different projects. If you had two projects, would you write two separate test suites?

You should start by establishing an API between the server and the client , as if you would not have any communication between the teams after starting the implementation.

Then you create a client that consumes the API and a server that creates the API (or tests first if you are TDD).

For testing, one team needs a mock server to provide false API responses for client testing, and the other team needs to test the received server data (i.e. the second team uses ails integration testing, such as your rails guy claims)

Answer 3

I would recommend Cucumber. It allows you to write specific tests for your application, emulating a browser. This way you can easily send requests and check the JSON response.

Answer 4

One way to do this is with controller tests using rspec (you can also use test :: unit)

 describe PersonApiController # GET /person/1.json it "should respond with a person" do person = Person.create(:name => "scott") get :show, :id => person.id, :format => 'json' response.should be_success response.body.should have_selector('name', :content => person.name) end end