Роман Петров - юнит-тестирование мобильных приложений на примере платформы iOS
- 1. Unit-тестирование мобильных приложений на примере платформы iOS Роман Петров, технический директор Omega-R
- 3. Зачем писать юнит-тесты? ● Быть уверенным в том, что ваш код работает как надо. ● Продолжать быть уверенным в этом после внесения изменений (защита от регрессии). ● Сокращать время ручного тестирования (как программистов, так и тестировщиков). ● Эффективно использовать системы непрерывной интеграции (без авто-тестов смысла в них становится меньше). ● Повышать ЧСВ: «Я могу в юнит-тесты!»
- 4. Почему многие не пишут юнит-тесты?
- 6. «Я же крутой, я и без тестов правильно напишу!»
- 7. «Чукча не читатель, чукча писатель!»
- 8. «Как на ЭТО вообще можно тесты написать?»
- 10. Немного теории ● Юнит-тесты — они же модульные тесты. ● Минимальный модуль в ООП — класс. ● Тестируем каждую нетривиальную функцию. ● Пишем более комплексные тесты на взаимосвязанные функции. ● Пишем как положительные, так и отрицательные тесты. ● Аксиома: НИКОГДА не верь входным данным, даже если данные дает твой собственный код. ● В сферическом приложении в вакууме все функции являются «чистыми», а классы — абсолютно изолированы. ● Реальность кусается.
- 11. Средства тестирования на мобильных платформах
- 12. iOS XCTest — родное средство для юнит-тестов, умеет все: собственно юнит- тесты, тесты асинхронных процессов, замеры производительности, тестирование UI. OCMock — средство для создания mock-объектов (полноценно работает только с Objective-C). KIF Framework — более удобное средство для автоматизации тестирования UI.
- 13. Android JUnit — стандартный фреймворк для написания юнит-тестов на Java, тесты запускаются в виртуальной машине Java на компьютере. Espresso — фреймворк для тестирования UI (входит в Android Testing Support Library). AndroidJUnitTestRunner — средство для запуска JUnit-тестов на реальных устройствах и симуляторе.
- 14. Windows Phone В среде MS Visual Studio есть все необходимые инструменты как для модульного тестирования, так и для интерфейсного тестирования.
- 16. В идеале ВСЁ
- 17. В реальности Расставим приоритеты: ● Весь код модели (в паттерне MVC). ● Работа с API (как со своим, так и с чужим). ● Use cases (без UI). ● Производительность критических участков.
- 18. Перестаем бояться тестов и начинаем их писать
- 20. Тестируем факториал Все хорошо Почти все плохо
- 24. Тест работы с API: делаем это правильно Необходимо разорвать зависимость (если она есть) и определить протокол. В Objective-C можно использовать OCMock, но лучше и в нем использовать протоколы.
- 25. Тест работы с API: делаем это правильно
- 26. Тестируем работу с CoreData Не включаем классы сущностей в тестовый таргет и импортируем модуль приложения в классе теста. Классы сущностей надо будет сделать публичными.
- 27. Тестируем работу с CoreData
- 28. Тест на вызов метода делегата В OCMock есть готовое средство для таких тестов, но работает это, опять же, только в Objective-C. Поэтому на Swift пишем сами.
- 29. Тест на вызов метода делегата
- 30. Общие методы в нескольких наборах тестов
- 31. Очевидно, но не очень правильно Наследование приводит к появлению лишнего пустого набора тестов
- 32. Правильно Расширение класса Протокол с реализацией по умолчанию Пример использования
- 33. Как улучшать архитектуру, чтобы тесты писались легче (и вообще писались)
- 34. Улучшаем архитектуру ● Чистые функции и чистые классы ● Разрыв зависимостей ● Один класс — одна задача (single responsibility) ● Применяем паттерны проектирования
- 35. Благодарю за внимание! А теперь время для вопросов