Ок. Еще вопросы:
1. распределение между запросами разного типа
2. критерии оценки, в частности, задержка против объема данных
3. предполагаемое распределение запросов между данными (аквтивно смотрим последнее, активно смотрим популярное, тупо долбим все равномерно)
Юнит тесты с моками в этом плане только хуже. Приемочный тест даст вам сигнал, что ошибка есть. Если вы забыли синхронизировать протокол мока с живым объектом, то о ошибке вы даже не узнаете. Про тестирование контроллеров вообще, я склоняюсь к мнению, что они быть настолько простыми, чтобы их не надо было тестировать.
Для этого есть приемочные тесты, в которых не надо зорко бдить за соответствие моков остальному коду. Моки вообще зло, они дают ложную уверенность отсутствия багов.
В контроллерах не должно быть такого количества когда, чтобы его захотелось протестировать модульными тестами. Хочешь юнит-тест? Пиши сервис, стратегию, etc.
Вы не боитесь, что люди будут выбирать неадекватные планы, и точить свой проект под них?
1. распределение между запросами разного типа
2. критерии оценки, в частности, задержка против объема данных
3. предполагаемое распределение запросов между данными (аквтивно смотрим последнее, активно смотрим популярное, тупо долбим все равномерно)