Комментарии 7
Выглядит монументально. Сколько человекодней делали+внедряли, если не секрет?
Пытался прикинуть, но начал вспоминать множество «подводных камней» и доработок, которые были выполнены, и думаю не смогу ответить на Ваш вопрос. Сложно сказать сколько человекодней затрачено с самого начала. Система развивается скорее по необходимости, а не непрерывно. Сейчас ей уже больше 2х лет. Последнее значительное изменение было в декабре — сделали переиспользование симуляторов.
Самая сложная часть системы — автоматизация UI-тестирования. На нее затратили значительно бОльшую часть времени, нежели на все остальное. Часто приходилось почти «в слепую» искать решение, как с очисткой keychain, например. Хоть в статье и описаны 2 этапа развития, но это только основные крупные этапы, были и промежуточные работоспособные этапы, помимо доработок и исправлений.
Если говорить о проверках проекта и исходников, то зависит от сложности модуля. Они, по-сути, не сильно зависят от всей системы, лишь бы соответствовали определенному интерфейсу. Некоторые из работающих на данный момент разрабатывались и встраивались буквально за полдня-день.
Самая сложная часть системы — автоматизация UI-тестирования. На нее затратили значительно бОльшую часть времени, нежели на все остальное. Часто приходилось почти «в слепую» искать решение, как с очисткой keychain, например. Хоть в статье и описаны 2 этапа развития, но это только основные крупные этапы, были и промежуточные работоспособные этапы, помимо доработок и исправлений.
Если говорить о проверках проекта и исходников, то зависит от сложности модуля. Они, по-сути, не сильно зависят от всей системы, лишь бы соответствовали определенному интерфейсу. Некоторые из работающих на данный момент разрабатывались и встраивались буквально за полдня-день.
Спасибо за статью, очень подробно и интересно все рассказано. А рассматривали calabash для написания тестов? Чем не понравился, если не секрет? Фреймворк на ruby, идет вполне в ногу со XCode обновлениями, даже FBSimulator включен в последних версиях.
Вот говорится "Для UI-тестов используются настоящие почтовые аккаунты… стабим все модифицирующее сетевое взаимодействие… Это дает возможность сохранить состояние ящиков". Т.е. ящики всё-таки настоящие? Нет никакого тестового окружения, где можно было бы создать чистый ящик, что-то поделать и убить его в конце теста? Кажется, что без такой возможности тесты не очень полезны.
Ящики настоящие, и на первых этапах это казалось преимуществом — тестируем на живом, видим проблемы взаимодействия сразу. Потом появились тесты, которые непоправимо модифицируют ящик.
Из нескольких вариантов мы остановились на самом простом — стабы.
С момента их появления, конечно, можно спорить насчёт утверждения про настоящие ящики. Теперь это гибрид. Часть тестов работают полностью на «живом», а часть с момента модификации стабится. Сейчас мы думаем над заменой текущей системе со стабами.
Но про пользу не совсем понял. В текущем виде настоящий ящик является только стартовой точкой для теста с модификацией. Конечное состояние ящика совпадает с начальным, так как модифицирующие запросы не доходят до бэк-энда.
Тут, кажется, можно занять две точки зрения:
— тестирование самого приложения, считая API бэк-энда «утвержденным контрактом»;
— тестирование приложения и его взаимодействия с «живым» бэк-эндом.
Исходно, конечно, хотели покрыть взаимодействие с настоящим сервером, но без дополнительных возможностей, о которых Вы как раз написали (создание одноразового ящика по заданной конфигурации), это вряд ли получится сделать. Сейчас у нас их нет.
Поэтому мы сейчас ближе к первому варианту, но все же где-то по-середине.
Из нескольких вариантов мы остановились на самом простом — стабы.
С момента их появления, конечно, можно спорить насчёт утверждения про настоящие ящики. Теперь это гибрид. Часть тестов работают полностью на «живом», а часть с момента модификации стабится. Сейчас мы думаем над заменой текущей системе со стабами.
Но про пользу не совсем понял. В текущем виде настоящий ящик является только стартовой точкой для теста с модификацией. Конечное состояние ящика совпадает с начальным, так как модифицирующие запросы не доходят до бэк-энда.
Тут, кажется, можно занять две точки зрения:
— тестирование самого приложения, считая API бэк-энда «утвержденным контрактом»;
— тестирование приложения и его взаимодействия с «живым» бэк-эндом.
Исходно, конечно, хотели покрыть взаимодействие с настоящим сервером, но без дополнительных возможностей, о которых Вы как раз написали (создание одноразового ящика по заданной конфигурации), это вряд ли получится сделать. Сейчас у нас их нет.
Поэтому мы сейчас ближе к первому варианту, но все же где-то по-середине.
Тупо лайк за статью, и как таких творческих людей не уволили…
А как менеджер, который следит за Х фичами, может увидеть по ним картину? Возможно сделать скриншот?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как устроено автоматическое тестирование в Почте Mail.Ru под iOS