Документирование кода. Создание unit-тестов

Документирование кода

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

Отделение интерфейса от реализации

Поскольку некоторые классы могут использовать другие классы, тестирование отдельного класса часто распространяется на связанные с ним. Например, класс пользуется базой данных; в ходе написания теста программист обнаруживает, что тесту приходится взаимодействовать с базой. Это ошибка, поскольку тест не должен выходить за границу класса. В результате разработчик абстрагируется от соединения с базой данных и реализует этот интерфейс, используя свой собственный mock-объект. Это приводит к менее связанному коду, минимизируя зависимости в системе.

Создание unit-тестов

Несовершенное программное решение может оказать колоссальный эффект на генерацию доходов, надежность и репутацию в долгосрочной перспективе. Так, прежде чем доставить ПО клиенту, каждая компания должна гарантировать, что оно работает безупречно и соответствует всем спецификациям и требованиям. Поэтому тестирование уже сейчас становится неотъемлемой и значимой частью жизненного цикла разработки ПО. В этом нам поможет подход TDD (Test Driven Development) — разработка через тестирование.

Основные принципы его применения:

1. прежде чем писать код реализации некой возможности, пишут тест, который позволяет проверить, работает этот будущий код реализации или нет;

2. создают реализацию возможностей и добиваются того, чтобы она успешно прошла тестирование;

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

Наша небольшая простая функция, которую мы будем тестировать, должна всего лишь проверять сложность пароля по следующим правилам:

- количество символов от 8 до 20;

- наличие цифр;

- наличие спецсимволов;

- наличие прописных и строчных букв.

Также нам представлен набор тестовых данных для проверки.

Рисунок 1 – Набора тестовых данных

1. Создаем библиотеку. NET Framework

Рисунок 2 – Создание библиотеки. NetFramework

2. Переименовываем стандартный класс в PasswordChecker

Рисунок 3 – Переименование стандартного класса

3. Затем создаем статичный метод ValidatePassword, а в теле метода пока просто возвращаем True

Рисунок 4 – Создание статического метода

4. Затем создаем тестовый проект для этого метода (правой кнопкой мыши — Createunit-test), где и будем создавать тесты

Рисунок 5 – Создание тестового метода

5. Есть очень хороший подход оформления тестов, который формулируется Arrange-Act-Assert. Суть его заключается в том, чтобы в модульном тесте четко определить:

- предусловие (блок Аrrange) — устанавливает начальные условия для выполнения теста

- действие (блок Act) — выполняет сам тест

- постусловие (блок Assert) — верифицирует результат теста, и, в данном случае, оформление — повышает читаемость текста и облегчает его использование в качестве документации к тестируемой функциональности.

Например, напишем первый тест. Он будет проверять количество символов, где мы разместим блоки Arrange, Act и Assert

Рисунок 6 – Первый тест

Объявляем переменную для установки пароля из тестовых данных

Рисунок 7 – Объявление переменной пароля

Здесь же объявляем ожидаемое значение в результате выполнения теста

Рисунок 8 – Объявление ожидаемого значения

В блоке Act создаем переменную, которая вернет актуальный результат при выполнении метода CheckPassword. В нашем случае ValidatePassword

Рисунок 9 – Переменная для возврата актуального результата

С помощью класса Assert сравниваем два значения: ожидаемое и реальное, метод ArEquel, и в качестве аргумента — наши данные

Рисунок 10 – Сравнение значений с помощью класса Assert

Для проверки результата в классе Assert, помимо ArEquel, определен ряд методов, среди которых можно выделить, например, следующие: All, Matches, Empty, IsTrue, IsNull, Throws и другие.

6. Давайте во втором тестовом методе воспользуемся классом IsFalse в блоке Assert

Рисунок 11 – Использование класса IsFalse

7. Запускаем тесты: на вкладке TestWindows можно открыть обозреватель тестов

Рисунок 12 – Открытие обозревателя тестов

8. С помощью команды Run All можно их запустить

Рисунок 13 – Запуск тестов

9. Так как наша функция всегда возвращает True, первый метод проходит, а второй — нет

Рисунок 14 – Результаты тестирования

10. Обращаем ваше внимание на наименование тестовых методов. Имя теста должно состоять из трех частей:

- имя тестируемого метода;

- сценарий, в котором выполняется тестирование;

- ожидаемое поведение при вызове сценария.

Например, в методе Check_4SymbolsReturnsFalse имя тестируемого метода находится в первой части названия — Check, затем идет сценарий — то, что у нас используется 4 символа, а затем ожидаемое поведение, у нас вернется False.

11. Реализуем все остальные тестовые методы по аналогии, группируя их по требованиям к паролю. Пишем тестовый метод для проверки более чем 20 символов (в данном случае их будет 30)

Рисунок 15 – Реализация остальных тестовых методов

12. Теперь, когда все тесты готовы, самое время приступить к написанию тела метода, проверяющего пароль.

Первым условием проверяем длину

Рисунок 16 – Проверка длины пароля

Запускаем тесты. Как видно, тесты на количество символов 34, 8 прошли

Рисунок 17 – Результаты тестирования

Далее реализуем проверку строчных букв. Два теста на проверку нижнего регистра тоже пройдены

Рисунок 18 – Проверка строчных букв

Затем идет проверка заглавных букв. И они тоже оба пройдены

Рисунок 19 – Проверка заглавных букв

Реализуем проверку цифр. Они тоже пройдены

Рисунок 20 – Проверка на наличие цифр

Реализуем проверку спецсимволов. Метод Intersect будет проверять вхождение спецсимволов в пароле

Рисунок 21 – Проверка на наличие спецсимволов

13. Мы обработали все требования и прошли все тесты

Использованные источники:

1. https: //nationalteam. worldskills. ru/skills/modulnoe-testirovanie-unit-tests/