Тестирование / 2 слайд

2 слайд

• Модульное тестирование (unit testing) — тесты, задача которых проверить каждый модуль системы по отдельности. Желательно, чтобы это были минимально делимые кусочки системы

• Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок

3 слайд

1. Модульные тесты позволяют исправить ошибки на ранних этапах разработки и снизить затраты.

2. Это помогает разработчикам лучше понимать кодовую базу проекта и позволяет им быстрее и проще вносить изменения в продукт.

3. Хорошие юнит-тесты служат проектной документацией.

4. Модульные тесты помогают с миграцией кода. Просто переносите код и тесты в новый проект и изменяете код, пока тесты не запустятся снова.

4 слайд

• Unit — модульные тесты, применяемые в различных слоях приложения, тестирующие наименьшую делимую логику приложения: например, класс, но чаще всего — метод. Эти тесты обычно стараются по максимуму изолировать от внешней логики, то есть создать иллюзию того, что остальная часть приложения работает в стандартном режиме.

• Integration — интеграционное тестирование. Оно проверяет более крупные кусочки системы, то есть это либо объединение нескольких кусочков логики (несколько методов или классов), либо корректность работы с внешним компонентом. Этих тестов как правило меньше, чем Unit, так как они тяжеловеснее.

• UI — тесты, которые проверяют работу пользовательского интерфейса. Они затрагивают логику на всех уровнях приложения, из-за чего их еще называют сквозными. Их как правило в разы меньше, так они наиболее тяжеловесны и должны проверять самые необходимые (используемые) пути.

• На рисунке выше мы видим соотношение площадей разных частей треугольника: примерно такая же пропорция сохраняется в количестве этих тестов в реальной работе.

5 слайд

Рассмотрим сначала экстремальные случаи: простой код без зависимостей и сложный код с большим количеством зависимостей. Простой код без зависимостей. Скорее всего здесь и так все ясно. Его можно не тестировать.

Сложный код с большим количеством зависимостей. Хм, если у вас есть такой код, тут пахнет God Object’ом и сильной связностью. Скорее всего, неплохо будет провести рефАкторинг. Мы не станем покрывать этот код юнит-тестами, потому что перепишем его, а значит, у нас изменятся сигнатуры методов и появятся новые классы. Так зачем писать тесты, которые придется выбросить? Что у нас остается: Cложный код без зависимостей. Это некие алгоритмы или бизнес-логика. Отлично, это важные части системы, тестируем их.

Не очень сложный код с зависимостями. Этот код связывает между собой разные компоненты. Тесты важны, чтобы уточнить, как именно должно происходить взаимодействие

6 слайд

TDD (Test-driven development) — разработка через тестирование. В рамках этого подхода в первую очередь пишется тест, который будет проверять определенный код. Получается тестирование чёрного ящика: мы знаем, что есть на входе и знаем, что должно получиться на выходе. Это позволяет избежать дублирования кода. Разработка через тестирование начинается с проектирования и разработки тестов для каждой небольшой функциональности приложения. Основная цель TDD — сделать код более понятным, простым и без ошибок.

• Подход состоит из таких составляющих: Пишем наш тест.

• Запускаем тест, прошел он или нет (видим, что всё красное — не психуем: так и должно быть).

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

• Выполняем рефАкторинг кода.

• Исходя из того, что модульные тесты являются наименьшими элементами в пирамиде автоматизации тестирования, TDD основан на них. С помощью модульных тестов мы можем проверить бизнес-логику любого класса

7 слайд

1. Придерживайтесь единого стиля написания тела теста. Отлично зарекомендовал себя подход AAA (arrange, act, assert) 

2. Тестируйте одну вещь за один раз. Каждый тест должен проверять только одну вещь. Если процесс слишком сложен (например, покупка в интернет магазине), разделите его на несколько частей и протестируйте их отдельно. Если вы не будете придерживаться этого правила, ваши тесты станут нечитаемыми, и вскоре вам окажется очень сложно их поддерживать.

8 слайд

Давайте представим, что нам нужно протестировать автоматическую систему полива. Можно подойти к этой задаче двумя способами:

Тестирование состояния

Запускаем цикл (12 часов). И через 12 часов проверяем, хорошо ли политы растения, достаточно ли воды, каково состояние почвы и т.д.

