Боль №4: Testing
TL;DR
Минусы|ысюлП
Отсутствие
автоматизированных тестов
Ручное тестирование релиза
• В ручном тестировании доминирует человеческий
фактор: устал, забыл, забил, не подумал
• На регрессионное тестирование уходит очень много
времени и сам результат нестабилен
• Тест-кейсы очень редко фиксируются
документально - тестирование не прозрачно и
зависит от опыта тестировщика
Отсутствие
модульных тестов
Сложно оценить
адекватность алгоритмов
и, следовательно,
гарантировать их
корректную работу
Отсутствие
интеграционных тестов
SOA- это хорошо, но
• Чем больше сервисов, тем сложнее отследить влияние каждого
отдельного релиза на всю систему в целом
• Все компоненты системы чувствительны к изменениям API
«соседей» и проблемы выявляются далеко не сразу
• Пример из жизни: новое оформление заказов на сайте
сломало возврат онлайн-платежей в 1С, узнали об этом спустя
месяц эксплуатации
Как итог
• рост технического долга без тестов делает
рефакторинг рискованной операцией и,
следовательно, ухудшают поддерживаемость
кодовой базы
• сложно оценивать адекватность алгоритмов и,
следовательно, гарантировать их корректную работу
при ревью кода, если нет тестовых сценариев их
использования
• с ростом проекта он становится менее устойчивым
к изменениям, усложняя процесс внедрения нового
функционала
Как будем тестировать?
• Модульное тестирование - покроем юнит-тестами
наиболее критичный функционал (все что связано с
платежами, оформлением заказов)
• Интеграционное тестирование - покроем API
фукнциональными тестами в полном соответствии с
документацией
Какие инструменты нам
потребуются?
• PHPUnit
Какие инструменты нам
потребуются?
• PHPUnit
• Codeception
Какие инструменты нам
потребуются?
• PHPUnit
• Codeception
• flow/jsonpath
Какие инструменты нам
потребуются?
• PHPUnit
• Codeception
• flow/jsonpath
• Jenkins
Простой пример: покрываем методы API
по добавлению товаров в избранное
Непрерывная интеграция с Jenkins
• все, что попало в master готово к релизу
• <target name="build" depends="prepare,lint,phpcs,phpunit"
description="Сборка проекта."/>
• fab tester deploy - если все ок, то отправляем эти изменения на preproduction
• bin/codecept build && bin/codecept run functional --steps - запускаем
функциональные тесты на preproduction
[35;1mПротестировать интеграцию "Серверной корзины" и "Списка желаемых покупок".[39;22m
(CartAndWishlistCept)
Scenario:
* I send post "/cart/flush", {...}
* I see response code is 200
* I send post "/wishlist/reset", {...}
…
Полезные ссылки
• https://ru.wikipedia.org/wiki/
Тестирование_программного_обеспечения
• https://ru.wikipedia.org/wiki/Разработка_через_тестирование
• http://behat.org/en/latest/
• http://allure.qatools.ru/
Почему баги попадают в
продуктив?!
тестируй за собой
Спасибо за внимание!
Есть вопросы?
Камиль Самигуллин
какой-то разработчик
kamil@samigullin.info
@ikamilsk
github.com/kamilsk
linkedin.com/in/kamilsk

Enter: testing