Edit # 2: есть ли у кого-нибудь хороший метод тестирования "средний» клиент-серверного приложения, где мы можем перехватывать запросы и ответы, подделывать клиент или сервер по мере необходимости, и которое обеспечивает самодокументирование API?

Огурец может быть хорошим решением во многих случаях, но этоне совсем то, что яищу И этот средний уровень должен быть независимым от реализации клиент-сервер. (например, черный ящик).

Наша модель клиент-сервер представляет собой сервер ruby-on-rails с клиентом Flex, использующий интерфейс RESTish с JSON в качестве формата данных. Поэтому все, что клиент отправляет на сервер, обычно представляет собой один параметр JSON. Сервер делает этои отвечает чистой моделью JSON.

У нас есть стандартное тестирование рельсов на сервере, и мыработа над получением правильных тестов FlexUnit на клиенте (этодвижущаяся цель). Тем не менее, естьВ моей команде спор об эффективности текущей модели тестирования, поскольку каждое изменение на сервере, похоже, нарушает часть API. Это говорит мне о том, что существует проблема как с взаимодействием API (между членами команды, самодокументированием в коде и т. Д.), Так и с отсутствием надлежащего тестирования работоспособности API.

Так что я'Мы задавались вопросом, нужен ли нам фиктивный клиент для тестирования сервера на чистом уровне JSON (без всех других сложностей полнофункционального клиента) и, возможно, имитирующий сервер для того же действия с полнофункциональным клиентом. Это послужит двум целям: документировать API и обеспечить более тщательное тестирование самого API.

Причина тамСпор заключается в том, что специалист по рельсам утверждает, что тестирования интеграции по рельсам достаточно для тестирования всех запросов к серверу, а среда тестирования среднего уровня будет просто избыточной.

Таким образом, здесь возникает вопрос: с учетом нашей ситуации, как следует самостоятельно документировать API и как мы должны тестировать сам API?

РЕДАКТИРОВАТЬ:

У нас есть маршруты, такие как /foo/444/bar.js, но параметры могут быть практически любой сложной строкой JSON в зависимости от действия, например:

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

но кроме отредактированных вручную документов API, естьНет самодокументирования. Контроллер рельсов часто просто десериализует и применяет изменения непосредственно к модели. Было бы неплохо иметь общие тесты, чтобы сказать нам, когда этос изменился,а также какие'ожидается