Разработка через тестирование на простом примере

Разработка через тестирование начинается с юнит-тестов, а не с кода. Из части Agile она доросла до самостоятельной дисциплины.

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

Тогда зачем тратить на них время?

Для метода TDD ответ очевиден: сегодняшние вложения в тесты дадут вознаграждение завтра при добавлении новой функциональности и рефакторинге. Метод предлагает писать юнит-тесты перед кодом. Идея появилась в середине 1990-х, а в 2003 опубликовали книгу Экстремальное программирование. Она объясняет понятие непрерывного рефакторинга для улучшения кода продукта.

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

Методология представляет собой структурированную практику. Она позволяет получить чистый код и модифицировать его благодаря совмещению программирования, юнит-тестирования и рефакторинга. У методологии есть три фазы:

• Красная. Код не компилируется? Пишем юнит-тест.
• Зелёная. Реализация пишется в сжатые сроки. Появилось чистое и простое решение? Выполняйте его. В другом случае продукт будет улучшаться пошагово. Главная цель – получить зелёный цвет для юнит-тестов.
• Рефакторинг. Не пренебрегайте данным этапом – он устраняет повторения и вводит возможность изменять архитектуру. Фаза не затрагивает поведение программы.

Три ступени реализуются пятью этапами.

Цикл занимает до 10 минут и повторяется до покрытия функциональности юнит-тестами. Кажется, что всё просто. Однако шаги должны выполняться с предельной строгостью для использования преимуществ методологии. Соблюдайте правила, и получите структурированный код. Продукт будет соответствовать необходимым принципам (KISS -–Keep it simple, stupid) без реализации ненужных функций (DRY – Don’t Repeat Yourself) благодаря непрерывному рефакторингу.

Чистые тесты

TDD – это не чудо, ведущее к оптимальному набору юнит-тестов без усилий. Помните, что в этой практике код продукта и тесты одинаково важны!

Чистый тест соблюдает 5 правил:

• Скорость: он работает быстро для частых запусков.
• Независимость: не зависят друг от друга.
• Повторность:  воспроизводится в любой среде.
• Самопроверка:  возвращает результат (Неудача или Успех) для быстрого и лёгкого заключения.
• Своевременность: пишется в подходящий момент.

Поменяйте мышление

Разработка через тестирование – отдельная парадигма. Во время обучения растут навыки программиста и преимущества подхода. Рассматривайте методику как вклад в будущее. Изменения затрагивают документацию приложения и юнит-тестов, представляющих исполняемые спецификации. Тесты используются для проверки исполнения требований и описывают их. Большую трудность для программиста составляет создание дорожной карты для сложной функциональности в форме запланированных тестов.

Методология обнаруживает баги на ранних стадиях, что снижает затраты на поиск решения. 80% – это минимум покрытия кода серией юнит-тестов. Следовательно, разработчик уверенно приступает к рефакторингу и постоянному улучшению.

Выбирайте правильные инструменты

Eclipse с нативной поддержкой JUnit – явное преимущество. Плагины MoreUnit и Infinitest рекомендуется использовать в управлении юнит-тестами. Последние выполняют тесты при каждом изменении кода автоматически, что упрощает циклы обратной связи – часть непрерывного юнит-тестирования. В повторяющемся цикле методологии, использование шаблонов кода для юнит-тестов экономит время.

Разработка через тестирование в действии

Решим специфичную задачу. Возьмём проблему преобразования арабских чисел в римские.

Сначала напишем класс RomanNumeralTest. Он содержит серии юнит-тестов программы. Первое требование – значение «1» выдаёт римскую «I»:

public class RomanNumeralTest {
   private static RomanNumeral romanNumeral;

   @BeforeClass
   public static void setUpBeforeClass() {
      romanNumeral = new RomanNumeral();
   }

   @Test
   public void testIntToRoman_1_is_I() {
      assertThat(romanNumeral.intToRoman(1), is("I"));
   }
}

При запуске получим ошибку компиляции:

Продолжайте писать код продукта для прохождения теста. Для этого ставим курсор в месторасположение класса RomanNumeral и нажимаем Ctrl+1  – сочетание горячих клавиш Eclipse. Оно предложит быстрое исправление для создания пустого класса RomanNumeral. Аналогичным способом пишем intToRoman – простейший метод, достаточный для возвращения значения «I»:

public class RomanNumeral {
   public String intToRoman(int arabic) {
      return "I";
   }
}

Тест выполнится. Двигайтесь по циклу.

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

@Test
public void testIntToRoman_2_is_II() {
   assertThat(romanNumeral.intToRoman(2), is("II"));
}

Для успешного прохождения измените метод intToRoman класса RomanNumeral:

public String intToRoman(int arabic) {
   if (arabic == 2) return "II";
   return "I"; 
}

Когда получаем зелёный цвет, двигаемся к рефакторингу. Предпочтительно иметь один выход для метода и использовать фигурные скобки для условия if:

public String intToRoman(int arabic) {
   String roman = "I";

   if (arabic == 2){
      roman = "II";
   }

   return roman; 
}

