Слайд 2Что такое Unit-тест
Фрагмент кода, написанный разработчиком, для провеки очень маленького, специфичного фрагмента
![Что такое Unit-тест Фрагмент кода, написанный разработчиком, для провеки очень маленького, специфичного фрагмента функциональности кода.](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/1067021/slide-1.jpg)
функциональности кода.
Слайд 3Зачем нужно возиться с тестами
они делают жизнь проще
они делают дизайн приложения лучше
они
![Зачем нужно возиться с тестами они делают жизнь проще они делают дизайн](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/1067021/slide-2.jpg)
значительно уменьшают время, затрачиваемое на отладку.
Слайд 4Чего мы добиваемся написанием тестов
Ответов на вопросы:
Делает ли код то, что ожидает
![Чего мы добиваемся написанием тестов Ответов на вопросы: Делает ли код то,](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/1067021/slide-3.jpg)
от него разработчик?
Делает ли он это все время?
Можно ли положиться на код?
Побочные эффекты:
Документирование кода и способов работы с ним
Слайд 5Как писать юнит-тесты
Ответить на вопрос: как мы будем тестировать новый метод.
Написать тест
![Как писать юнит-тесты Ответить на вопрос: как мы будем тестировать новый метод.](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/1067021/slide-4.jpg)
и тестируемый класс.
Запустить тест.
Запустить ВСЕ тесты системы.
Слайд 6Типичные отговорки
Написание тестов занимает слишком много времени
Запуск тестов занимает слишком много времени
Это
![Типичные отговорки Написание тестов занимает слишком много времени Запуск тестов занимает слишком](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/1067021/slide-5.jpg)
не моя работа – тестировать мой код
Я не знаю точно, как код должен работать, поэтому я не могу написать тест
Но он же компилируется!
Мне платят за за написание кода, а не тестов
Я чувствую вину, оставляя QA без работы
Моя компания не позволит запустить юнит-тысты на live-системе
Слайд 7Написание тестов занимает
слишком много времени
Перед тем, как использовать эту отговорку оцените:
Сколько времени
![Написание тестов занимает слишком много времени Перед тем, как использовать эту отговорку](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/1067021/slide-6.jpg)
вы тратите на дебаг кода, написанный вами и вашими коллегами
Сколько времени тратится на переработку кода после нахождения крупных багов?
Сколько времени тратится на то, чтобы локализовать обнаруженный баг в коде?
Слайд 8Написание тестов занимает слишком много времени
![Написание тестов занимает слишком много времени](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/1067021/slide-7.jpg)
Слайд 10Структура теста
Создать условия, необходимые для тестов (создать объекты, моки, ресурсы и др.)
Настроить
![Структура теста Создать условия, необходимые для тестов (создать объекты, моки, ресурсы и](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/1067021/slide-9.jpg)
моки (если нужно)
Вызвать тестируемый метод
Проверить, что тестируемый метод ведет себя как ожидается
Прибрать за собой (закрыть ресурсы и т.п.)
Слайд 11Right-BICEP
Right – верны ли результаты?
B – Boundary верны ли граничные условия?
I –
![Right-BICEP Right – верны ли результаты? B – Boundary верны ли граничные](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/1067021/slide-10.jpg)
Inverse можно ли проверить обратные связи?
C – Cross-check можно ли проверить результат другими методами?
E – Error conditions можно ли вызвать ошибочные состояния искусственно?
P – Performance удовлетворительна ли производительность?
Слайд 12Right
верны ли результаты
Если результаты выполнения кода верны, то как я об этом
![Right верны ли результаты Если результаты выполнения кода верны, то как я об этом узнаю?](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/1067021/slide-11.jpg)
узнаю?
Слайд 13B – Boundary
Проверка граничных условий
CORRECT
Conformance – верен ли формат значения?
Ordering – является
![B – Boundary Проверка граничных условий CORRECT Conformance – верен ли формат](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/1067021/slide-12.jpg)
ли правильный набор данных упорядоченным?
Range – лежит ли значение в пределах конкретных минимального и максимального значения?
Reference – ссылается ли код на что-либо внешнее, что не находится под контролем данного кода? Зависит ли от состояния зависимостей, состояние объекта? Зависит ли код от каких-либо условий.
Existence -
Cardinality – количественная проврка результата (нужное ли количество возвращается/используется методами)?
Time – все ли происходит в нужном порядке? В нужное время? В пределах допустимого времени? Правильно ли обрабатываются конкурентные условия?
Слайд 14I - Inverse
проверка обратных связей
![I - Inverse проверка обратных связей](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/1067021/slide-13.jpg)
Слайд 15C - Cross-check
проверка результат другими методами
![C - Cross-check проверка результат другими методами](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/1067021/slide-14.jpg)
Слайд 16E – Force Error conditions
вызов ошибочных состояний
Типичные ошибочные состояния
Кончилась память
Кончилось место на
![E – Force Error conditions вызов ошибочных состояний Типичные ошибочные состояния Кончилась](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/1067021/slide-15.jpg)
диске
Проблемы с синхронизацией времени
Доступность и ошибки сетей
Система под нагрузкой
Ограниченная цветовая палитра
Высокое/низкое разрешение экрана
Слайд 17P – Performance
параметры производительности
Производительность алгоритма
Скорость выделения ресурсов
Скорость доступа к ресурсам
Время обработки запроса
Потребляемая
![P – Performance параметры производительности Производительность алгоритма Скорость выделения ресурсов Скорость доступа](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/1067021/slide-16.jpg)
память
Слайд 18Свойства хорошего теста
A-TRIP:
Automatic – тесты должны запускаться автоматически и проверять результаты автоматически.
Thorough
![Свойства хорошего теста A-TRIP: Automatic – тесты должны запускаться автоматически и проверять](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/1067021/slide-17.jpg)
– тестируйте все, что может сломаться.
Repeatable –тесты должны запускаться снова и снова, в любом порядке и всегда возвращать одинаковые результаты.
Independent – тесты должны быть независимы (от окружения и друг от друга).
Professional – тест, это код и он должен быть таким же качественным, как и обычный код.
Слайд 19Automatic
Не пишите тесты, которые требуют ввода пользователя
Если метод требует ресурс (базу данных,
![Automatic Не пишите тесты, которые требуют ввода пользователя Если метод требует ресурс](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/1067021/slide-18.jpg)
соединение по сети), сделайте заклушку или мок для тестирования такого метода
Если запуск всех тестов требует длительного времени, то при разработке целесообразно использовать отдельный сервер, который будет запускать такие тесты и рассылать отчеты разработчикам (Continuous Integration)
Слайд 20Thorough (целостность)
Чем больше процент покрытия тестами кода, тем меньше проблем.
Баги имеют свойство
![Thorough (целостность) Чем больше процент покрытия тестами кода, тем меньше проблем. Баги](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/1067021/slide-19.jpg)
группироваться в проблемных местах ? иногда проще и дешевле переписать такие проблемные места с нуля.
Слайд 21Repeatable
Результаты тестов не должны зависеть от чего-то, находящегося под вашим непосредственным контролем
![Repeatable Результаты тестов не должны зависеть от чего-то, находящегося под вашим непосредственным](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/1067021/slide-20.jpg)
(ресурсы, данные из баз данных, внешних систем и т.п.)
Используйте моки и заглушки для изоляции теста от таких систем
Слайд 22Independent
Убедитесь, что вы тестируете только одну вещь одновременно.
Разбивайте сложные операции на несколько
![Independent Убедитесь, что вы тестируете только одну вещь одновременно. Разбивайте сложные операции](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/1067021/slide-21.jpg)
более мелких и тестируйте их независимо.
Некоторая функциональность может иметь несколько тестов, проверяющих различные ее аспекты (например, тест с применением некорректных значений, тест метода обычном режиме для обработки единичных значений, тест для метода в пакетном режие для массовых операций).
Вы не должны зависеть от порядка запуска других тестов.
Слайд 23Professional
Используйте все принципы хорошего дизайна: DRY (Don’t Repeat Yourself), сохраняйте инкапсуляцию, уменьшайте
![Professional Используйте все принципы хорошего дизайна: DRY (Don’t Repeat Yourself), сохраняйте инкапсуляцию,](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/1067021/slide-22.jpg)
связность компонентов.
Не пишите тесты в линейном процедурном стиле, если можно использовать преимущества ООП.
Некоторые связанные методы тестирования можно инкапсулировать в отдельные классы.
Если необходимо, создавайте фреймворки для тестирования.
Не тратьте время на тестирование банальностей (не нужно писать юнит-тесты для get/set-методов).
Хорошее покрытие кода ~1:1 (1 строчка кода к одной строчке теста).
Слайд 24Тестирование тестов
Не тестируйте тесты – чаще всего в этом нет необходимости.
Улучшайте тесты
![Тестирование тестов Не тестируйте тесты – чаще всего в этом нет необходимости.](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/1067021/slide-23.jpg)
по мере исправления багов.
Слайд 25Как исправлять баги
Идентифицировать баг
Написать тест, который «поломается» от этого бага, чтобы подтвердить
![Как исправлять баги Идентифицировать баг Написать тест, который «поломается» от этого бага,](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/1067021/slide-24.jpg)
наличие бага.
Исправить код так, чтобы тест выполнился.
Запустить ВСЕ остальные тесты.
Слайд 27Общие принципы
Тестируйте все, что может сломаться
Тестируйте все, что уже сломалось
Новый код признается
![Общие принципы Тестируйте все, что может сломаться Тестируйте все, что уже сломалось](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/1067021/slide-26.jpg)
виновным, пока не доказана его невиновность.
Тестового кода должно быть как минимум сколько же, сколько и production-кода.
Запускайте юнит-тесты локально при каждой компиляции.
Запускайте все юнит-тесты перед check-in-ом в репозиторий.