Часть 1

Август 29, 2022

Содержание

2. Что такое Unit-тест Фрагмент кода, написанный разработчиком, для провеки очень маленького, специфичного фрагмента функциональности кода. «
3. Зачем нужно возиться с тестами они делают жизнь проще они делают дизайн приложения лучше они значительно
4. Чего мы добиваемся написанием тестов Ответов на вопросы: Делает ли код то, что ожидает от него
5. Как писать юнит-тесты Ответить на вопрос: как мы будем тестировать новый метод. Написать тест и тестируемый
6. Типичные отговорки Написание тестов занимает слишком много времени Запуск тестов занимает слишком много времени Это не
7. Написание тестов занимает слишком много времени Перед тем, как использовать эту отговорку оцените: Сколько времени вы
8. Написание тестов занимает слишком много времени
9. Что тестировать
10. Структура теста Создать условия, необходимые для тестов (создать объекты, моки, ресурсы и др.) Настроить моки (если
11. Right-BICEP Right – верны ли результаты? B – Boundary верны ли граничные условия? I – Inverse
12. Right верны ли результаты Если результаты выполнения кода верны, то как я об этом узнаю?
13. B – Boundary Проверка граничных условий CORRECT Conformance – верен ли формат значения? Ordering – является
14. I - Inverse проверка обратных связей
15. C - Cross-check проверка результат другими методами
16. E – Force Error conditions вызов ошибочных состояний Типичные ошибочные состояния Кончилась память Кончилось место на
17. P – Performance параметры производительности Производительность алгоритма Скорость выделения ресурсов Скорость доступа к ресурсам Время обработки
18. Свойства хорошего теста A-TRIP: Automatic – тесты должны запускаться автоматически и проверять результаты автоматически. Thorough –
19. Automatic Не пишите тесты, которые требуют ввода пользователя Если метод требует ресурс (базу данных, соединение по
20. Thorough (целостность) Чем больше процент покрытия тестами кода, тем меньше проблем. Баги имеют свойство группироваться в
21. Repeatable Результаты тестов не должны зависеть от чего-то, находящегося под вашим непосредственным контролем (ресурсы, данные из
22. Independent Убедитесь, что вы тестируете только одну вещь одновременно. Разбивайте сложные операции на несколько более мелких
23. Professional Используйте все принципы хорошего дизайна: DRY (Don’t Repeat Yourself), сохраняйте инкапсуляцию, уменьшайте связность компонентов. Не
24. Тестирование тестов Не тестируйте тесты – чаще всего в этом нет необходимости. Улучшайте тесты по мере
25. Как исправлять баги Идентифицировать баг Написать тест, который «поломается» от этого бага, чтобы подтвердить наличие бага.
26. Red-Green-Refactor
27. Подведем итоги
28. Общие принципы Тестируйте все, что может сломаться Тестируйте все, что уже сломалось Новый код признается виновным,
29. Вопросы, которые стоит задавать при написании кода и тестов Если код выполнился правильно, как я об
31. Скачать презентацию

Слайд 2

Что такое Unit-тест
Фрагмент кода, написанный разработчиком, для провеки очень маленького, специфичного

фрагмента функциональности кода.

Слайд 3

Зачем нужно возиться с тестами
они делают жизнь проще
они делают дизайн приложения

лучше
они значительно уменьшают время, затрачиваемое на отладку.

Слайд 4

Чего мы добиваемся написанием тестов
Ответов на вопросы:
Делает ли код то, что

ожидает от него разработчик?
Делает ли он это все время?
Можно ли положиться на код?
Побочные эффекты:
Документирование кода и способов работы с ним

Слайд 5

Как писать юнит-тесты
Ответить на вопрос: как мы будем тестировать новый метод.
Написать

тест и тестируемый класс.
Запустить тест.
Запустить ВСЕ тесты системы.

Слайд 6

Типичные отговорки
Написание тестов занимает слишком много времени
Запуск тестов занимает слишком много

времени
Это не моя работа – тестировать мой код
Я не знаю точно, как код должен работать, поэтому я не могу написать тест
Но он же компилируется!
Мне платят за за написание кода, а не тестов
Я чувствую вину, оставляя QA без работы
Моя компания не позволит запустить юнит-тысты на live-системе

Слайд 7

Написание тестов занимает слишком много времени
Перед тем, как использовать эту отговорку оцените:
Сколько

времени вы тратите на дебаг кода, написанный вами и вашими коллегами
Сколько времени тратится на переработку кода после нахождения крупных багов?
Сколько времени тратится на то, чтобы локализовать обнаруженный баг в коде?

Слайд 8

Написание тестов занимает слишком много времени

Слайд 9

Что тестировать

Слайд 10

Структура теста
Создать условия, необходимые для тестов (создать объекты, моки, ресурсы и

др.)
Настроить моки (если нужно)
Вызвать тестируемый метод
Проверить, что тестируемый метод ведет себя как ожидается
Прибрать за собой (закрыть ресурсы и т.п.)

Слайд 11

Right-BICEP
Right – верны ли результаты?
B – Boundary верны ли граничные условия?
I

– Inverse можно ли проверить обратные связи?
C – Cross-check можно ли проверить результат другими методами?
E – Error conditions можно ли вызвать ошибочные состояния искусственно?
P – Performance удовлетворительна ли производительность?

Слайд 12

Right верны ли результаты
Если результаты выполнения кода верны, то как я об

этом узнаю?

Слайд 13

B – Boundary Проверка граничных условий
CORRECT
Conformance – верен ли формат значения?
Ordering –

является ли правильный набор данных упорядоченным?
Range – лежит ли значение в пределах конкретных минимального и максимального значения?
Reference – ссылается ли код на что-либо внешнее, что не находится под контролем данного кода? Зависит ли от состояния зависимостей, состояние объекта? Зависит ли код от каких-либо условий.
Existence -
Cardinality – количественная проврка результата (нужное ли количество возвращается/используется методами)?
Time – все ли происходит в нужном порядке? В нужное время? В пределах допустимого времени? Правильно ли обрабатываются конкурентные условия?

Слайд 14

I - Inverse проверка обратных связей

Слайд 15

C - Cross-check проверка результат другими методами

Слайд 16

E – Force Error conditions вызов ошибочных состояний
Типичные ошибочные состояния
Кончилась память
Кончилось место

на диске
Проблемы с синхронизацией времени
Доступность и ошибки сетей
Система под нагрузкой
Ограниченная цветовая палитра
Высокое/низкое разрешение экрана

Слайд 17

P – Performance параметры производительности
Производительность алгоритма
Скорость выделения ресурсов
Скорость доступа к ресурсам
Время обработки

запроса
Потребляемая память

Слайд 18

Свойства хорошего теста
A-TRIP:
Automatic – тесты должны запускаться автоматически и проверять результаты

автоматически.
Thorough – тестируйте все, что может сломаться.
Repeatable –тесты должны запускаться снова и снова, в любом порядке и всегда возвращать одинаковые результаты.
Independent – тесты должны быть независимы (от окружения и друг от друга).
Professional – тест, это код и он должен быть таким же качественным, как и обычный код.

Слайд 19

Automatic
Не пишите тесты, которые требуют ввода пользователя
Если метод требует ресурс (базу

данных, соединение по сети), сделайте заклушку или мок для тестирования такого метода
Если запуск всех тестов требует длительного времени, то при разработке целесообразно использовать отдельный сервер, который будет запускать такие тесты и рассылать отчеты разработчикам (Continuous Integration)

Слайд 20

Thorough (целостность)
Чем больше процент покрытия тестами кода, тем меньше проблем.
Баги имеют

свойство группироваться в проблемных местах ? иногда проще и дешевле переписать такие проблемные места с нуля.

Слайд 21

Repeatable
Результаты тестов не должны зависеть от чего-то, находящегося под вашим непосредственным

контролем (ресурсы, данные из баз данных, внешних систем и т.п.)
Используйте моки и заглушки для изоляции теста от таких систем

Слайд 22

Independent
Убедитесь, что вы тестируете только одну вещь одновременно.
Разбивайте сложные операции на

несколько более мелких и тестируйте их независимо.
Некоторая функциональность может иметь несколько тестов, проверяющих различные ее аспекты (например, тест с применением некорректных значений, тест метода обычном режиме для обработки единичных значений, тест для метода в пакетном режие для массовых операций).
Вы не должны зависеть от порядка запуска других тестов.

Слайд 23

Professional
Используйте все принципы хорошего дизайна: DRY (Don’t Repeat Yourself), сохраняйте инкапсуляцию,

уменьшайте связность компонентов.
Не пишите тесты в линейном процедурном стиле, если можно использовать преимущества ООП.
Некоторые связанные методы тестирования можно инкапсулировать в отдельные классы.
Если необходимо, создавайте фреймворки для тестирования.
Не тратьте время на тестирование банальностей (не нужно писать юнит-тесты для get/set-методов).
Хорошее покрытие кода ~1:1 (1 строчка кода к одной строчке теста).

Слайд 24

Тестирование тестов
Не тестируйте тесты – чаще всего в этом нет необходимости.
Улучшайте

тесты по мере исправления багов.

Слайд 25

Как исправлять баги
Идентифицировать баг
Написать тест, который «поломается» от этого бага, чтобы

подтвердить наличие бага.
Исправить код так, чтобы тест выполнился.
Запустить ВСЕ остальные тесты.

Слайд 26

Red-Green-Refactor

Слайд 27

Подведем итоги

Слайд 28

Общие принципы
Тестируйте все, что может сломаться
Тестируйте все, что уже сломалось
Новый код

признается виновным, пока не доказана его невиновность.
Тестового кода должно быть как минимум сколько же, сколько и production-кода.
Запускайте юнит-тесты локально при каждой компиляции.
Запускайте все юнит-тесты перед check-in-ом в репозиторий.

Слайд 29

Вопросы, которые стоит задавать при написании кода и тестов
Если код выполнился

правильно, как я об этом узнаю?
Как я собираютсь тестировать это?
Что еще может пойти не так?
Может ли такая проблема «всплыть» где-нибудь еще?

Часть 1

Содержание

Что такое Unit-тестФрагмент кода, написанный разработчиком, для провеки очень маленького, специфичного

Зачем нужно возиться с тестамиони делают жизнь прощеони делают дизайн приложения

Чего мы добиваемся написанием тестовОтветов на вопросы:Делает ли код то, что

Как писать юнит-тестыОтветить на вопрос: как мы будем тестировать новый метод.Написать

Типичные отговоркиНаписание тестов занимает слишком много времениЗапуск тестов занимает слишком много

Написание тестов занимает слишком много времениПеред тем, как использовать эту отговорку оцените:Сколько

Написание тестов занимает слишком много времени

Что тестировать

Структура тестаСоздать условия, необходимые для тестов (создать объекты, моки, ресурсы и

Right-BICEPRight – верны ли результаты?B – Boundary верны ли граничные условия?I

Right верны ли результатыЕсли результаты выполнения кода верны, то как я об

B – Boundary Проверка граничных условийCORRECTConformance – верен ли формат значения?Ordering –

I - Inverse проверка обратных связей

C - Cross-check проверка результат другими методами

E – Force Error conditions вызов ошибочных состоянийТипичные ошибочные состоянияКончилась памятьКончилось место

P – Performance параметры производительностиПроизводительность алгоритмаСкорость выделения ресурсовСкорость доступа к ресурсамВремя обработки

Свойства хорошего тестаA-TRIP:Automatic – тесты должны запускаться автоматически и проверять результаты

AutomaticНе пишите тесты, которые требуют ввода пользователяЕсли метод требует ресурс (базу

Thorough (целостность)Чем больше процент покрытия тестами кода, тем меньше проблем.Баги имеют

RepeatableРезультаты тестов не должны зависеть от чего-то, находящегося под вашим непосредственным

IndependentУбедитесь, что вы тестируете только одну вещь одновременно.Разбивайте сложные операции на

ProfessionalИспользуйте все принципы хорошего дизайна: DRY (Don’t Repeat Yourself), сохраняйте инкапсуляцию,

Тестирование тестовНе тестируйте тесты – чаще всего в этом нет необходимости.Улучшайте

Как исправлять багиИдентифицировать багНаписать тест, который «поломается» от этого бага, чтобы