Разработка через тестирование (TDD). Артур Аюханов artbear

• Тестирование никогда не доказывает отсутствия ошибок.
  Но наличие тестов – это лучше, чем отсутствие тестов.

Два главных требования тестирования (ОПЫТ):

• Если тестирование не будет автоматизированным, его будет лень делать.
• Если тесты будут выполняться медленно, их опять же лениво делать.

Результаты использования TDD

• Быстрое нахождение ошибок и исправление ошибок
  Тесты до разработки, потом небольшой кусок кода  — проверяется.
  Если тест упал – ошибка в коде из 15-20 строк, не надо искать несколько часов в модуле из 20 экранов.
• Отладка становится очень простой либо вообще не используется
  Я отладку использую очень редко. Потому что у меня все в тестах, как правило. В крайнем случае я пишу отладочные сообщения. Это более эффективно, чем ходить по коду, искать ошибки и т.д.
• Уверенность в качестве ПО
  Видно, что система работает, как проходят тесты. Появляется психологическая уверенность.
• Простота доработки/рефакторинга
• Выбор проектных решений, например, интерфейсов взаимодействий и дизайна программы.
  Тестирование позволяет также заранее принимать проектные решения, т.е. интерфейсы, связи различных модулей, дизайн программ.
  Например, у меня есть задача сделать какую-то выгрузку.
  Сначала делаю тесты, продумываю эту выгрузку. Когда мы пишем тесты, мы фактически продумываем дизайн программы. То есть я не рисую ничего в формах – всё делается в модуле. Продумываю и только потом, когда моя программа проходит все тесты, которые я сам для себя определил, только после этого я рисую форму, в которой использую только нужные мне данные, которые нашел в результате тестов.
  В тестах у меня задан дизайн программы – это очень важно и это на самом деле удобно.
• Разработка через тесты позволяет нам создать слабосвязанные модули.
  Если модули очень сильно связаны между собой, сложно написать хороший тест. Тест не проходит, потому что много связей. Приходится облегчать эти связи, т.е. переписывать код, переписывать тест. Зато в результате мы получаем слабосвязанную программу. И это правильно.
• Еще один важный фактор, про который забывают – это создание документации.
  Очень часто у нас документация не связана с программой, т.е. происходит изменение в программе, документация, как правило, отстает от программы. А тесты всегда соответствуют программе. То есть – тесты выступают как всегда актуальная и доступная документация. То есть, если я возвращаюсь через полгода к проекту, который я выполнил на тестах, я первым делом смотрю в тесты и вижу, как все сделано. Если мне нужно доработать, я уже дорабатываю в соответствии с тестами.

Здесь указаны основные принципы, как надо выполнять разработку через тестирование (TDD).

Принципы (правила) разработки через тестирование

• Основные принципы:
  • Пишите код после теста, который не проходит
  • Пишите тест в объёме = отказ.
  • Пишите код = необходимо для прохождения теста
  • Дублирование Устраняйте.
  • Используйте утверждения для проверки теста
  • Используйте автоматизированную среду запуска тестов
  • Запускайте тесты часто
  • В случае успеха нужна простая «зеленая» полоса. Иногда начинающие пишут много различных сообщений – это путает.
  • Подробные сообщения и «красная» полоса нужны только при отказе теста (для неверных тестов)

Всё просто:

1. Пишем тест, ТОЛЬКО тест, НЕ пишем код. Причем только в том объеме, который нужен для отказа. Потом пишем код, но только в том объеме, который нужен для прохождения теста успешно.
2. Иногда забывают  устранение дублирования. В тесте и в коде не должны быть использованы одинаковые механизмы.
3. Предлагаю использовать всем – Утверждения. Если тест должен проверять какую-то функцию, которая должна возвращать какое-то значение, мы должны проверить это значение и всё. Больше не нужно.
4. Тесты должны запускаться автоматически, поэтому должна быть какая-то среда. Тесты лениииииво запускать вручную.
5. Тесты должны запускаться часто. Если они не будут запускаться часто, мы напишем очень много кода. Напишем много кода – будет много ошибок.

Здесь у меня представлен цикл тестирования. Он очень простой:

TDD — цикл тестирования/кодирования

• Пишем тест. Компилируем. под компиляцией понимается успешное прохождение проверки синтаксиса.
• Запускаем тест. Убеждаемся, что он не проходит в режиме выполнения.
• Пишем код в том объеме, который нужен для успешного срабатывания теста в режиме выполнения.
• Запускаем тест и убеждаемся, что он корректно отработал
• Обязательно выполняем рефакторинг  для «чистоты» кода, устраняем дублирования. Исправляем свой тест, чтобы он стал проще, легче. Исправляем свой код.
• Повторяем последовательность сначала
• Главное — использовать короткие циклы в разработке, чтобы поиск ошибок был наиболее упрощенным

TDD – принципы написания тестов

• Тест должен решать одну задачу
• Тест должен быть изолированным от других тестов
• Тест должен быть относительно быстрым
  • Если тестов много и они работают долго, можно организовать ночную проверку всех тестов. Но это тоже неправильно, потому что проверяться должны все тесты.
  • Не пишем другой код, пока есть отказной тест
    • Иногда приходится пропускать отказные тесты
    • Тест должен подчиняться тем же правилам, что и код
      • Методики разработки
      • Чистый код и т.п.
      • В конце рабочего дня лучше оставить неработающий тест. Это позволит быстро войти в работу на следующий день. Не надо вспоминать, что делали накануне.

Выводы:

• Используйте утверждения для повышения качества кода
• Использование тестирования снижает затраты на разработку и сопровождение
• Тестирование не гарантирует нахождение всех ошибок
• TDD и тестирование повышают надежность ПО и качество системы
• Работа разработчика становится более эффективной
• Работа в режиме TDD приносит больше положительных эмоций
• Вход в TDD не так сложен, как кажется тем, кто не знаком с TDD