Пытался прикинуть, но начал вспоминать множество «подводных камней» и доработок, которые были выполнены, и думаю не смогу ответить на Ваш вопрос. Сложно сказать сколько человекодней затрачено с самого начала. Система развивается скорее по необходимости, а не непрерывно. Сейчас ей уже больше 2х лет. Последнее значительное изменение было в декабре — сделали переиспользование симуляторов.
Самая сложная часть системы — автоматизация UI-тестирования. На нее затратили значительно бОльшую часть времени, нежели на все остальное. Часто приходилось почти «в слепую» искать решение, как с очисткой keychain, например. Хоть в статье и описаны 2 этапа развития, но это только основные крупные этапы, были и промежуточные работоспособные этапы, помимо доработок и исправлений.
Если говорить о проверках проекта и исходников, то зависит от сложности модуля. Они, по-сути, не сильно зависят от всей системы, лишь бы соответствовали определенному интерфейсу. Некоторые из работающих на данный момент разрабатывались и встраивались буквально за полдня-день.
Ящики настоящие, и на первых этапах это казалось преимуществом — тестируем на живом, видим проблемы взаимодействия сразу. Потом появились тесты, которые непоправимо модифицируют ящик.
Из нескольких вариантов мы остановились на самом простом — стабы.
С момента их появления, конечно, можно спорить насчёт утверждения про настоящие ящики. Теперь это гибрид. Часть тестов работают полностью на «живом», а часть с момента модификации стабится. Сейчас мы думаем над заменой текущей системе со стабами.
Но про пользу не совсем понял. В текущем виде настоящий ящик является только стартовой точкой для теста с модификацией. Конечное состояние ящика совпадает с начальным, так как модифицирующие запросы не доходят до бэк-энда.
Тут, кажется, можно занять две точки зрения:
— тестирование самого приложения, считая API бэк-энда «утвержденным контрактом»;
— тестирование приложения и его взаимодействия с «живым» бэк-эндом.
Исходно, конечно, хотели покрыть взаимодействие с настоящим сервером, но без дополнительных возможностей, о которых Вы как раз написали (создание одноразового ящика по заданной конфигурации), это вряд ли получится сделать. Сейчас у нас их нет.
Поэтому мы сейчас ближе к первому варианту, но все же где-то по-середине.
Самая сложная часть системы — автоматизация UI-тестирования. На нее затратили значительно бОльшую часть времени, нежели на все остальное. Часто приходилось почти «в слепую» искать решение, как с очисткой keychain, например. Хоть в статье и описаны 2 этапа развития, но это только основные крупные этапы, были и промежуточные работоспособные этапы, помимо доработок и исправлений.
Если говорить о проверках проекта и исходников, то зависит от сложности модуля. Они, по-сути, не сильно зависят от всей системы, лишь бы соответствовали определенному интерфейсу. Некоторые из работающих на данный момент разрабатывались и встраивались буквально за полдня-день.
Из нескольких вариантов мы остановились на самом простом — стабы.
С момента их появления, конечно, можно спорить насчёт утверждения про настоящие ящики. Теперь это гибрид. Часть тестов работают полностью на «живом», а часть с момента модификации стабится. Сейчас мы думаем над заменой текущей системе со стабами.
Но про пользу не совсем понял. В текущем виде настоящий ящик является только стартовой точкой для теста с модификацией. Конечное состояние ящика совпадает с начальным, так как модифицирующие запросы не доходят до бэк-энда.
Тут, кажется, можно занять две точки зрения:
— тестирование самого приложения, считая API бэк-энда «утвержденным контрактом»;
— тестирование приложения и его взаимодействия с «живым» бэк-эндом.
Исходно, конечно, хотели покрыть взаимодействие с настоящим сервером, но без дополнительных возможностей, о которых Вы как раз написали (создание одноразового ящика по заданной конфигурации), это вряд ли получится сделать. Сейчас у нас их нет.
Поэтому мы сейчас ближе к первому варианту, но все же где-то по-середине.