Theory of testing is usually differs from practice. Today we want to talk about our practical experience in testing application's code which is used by millions of iOS users and about the difficult path that our team finished in order to achieve stable code.

Let’s imagine: the developers successfully convinced themselves and the business of the need to cover the code with tests. Over time, in the project were created more than a dozen thousand unit- and more than a thousand UI-tests. Such a large test base araised several problems, and we successfully found the solution for them.

Instruments for Apple's Xcode is a tool for performance analysis of an iOS application. In 2018 Apple introduced Custom Instruments — an opportunity to expand the standard set of instruments for application profiling. When existing tools are not enough, you can create new ones yourself — it will collect, analyze and display the data the way you need.

Instruments для Xcode компании Apple — это инструменты для анализа производительности iOS-приложения. Их используют для сбора и отображения данных, которые необходимы в отладке кода. В прошлом году Apple презентовала Custom Instruments. Это возможность расширить стандартный набор инструментов для профилирования приложений. Когда существующих инструментов недостаточно, вы сможете самостоятельно создать новые — они соберут, проанализируют и отобразят данные так, как вам потребуется.

Прошел год, а новых публичных инструментов и информации по их созданию в сети почти нет. Так что мы решили исправить ситуацию и поделиться тем, как создавали собственный Custom Instrument, который определяет причину слабой изоляции unit-тестов. Он базируется на технологии signpost (мы писали о ней в предыдущей статье) и позволяет быстро и точно определять место возникновения мигания теста.

В предыдущей статье мы познакомились с пирамидой тестирования и тем, какую пользу несут автоматизированные тесты. Но теория, как правило, отличается от практики. Сегодня мы хотим рассказать о своем опыте тестирования кода приложения, которым пользуются миллионы пользователей iOS. А также о том непростом пути, который пришлось пройти нашей команде для достижения стабильного кода.

Ситуация такова: предположим, разработчикам удалось убедить себя и бизнес в необходимости покрытия кодовой базы тестами. Со временем в проекте стало более десятка тысяч unit- и более тысячи UI-тестов. Такая большая тестовая база породила несколько проблем, о решении которых мы хотим рассказать.

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