Тестирование взаимодействия

Установим датчики, которые будут засекать, когда полив начался и закончился, и сколько воды поступило из системы.

Стабы используются при тестировании состояния, а моки – взаимодействия. Лучше использовать не более одного мока на тест. Иначе с высокой вероятностью вы нарушите принцип «тестировать только одну вещь». При этом в одном тесте может быть сколько угодно стабов или же мок и стабы.

____

Главное различие между stubs и mocks заключается в том, что в одном случае мы управляем состоянием, а в другом - поведением.

Когда мы используем mocks, мы заменяем весь модуль на mock (ложный, тестовый объект, имитирующий настоящий). А stub - это функция, которая всегда выводит один и тот же результат, вне зависимости от того, что было подано на вход. Mocks используют для того, чтобы проверить, была ли функция вызвана с правильными аргументами, а stubs, чтобы протестировать, как функция работает с полученным ответом.

9 слайд

Ручной подход к модульному тестированию может использовать пошаговый инструктивный документ.

В рамках автоматизированного подхода

• Разработчик записывает в приложение часть кода, чтобы протестировать функцию. Позже они закомментируют и, наконец, удаляют тестовый код при развертывании приложения.

• Разработчик также может изолировать функцию для более тщательного тестирования. Изоляция кода помогает выявить ненужные зависимости между тестируемым кодом и другими модулями или пространствами данных в продукте.

• Кодер обычно использует UnitTest Framework для разработки автоматизированных тестовых случаев. 

10 слад

1. Junit : Junit — это бесплатный инструмент тестирования, используемый для языка программирования Java. Предоставляет утверждения для определения метода испытаний. Этот инструмент сначала проверяет данные, а затем вставляет их в кусок кода.

2. NUnit : NUnit — широко используемая среда модульного тестирования для всех языков .net. Это инструмент с открытым исходным кодом, который позволяет писать сценарии вручную. Он поддерживает управляемые данными тесты, которые могут выполняться параллельно.

3. JMockit : JMockit — это инструмент модульного тестирования с открытым исходным кодом. Это инструмент покрытия кода с метриками линий и путей. Позволяет имитировать API с синтаксисом записи и проверки. Этот инструмент предлагает покрытие линии, покрытие пути и покрытие данных.

4. EMMA : EMMA — это набор инструментов с открытым исходным кодом для анализа и составления отчетов о коде, написанном на языке Java. Эмма поддерживает типы покрытия, такие как метод, линия, базовый блок. Он основан на Java, поэтому не имеет внешних библиотечных зависимостей и может обращаться к исходному коду.

5. PHPUnit : PHPUnit — это инструмент модульного тестирования для программиста PHP. Он берет небольшие порции кода, называемые модулями, и тестирует каждый из них в отдельности. Этот инструмент также позволяет разработчикам использовать заранее определенные методы утверждений, чтобы утверждать, что система ведет себя определенным образом. 

15 слайд

• Модульные тесты должны быть независимыми. В случае каких-либо улучшений или изменений в требованиях, тестовые случаи не должны быть затронуты.

• Тестируйте только один код за раз.

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

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

16 слайд

Разработчики, желающие узнать, какие функциональные возможности предоставляет модуль и как его использовать, могут взглянуть на модульные тесты, чтобы получить общее представление о API модуля.

Модульное тестирование позволяет программисту выполнить рефакторинг кода позднее и убедиться, что модуль по-прежнему работает правильно. Процедура заключается в написании контрольных примеров для всех функций и методов, чтобы в случае, если изменение вызвало ошибку, его можно было быстро идентифицировать и исправить.

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

17 слайд

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

Модульное тестирование по своей природе ориентировано на единицу кода. Следовательно, он не может отловить ошибки интеграции или ошибки системного уровня.

Рекомендуется использовать модульное тестирование в сочетании с другими видами тестирования.

18 слайд

Миф: Это требует времени, и я всегда overscheduled Моего кода скала! Мне не нужны юнит-тесты.

Правда юнит-тестирование увеличивает скорость разработки.

Программисты думают, что Integration Testing перехватит все ошибки и не выполнит модульный тест Как только модули интегрированы, очень простые ошибки, которые можно очень легко найти и исправить в тестируемом модуле, занимают очень много времени для отслеживания и исправления.