## Контекст - финтех и производство - enterprise платформы и системы - inhouse разработка - интеграция --- ### Без тестов - большинство inhouse проектов - началось как утилита, а теперь уже > 200k LOC --- ### Итнересный кейс :) At ASML, when you want to fix a bug, you first describe the bugfix in a Word document. This goes to various risk assessment managers. They assess whether fixing the bug might generate a regression elsewhere. There's no tests, remember, so they do _educated guesses_ whether the bugfix is too risky or not. If they think not, then you get a go to manually apply the fix in 6+ product families. Without automated tests. \- https://news.ycombinator.com/item?id=18442637 --- ## Зачем - Закрепить ожидаемое поведение системы - Проверить поведение на соответствие ожиданиям - Избежать регресса при внесении изменений --- ## Что - Общее поведение системы - интеграционные тесты - приемочные (acceptance) тесты - Низкоуровневые составляющие - минимальная/малая единица поведения: unit тесты --- ## Когда - При внесении изменений - В код - В конфигурацию (использование в новой среде) --- ## Итеративная командная разработка - Каждый выполняет свою задачу в отдельной ветке репозитория (или в иерархии веток) - Выполненные задачи накапливаются в отдельной ветке репозитория (develop, preprod, master, в зависимости от принятого flow) - В час "Ч" из этой ветки собирается релиз/деплой --- ## Две ключевые точки контроля - после завершения задачи/фикса - результат соответствует требованиям? (acceptance) - перед деплоем/релизом - ничего не сломалось при накоплении изменений? (integration) --- ## Форма теста - спецификация ожиданий в любом виде - код - протокол тестирования - user story/use case из текстовых описаний QA по мере необходимости делает скрипты --- ## В контексте CI/CD Для CI/CD необходим высокий уровень автоматизации - управления инфраструктурой и конфигурацией - мониторинга и оповещения **Интергационное тестирование обязательно** --- ## В контексте CI/CD **Интергационное тестирование обязательно** Но не обязательно автоматизированное :) --- ### Влияние тестов на качество системы (по моему опыту) - юнит тесты - далеко не всегда - интеграционные/acceptance тесты - значительно - не обязательно автоматизированные - чем больше проект, тем сильнее влияние * верификаторы кода - в каком-то одном аспекте (зависит от квалификации команды), как и линтеры --- ## Экзотика (и не очень) - Formal Verification (напр JML) - Property-Based Testing - Static code analyzers --- ## TDD При использовании TDD имеем: - дисциплина мышления - сначала думаем, потом делаем - сначала формулируем API и ожидания от - минимальной функциональной единицы (unit test) - подсистемы/модуля (ассеptance test) --- ## TDD - четкий процесс с малыми шагами - уверенность при внесении изменений - можно сфокусироваться на малой части функционала не беспокоясь о побочных эффектах) - эволюция кода (код непрерывно рефакторится под новые тесты) --- ## НО - подходит не всем и не всегда - может быть медленнее - требует дисциплины - при плохом проектировании - каскады ошибок в 1000е тестов - очень легко превратить редизайн (API, структуры) в АД --- # Автоматизируйте всё! И time-to-market будет измеряться в часах