Однажды кто-то из инженеров-программистов подумал: если я собираюсь написать кучу тестов для этой программы (класса), то почему бы сначала не написать тесты? С тех пор идёт война между сторонниками и противниками этого подхода - что раньше - курица или яйцо (тесты или программы).
Война идёт, а подход сохранился и многими используется. Он называется разработка через тестирование (Test-Driven Development, TDD).
Лично я, например, при разработке программ для компьютера, никогда почти не пишу тесты - все глюки устраняются по мере обнаружения. Несмотря на то, что некоторые мои программы достаточно сложные, сбои в них не ведут к каким-то серьёзным неприятностям - никто не умрёт и не потеряет большие деньги.
Другое дело, когда я разрабатывал системы управления производством. Здесь я этот подход применял часто. И бывало, что на создание тестов у меня уходило больше времени, чем на создание программ (модулей). Потому что там совсем другое дело - сбой в программе может привести к остановке производства, поломке оборудования и даже к человеческим жертвам. И в таких случаях, конечно, надо всё очень тщательно проверить до того, как программа будет запущена в работу.
Но ведь можно было сначала написать программу, а потом - тесты? Да, можно было. Но для отладки в моём случае это было неудобно. Поскольку при разработке программ, управляющих оборудованием, у меня под рукой не было этого оборудования (я не мог разрабатывать ПО непосредственно в цехах на настоящем оборудовании), мне приходилось сначала создавать виртуальные модели этого оборудования, в которых прописывать поведение оборудования. А потом уже писать ПО для управления этим оборудованием и проверять, как всё это работает в разных ситуациях в “виртуальной реальности”.
Красный-зелёный-рефакторинг
У тех, кто использует TDD, есть традиция выполнять три главных шага по ходу разработки после того, как тест будет разработан, которые они называют “красный-зелёный-рефакторинг”:
- Красный - первый шаг, на котором тест должен быть провален. То есть надо создать такие условия, при котором тестирование будет неуспешным. Так вы поймёте, что тест работает.
- Зелёный - второй шаг. На этом шаге создаётся код, который успешно проходит тест. То есть красный переходит в зелёный, провал - в успех.
- Рефакторинг. Теперь, когда у вас есть рабочий код и пройденный тест, можно заняться улучшениями: повысить производительность, написать код более красиво и т.п.
Фишка в том, что если при рефакторинге вы случайно что-то сломаете, то вы это легко обнаружите, потому что у вас уже есть тесты!
А теперь небольшой пример в моей любимой Lazarus. Он слегка притянут за уши ))) Но для понимания общего принципа сгодится.
Итак, допустим у нас есть функция, которая вычисляет процент числа х от числа у. И предположим, что этот процент не должен превышать значение 100. Таким образом у нас могут возникнуть две нештатные ситуации:
- Деление на ноль
- Результат больше 100
Их то нам и надо предусмотреть в тесте. Для начала напишем только прототип функции (ну или её первый вариант). Основное внимание на тест:
Тут сразу понятно, что функция не пройдёт тест. Но в более сложных случаях этого сразу не понять, поэтому и нужны тесты. Итак, мы выполнили первый - красный шаг. Тест провален (точнее, сам тест прошёл успешно - выявил неправильную работу программы, провалена на самом деле проверка работы программы):
Теперь можно переходить к зелёному шагу - сделать рабочий код, который будет проходить тесты:
Ну а рефакторингом можете заняться самостоятельно, если хотите )))
Конечно, это всё не является догмой, и не надо в точности следовать этим инструкциям. Я, например, от любых методик беру только то, что мне нужно здесь и сейчас. И почти всегда это лишь часть какого-то метода. Или комбинация частей из разных методов.
На этом всё. Подписывайтесь на канал, чтобы ничего не пропустить.