[БЕЗ_ЗВУКА] Здравствуйте, уважаемые слушатели! Декомпозиция программы на функции, классы и модули позволяет осуществлять модульное, или компонентное, тестирование. Коротко его называют юнит-тестинг. Так вот, юнит-тесты — это способ проверить работу функции или метода отдельно от всей программы вместе взятой. Можно представить себе голову профессора Доуэля, подключенную к аппарату, обеспечивающему ее жизнедеятельность. Рассмотрим пример модульного тестирования. Допустим, в некоторой программе есть функция сортировки массива методом пузырька. Она получает массив в качестве параметра и, пользуясь ссылкой, сортирует его на месте. В программе предусмотрено ее использование, и мы могли бы протестировать ее вручную, но, во-первых, это займет время; во-вторых, это придется делать вручную каждый раз, когда мы захотим узнать, работает функция или нет; а в-третьих, основная часть программы может еще не работать. Что ж, мы можем проверить работу функции отдельно от остального кода да еще и автоматизировать это тестирование. Напишем вот такую тестирующую функцию. Назовем ее юнит-тестом исходной функции. И теперь для проверки нужно только запустить этот юнит-тест. Более того, поскольку автоматизированное тестирование не занимает столько времени, сколько ручное, его можно запускать хоть каждый день, а можно и чаще. Безусловно, для большей гарантии нужно добавить различные тестовые сценарии, тест-кейсы, проверяющие некоторые частные случаи, некоторую выборку, которая убедила бы нас в работоспособности функции. Сколько именно их нужно создать? Можно сказать так, что тест-кейсов много не бывает. Ценность модульного тестирования — в полноте покрытия тестами заявленной функциональности. Ну, конечно, согласно техническому заданию. Теперь о методике разработки, которая помогает наступать на грабли. Да, я не оговорился: именно наступать. Дело в том, что программисту свойственно не замечать своих ошибок. Если он сам пишет себе модульные тесты, написав перед этим код, то он, сам того не желая, проверит только то, что и так работает, а критические случаи в тестах будут отсутствовать. Опережающее тестирование — вот способ совместить роли программиста и тестировщика в одном лице. Прочитав техническое задание на создание функции или метода класса, нужно вначале написать юнит-тест, а потом уже приступать к реализации этих методов. Разработка через тестирование. Test-driven development, или коротко TDD. Это итеративная методика разработки программ, в которой тестирование ставится во главу угла. Конкретно опережающее тестирование. Давайте посмотрим на цикл разработки. Вначале создается тест новой функциональности и запускается. Красная полоса: тест не должен сработать, иначе он написан неправильно. Реализация кода и снова запуск теста. Поправляем код до тех пор, пока тест не выдаст «Окей» и не наступит зеленая полоса. И затем рефакторинг кода. Теперь можно выдохнуть, расслабиться и приукрасить код: мы точно ничего не сломаем — ведь всегда можно проверить его функциональность имеющимся тестом. Почему мы начинаем с написания несрабатывающего теста? Существующие тесты проходят нормально, значит, в коде нет известных проблем. Создав тест для выявления недостающего функционала, мы четко выявляем задачу, которую собираемся решить. И вот такими циклами разработки мы двигаем проект вперед и вперед, создавая новую и новую функциональность программы, которая всегда гарантированно покрыта модульными тестами. Разработка тестов часто выявляет дефекты дизайна приложения. Дело в том, что пока программист пишет тест, он обо многом думает и делает набросок будущей архитектуры. Ему приходится задать себе вопросы: Каковы обязанности тестируемой системы? Что и когда она должна делать? Какой API удобен для того, чтобы тестируемый код выполнял задуманное? Что нужно тестируемой системе для выполнения своих обязательств? Может быть, какие-то данные или другие классы? Что мы имеем на выходе? Какие есть побочные эффекты? Как узнать, что система работает правильно, и достаточно ли хорошо определена эта правильность? Таким образом, мы еще до написания функционала можем осознать, что нужно исправить техническое задание, если оно, конечно, написано плохо. Методика TDD позволяет программисту быть самому себе тестировщиком, добиваясь качественного кода. Это не значит, что работы станет меньше, нет. Работы станет больше: ведь теперь вместо одной функции придется писать две, а вместо одного класса — два класса. Но вот дурной работы, долгой отладки с поиском неуловимых ошибок станет существенно меньше. Спасибо за внимание! [ЗВУК] [БЕЗ_ЗВУКА]