Тесты по-прежнему имеет зелёный цвет успеха. Мы расширяем их дополнительным требованием – числом 3, которое даёт римскую «III». Это делает неудачными текущие юнит-тесты. Для проверки пишем следующее:

public String intToRoman(int arabic) {
   String roman = "I";

   if (arabic == 2){
      roman = "II";
   } else if(arabic == 3) {
      roman = "III";
   }

   return roman; 
}

На шаге рефакторинга код улучшается с помощью цикла. Он уменьшает значения арабских чисел и добавляет полосу римских:

public String intToRoman(int arabic) {
   StringBuilder roman = new StringBuilder();

   while (arabic-- > 0) {
      roman.append("I");
   }

   return roman.toString();
}

Мы обнаруживаем, что алгоритм не поддерживает римскую X. Для этого добавим обработку арабской десятки:

@Test
public void testInToRoman_10_is_X() {
   assertThat(romanNumeral.intToRoman(10), is("X"));
}

Тест выполняется, а рефакторинг не нужен. Значение 10 и его римское представление XX потребуют ещё один тест. Он «сломает» все предыдущие. Пишем следующий код:

public String intToRoman(int arabic) {
   StringBuilder roman = new StringBuilder();

   if (arabic == 10) {
      roman.append("X");
   } else {
      while (arabic-- > 0) {
         roman.append("I");
      }
   }

   return roman.toString();
}

Он пройдёт серию тестов. Фаза рефакторинга позволяет нам вернуться на предыдущий шаг для оптимизации алгоритма преобразования римской X. Заметно, что использование цикла будет эффективнее условий if / else if. Код принимает следующий вид:

public String intToRoman(int arabic) {
   StringBuilder roman = new StringBuilder();

   if (arabic == 10) {
      roman.append("X");
   } else if (arabic == 20) {
      roman.append("XX");
   } else {
      while (arabic-- > 0) {
         roman.append("I");
      }
   }

   return roman.toString();
}

Код успешно пройдёт серию тестов. Фаза рефакторинга позволяет нам вернуться на предыдущий шаг для оптимизации алгоритма преобразования римской X. Заметно, что использование цикла будет эффективнее условий if / else if. В итоге код принимает следующий вид:

public String intToRoman(int arabic) {
   StringBuilder roman = new StringBuilder();

   while (arabic >= 10) {
      roman.append("X");
      arabic -= 10;
   }

   while (arabic-- > 0) {
      roman.append("I");
   }

   return roman.toString();
}

Junit горит зелёным, а рефакторинг не изменил внутренне поведение метода. Рассмотрев код продукта, мы заметим, что задачи для «I» и «X» выполняются одним способом. У нас появилась идея нового дизайна алгоритма: две таблицы, связанные индексами и содержащие римские и арабские цифры соответственно.

public static final int[] ARABIC_DIGITS = {10, 1};
public static final String[] ROMAN_DIGITS = {"X", "I"};

public String intToRoman(int arabic) {
   StringBuilder roman = new StringBuilder();

   for (int i = 0; i < ARABIC_DIGITS.length; i++) {
      while (arabic >= ARABIC_DIGITS[i]) {
         roman.append(ROMAN_DIGITS[i]);
         arabic -= ARABIC_DIGITS[i];
      }
   }

   return roman.toString();
}

С помощью 30 юнит-тест не сломать, поэтому необязательно изменять код продукта. Для чисел 11 и 33, которые образуются римскими цифрами X и I алгоритм также остаётся функциональным. К неудаче в соответствующем юнит-тесте приведёт «V». Пора начинать цикл разработки через тестирование заново! Первое решение – добавить «V» и её арабский эквивалент в таблицы, и проверить алгоритм. Тесты проходят? Тогда это правильное решение. Во время рефакторинга возникает вопрос: не лучше ли заменить две индексированные таблицы на Java Map? Значения упорядочиваются путём двух взаимосвязанных циклов, текущее решение предпочтительнее потому, что оно проще соответствует принципам KISS.

Разработка через тестирование продолжается и мы завершаем серию юнит-тестов.

После 10 шага получаем следующие таблицы:

ARABIC_DIGITS = {1000, 900, 500, 400, 100, 90, 50, 40, 10, 9, 5, 4, 1};
ROMAN_DIGITS = {“M”,”CM”,”D”,”CD”,”C”,”XC”,”L”,”XL”,”X”,”IX”,”V”,”IV”,”I”};

Добавление новых тестов с такими арабскими цифрами, как 1954 и 3949 не потребует никаких изменений метода intToRoman в коде продукта. Серия полученных юнит-тестов покрывает код максимально.

Заключение

Знакомство с разработкой через тестирование показало силу этой практики. Смена парадигмы начинается с обучения и завершается ростом производительности разработчика.

Ещё одно упражнение: добавьте метод обратного преобразования в рассмотренную проблему с римскими и арабскими числами. Используйте разработку через тестирование. Практика – средство прогресса!

Что вы думаете по поводу такого тестирования?