Исправление seiken, (текущая версия) :
Там нетривиальный стэк протоколов, с нашей (клиентской) стороны над ним работает не один чел, включая аутсорс, нам даются уже готовые клиентские либы, а мы пишем с этими либами конкретный апп. Проблема в том, что иногда баги и в нашем (не нашей команды, но нашей конторы), платформенном коде для клиентов.
Т.е. при грамотном распределении труда, такие тестовые моки сервиса должны писаться один раз для всей платформы и клиентов, но не для каждого аппа разными людьми выдумываться свои мок-велосипеды. Благо, структура сообщений уровня приложения одинакова, различается только контент. Т.е. можно разработать тестовое клиент/серверное приложение X, которое будет и тестом, и примером реализации для разработчиков конкретных аппов.
По крайней мере, таким образом можно тестить все уровни кроме уровня приложения (всевозможные сценарии разрывов сессий, ошибок и т.п.). Так ведь?
Исходная версия seiken, :
Там нетривиальный стэк протоколов, с нашей (клиентской) стороны над ним работает не один чел, включая аутсорс, нам даются уже готовые клиентские либы, а мы пишем с этими либами конкретный апп. Проблема в том, что иногда баги и в нашем (не нашей команды, но нашей конторы), платформенном коде для клиентов.
Т.е. при грамотном распределении труда, такие тестовые моки сервиса должны писаться один раз для всей платформы и клиентов, но не для каждого аппа разными людьми выдумываться свои мок-велосипеды. Благо, структура сообщений уровня приложения одинакова, различается только контент. Т.е. можно разработать тестовое клиент/серверное приложение X, которое будет и тестом, и примером реализации для разработчиков конкретных аппов. Так ведь?