Спасение через тестирование - история одного проекта
TRANSCRIPT
Отсутствие ТЗОтсутствие документацииОтсутствие тестовОтсутствие спецификаций APIОтсутствие средств дебагингаНаличие легаси багов
- PhpUnit наиболее быстрый путь- Альтернативы Behat, Codeception- Smoke тест на 200- Тесты на совпадение респонса- Реализация более глубокой логики тестов по мере развития проекта- Фича – тест- Багфикс - тест
Эталонные данные для тестов
1. Дамп с продакшена\беты2. Фикстуры
2.2. Генератор фикстурhttps://github.com/smart-gamma/fixtures-generator
2.1. Ручные фикстуры
2.3. Конструкторы фикстурhttps://github.com/h4cc/AliceFixturesBundle
2.4. Свой кастомный билдер
- Проблема большинства проектов - отсутствие ТЗ и документации. Лучший способ разобраться в коде - написать для него тест! Т.е. тест, как инструмент изучения проекта.
- Тесты – путь к лучшей архитектуре!
BDD
- Более поздний этап в действиях стабилизации проекта, но очень важный
- Помогает понимать всей команде один сценарий развития “фичи”
- Помогает говорить с Product Owner на одном языке
- Помогает продумать задачу до ее реализации
- Документирует проект (ТЗ как User Stories)
- Является критерием для тестирования
Debugging
Стандартные логи: - prod.log - access.log - error.log
Что делать, если необходимо посмотреть реальный “флов” API?
“smart-gamma/logger”
custom Capifony tail log commads: http://capifony.org
- error.log- prod.api.log