Имея такое сложное программное обеспечение, каким оно является сегодня, мы можем рассчитывать на ручное тестирование каждой его части. Здесь на помощь приходят модульные тесты.

Один из способов разработки программного обеспечения - сначала написать тесты перед написанием производственного кода. Это называется разработкой через тестирование или TDD.

В этой статье мы подробно рассмотрим, что такое разработка через тестирование и как мы пишем тесты вместе с производственным кодом.

Три закона TDD

Есть 3 принципа TDD:

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

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

Поддержание чистоты тестов

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

Такие вещи, как правильное именование вещей, создание не слишком длинных функций, форматирование и т. Д., - все это применимо к модульным тестам так же, как и к производственному коду. Это упрощает сопровождение тестов, поэтому люди могут перейти к написанию рабочего кода.

Он требует такой же тщательности при проектировании и реализации, как и производственный код.

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

Чистые тесты

Чистые тесты читаемы. Это самая важная часть модульных тестов, потому что мы должны смотреть на них и знать, что они тестируют.

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

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

Двойной стандарт

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

Одно утверждение на тест

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

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

Единая концепция на тест

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

ПЕРВЫЙ

FIRST - это аббревиатура от принципов написания тестов. Каждая буква обозначает один принцип. Вот они:

  • F для быстрого - тесты должны выполняться быстро. Медленные тесты - это пытка, поэтому мы не хотим запускать их часто. Если мы не будем запускать их часто, мы пропустим регрессии, пока не поймем их позже. Кроме того, нам будет менее комфортно вносить изменения в код, поскольку мы не сможем проверить результаты, запустив тесты.
  • I для независимых - тесты не должны зависеть друг от друга. Они не должны создавать условия для следующего теста. Это связано с тем, что, когда один из них выходит из строя, все другие не работают, что затрудняет диагностику.
  • R для повторяемости - тесты должны повторяться в любой среде. Неважно, есть ли у вас сетевое подключение. Таким образом, мы должны поиздеваться над такими вещами. Мы столкнемся с проблемами, когда тесты будут зависеть от внешних ресурсов, которые не всегда доступны.
  • S для самопроверки - тесты должны иметь логический вывод, успешно или нет. Нам не нужно читать журналы, чтобы узнать, прошли ли тесты. В противном случае отказ становится субъективным и требует длительной ручной оценки.
  • T для Своевременного - тесты должны быть написаны своевременно. Они должны быть написаны до производственного кода, чтобы они прошли. Мы можем столкнуться с производственным кодом, который будет трудно протестировать, если мы напишем тесты позже.

Заключение

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

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

Тесты должны выполняться в любой среде одинаково. Им не следует полагаться на внешние ресурсы, которые не всегда доступны.

Результаты теста должны быть пройдены или не пройдены. Это не должно допускать субъективной интерпретации людьми.

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