Flutter, тесты и CI (ч.1)
Тесты, автоматически прогоняемые в рамках пайплайнов CI/CD, либо по-старинке запускамые лапками, уже давно и плотно вошли в жизнь многих разработчиков. А там, где такого нет, люди очень топят за то, чтобы они появились. С одной стороны, к тестированию я всегда относился нейтрально. Не заставляют писать тесты - ну и ладно. С другой стороны, тесты периодически спасают мою шкурку от поиска и устранения багов, которые в ином случае обнаруживались пользователями. Поэтому, в этом посте я хотел бы освежить в памяти то, что небходимо знать о тестах и поделиться знаниями о некоторых "подводных камнях", на которые можно совершенно неожиданно натолкнуться.
Вспоминая пирамиду тестирования, мы можем выделить в рамках Flutter стандартный джентельменский набор тестов, который можно реализовать средствави библиотек от разработчиков фреймворка.
-
Unit-тесты. Писать качественные и содержательные unit-тесты - целое исскусство, имхо. Иначе мы скатываемся к проблеме вроде expect(true, true). Но так или иначе, это основа благополучия процесса тестирования.
-
Widget-тесты. Особый вид тестов, когда мы говорим flutter, что нам следует отрисовать, а после этого проверяем получившийся виджет на корректность: ищем элементы UI разными способами (по ключам, контенту и тд), пытаемся взаимодействовать с найденными элементами, проверяем правильность свойств виджета. По своей сути, тот же unit, только для виджета. Такими тестами очень классно покрывать переиспользуемые UI-элементы, UIKit, библиотеки виджетов. А еще можно косвенно оценить качество этих самых библиотек по тому, насколько легко писать widget-тесты для их составляющих.
-
Интеграционные тесты. Widget-тест на стероидах, где вместо обычного виджета мы запускаем наше приложение и тестируем то, наколько корректно выполняются сценарии. То есть проверяем факт, что пользователь успешно пройдет уготованный ему flow и получит ожидаемый результат. Писать такие тесты можно с помощью пакета integration_test прямо на dart, но QA-автоматизаторам это не очень по нраву 🙂
-
Golden-тесты. Очередной подвид widget-теста, но с одним важным шагом - сравнением получившегося изображения с эталоном, который мы храним недалеко от тестов. Это позволяет выявлять неожиданные баги в отрисовке виджетов. Также можно не ограничиваться лишь сравнением виджетов - можно таким образом тестировать стадии сложных анимаций и даже целые экраны.
А завтра в это же время - вторая часть поста, где мы рассмотрим один из подводных булыжников тестирования 🙂