Леонардо да Винчи сказал:
Простота - это величайшая изысканность.
Сегодня мы обнаруживаем диаграмму, которая помогает нам использовать простоту как инструмент, особенно при разработке через тестирование.
T. P. P. означает приоритетную предпосылку трансформации. Имя громкое, но не очень понятное. Чтобы объяснить, для чего предназначена эта техника, нам понадобится небольшой контекст.
Мы говорили о Разработка через тестирование; Если вы знаете эту технику, независимо от того, являетесь ли вы экспертом или только что начали ее использовать, есть один аспект, который вы могли заметить: во время зеленой фазы, на которой мы делаем тест на зеленый мы написали, реализуя минимум, необходимый для прохождения самого теста, у нас есть три возможных стратегии.
Fake It: что означает передачу ответа, которого ожидает тест.
Очевидная реализация: мы реализуем самое простое возможное решение.
Триангуляция: мы используем новый тест и генерируемую им ошибку, чтобы направить нас к более общей реализации.
Здесь обратите внимание: стратегия очевидной реализации действительно непонятна, очень открыта для интерпретации, даже слишком. В то время как два других достаточно ясны, чтобы быть ясными, этот не дает достаточных границ и указаний.
Последовательность изменений
В эту пустоту входит TPP, который состоит из последовательности изменений кода, которые мы можем выполнить, чтобы попытаться создать «очевидную реализацию» в соответствии с требованиями стратегии. Последовательность начинается от самого простого изменения, которое мы можем сделать, до самого сложного, и практическое правило таково: начните с попытки сделать тест зеленым, используя первый тип изменения. Если этого достаточно, напишите следующий тест и попробуйте пройти его с таким же типом изменений. Когда этого уже недостаточно для прохождения теста, переходите к следующему изменению в последовательности.
Подводя итог: придерживайтесь простейших возможных изменений как можно дольше.
Итоговая таблица состоит из 13 видов изменений:
- от без реализации до return nil / null
- от return nil / null до возвращаемой константы
- от возвращаемой константы до константы + (сочетание констант)
- от константы до скаляра (используйте параметры функции, преобразуйте const в var)
- от оператора к операторов (используйте другие команды, кроме RETURN)
- от безусловного до условного (используйте IF или другое условное выражение)
- от скаляра до массива (первый вариант рефакторинга многих IF: поиск по массиву)
- от массива до контейнера (когда массив не подходит или его больше недостаточно, используйте более сложный объект)
- от оператора к хвостовой рекурсии (используйте рекурсию в качестве последней команды)
- от if до цикла (используйте циклы и итерации, предлагаемые языком)
- от оператора к рекурсии (свободно используйте рекурсию)
- от выражения к функции (извлечение сложной логики в методы)
- от переменной до мутации (теперь вы можете изменять свою переменную)
В чем смысл?
Я знаю, о чем вы думаете, мы все это подумали. Скажу прямо сейчас: не воспринимайте эту таблицу TPP буквально.
Таблица - это всего лишь отправная точка для приближения к этапу очевидной реализации, которую необходимо адаптировать к вашему собственному стилю и языку программирования и, в более общем плане, к контексту, в котором мы движемся.
Другими словами, на мой взгляд, эта таблица является попыткой дать стандартный и максимально объективный подход к стратегии, которая оставляет много свободы и, следовательно, много сомнений в том, что это означает «Очевидная реализация ».
На мой взгляд, таблица TPP имеет большое преимущество в том, чтобы прояснить это: на самом деле это означает наиболее тривиальную возможную реализацию, простейшее изменение, которое приводит нас к прохождению теста.
На мой взгляд, это подчеркивает фундаментальный аспект TDD: как можно скорее пройти зеленый тест, даже если реализация вас не удовлетворяет. Как только вы получите ожидаемое поведение с помощью тестов, которые помогут вам, будет легче продумать дизайн и воспользоваться фазой рефакторинга цикла TDD для его постоянного улучшения.
