День 125. Тестирование в разработке (беседы с разработчиком)
1. Unit-тесты. Тест на конкретный метод или функцию в коде (низкоуровневый). Делают инженеры, PM и тестировщики не опускаются на этот уровень. Покрываются все нетривиальные функции. Запускать такие функции быстро, проверить быстро — доли секунды, дешевле всего в разработке.
2. Интеграционные тесты. Как функции работают между собой в связке (тестируют модуль). Например, перевод денег по номеру телефона, чтобы у одного списалось, другому зачислилось. Можно использовать реальную базу данных или заглушки. Задача бизнес логику, не весь юзерстори. На таких тестах принимаем риски, что может быть база глючить и тест не пройдет. Интеграционных тестов меньше, чем unit-тестов, нужна тестовая база или заглушки, долго работает, секунды — дороже делать.
3. End to end. Эмуляция действий пользователя в приложении. На эмуляторе запускается приложение, вбивается номер телефона, сумма, нажимается кнопка ок. Проверяем, что на экране обновился баланс, если нет — выдаем ошибку. Плюсы — максимально близко эмулирует приложение. Минусы — хрупкий, может развалиться из-за проблем с сетью, или эмулятор глюкнул (сервер, на котором крутится эмулятор сломался). End to end тестов меньше всего, самые тяжелые в поддержке. Время на каждый тест — десятки секунд.
4. Snapshot-тест. По сути, это тестирование API — отправка запроса, сверка ответа с шаблоном. Если поля меняются, то тест отловит. Подробнее: https://docs.pact.io/
5. Test Rail. Система для расписывания тест кейсов, похоже на вики. Тесты записываются по фреймворку "given when then", главное, чтобы всем кто читает, было понятно. Тесты пишут люди. Если неверно зафиксируешь тест или неправильно его имплементируешь, все-равно может быть баг. Подробнее: https://habr.com/ru/post/81737/
6. В крупных компаниях тестировщик — это инженер который умеет прогать. На входе фича описывается как юзерстори, тестировщик берет юзерстори и сам прописывает тест кейсы (валюты, экраны, нет денег, отправка кода из SMS). Описывает в Test Rail граничные кейсы (например, отвалился интернет). Unit-тесты и интеграционные делает разработчик. По окончании разработки фичи, тестировщик руками прокликивает фичу и пишет end to end тесты.
7. Регрессионные тесты — это то, что прогоняется непосредственно перед релизом. Unit-тесты гоняются при каждом билде. Интеграционные гоняются раз в час. End to end раз в релиз обычно.
8. Тесты оценивают по финансам: если тест автоматизировать займет 100 часов тестировщика, а пройти руками 30 секунд, такие сценарии не автоматизируют, всегда проводят руками.
9. Имхо названия попутаны. Интеграционные тест = тест нескольких сервисов, их интеграция между собой. Возможно автор опустил до интеграции классов в коде между собой, но имхо это все же юнит все равно. End to end эм.. ладно, пох на названия. Допустим пункт 2 это все-таки про юзание разных сервисов, тогда
10. Между 1 и 2 пропущен behaviour tests, они пишутся в коде в формате, похожем на 5 пункт. Я люблю их больше всего. Они тестят не отдельные функции, а прям функционал, юзер стори, но без интерфейса. Пример http://goconvey.co <- конкретно этот товарищ обычно разрабам мозг ломает первое время, но можно это делать и без его магии. гуглится по BDD