В пресловутом подкасте Qaru # 38 Джоэл Спольский рассказал о том, как трудно было бы сделать TDD для чего-то вроде сжатия JPEG. Боб Мартин хотел осветить, как сделать TDD для экземпляра, например, во время подкаста # 41, но я не думаю, что они когда-либо доходили до Это. Таким образом:
Как можно использовать TDD для разработки и тестирования сжатия JPEG?
Вопрос Джоэла был примерно таким. Предположим, вы хотели немного настроить что-то, что привело к отображению изображения с низким разрешением, а не изображения с высоким разрешением. Как бы вы использовали TDD, чтобы заставить это работать? Вы могли бы написать тест, который очищал экран, чтобы показать, что изображение было низким?
Конечно нет. Вы уже знаете, что библиотека JPEG работает. Вы уже знаете, что если вы назовете его правильными аргументами, он будет отображаться с низким разрешением. Что вам нужно проверить, так это то, что бит, который вы установили, преобразуется в соответствующие вызовы в библиотеку JPEG. Таким образом, вы издеваетесь над библиотекой JPEG с помощью очень простого модуля, контролируемого вашим тестом. Затем вы устанавливаете бит и запрашиваете отображение. Библиотека Mocked JPEG будет помнить, как она была вызвана, а затем тест может проверить, чтобы она была вызвана правильно.
ОК, так как бы вы протестировали внутренности библиотеки JPEG? Я не очень много знаю о JPEG-рендеринге, но я предполагаю, что это касается сжатия, декомпрессии и растровых изображений. Сжатие и декомпрессия - это просто алгоритмы. Алгоритмы имеют предсказуемые результаты с заданных входных данных. Таким образом, вы создали серию очень простых входов и убедитесь, что вы получаете прогнозируемые выходы. Вы настраиваете входы так, чтобы внутренняя часть алгоритмов JPEG была покрыта. Такая же логика выполняется для растровых изображений. Вам не нужно отображать их на экране. Простые маленькие растровые изображения могут быть отображены в буферы памяти, которые могут проверяться. Простым я имею в виду ПРОСТО. 3X3, 5X5, 8X8. Просто. Опять же, вы структурируете свои входные данные, чтобы покрыть основную часть кода.
Ничто из этого не представляет собой ракетную науку. Нет, если он совершенен. Но набор из 50 тестов, который показывает, что 90% вашей логики является правильным, может иметь огромное значение, если вы хотите внести изменения.
Можете ли вы полностью исключить ручное тестирование? Конечно нет. Но вы можете значительно смягчить его. Вы можете сократить ручное тестирование до нескольких очень стратегических тестов, а не тысяч утомительных планов испытаний.
Если вы считаете, что TDD означает, что тесты проходят до любого кода или любого дизайна, это в значительной степени невозможно. Для сложных алгоритмов вам нужны некоторые результаты. А в случае сжатия результаты трудно получить вручную. Не невозможно, но сложно.
Кроме того, для сжатия требуется очень высокопроизводительный алгоритм. Просто пройти тест не совсем достаточно. Многие низкопроизводительные алгоритмы могут пройти базовый тест "правильность".
Чтобы выйти за пределы правильности, вам нужны доказательства того, что ваш алгоритм оптимален. Это может быть разработано только за пределами мира тестирования. Вам нужен анализ сложности, используя O (что-то), что не является результатом теста; и он не может быть хорошо определен как результат теста.
Если, с другой стороны, вы считаете, что "тестируемость" подходит к большей части кода, тогда это легко.
Создайте свой алгоритм. Напишите доказательство того, что оно оптимально.
Напишите код, который предоставляет критические фрагменты вашего алгоритма в качестве тестируемых модулей.
В некоторых случаях пишите код для получения результатов теста для общего алгоритма. Это может быть субоптимальный, грубый код, который дает правильный ответ через действительно очевидные, но медленные алгоритмы.
Соберите unittest, чтобы показать, что ваша реализация дает ожидаемые результаты тестирования.
Соберите техническую документацию, чтобы показать, что она также оптимальна.
Это не первый тест. Но это испытание.
Разработка, основанная на испытаниях, - это не только программирование, но и многое другое, что вы можете сделать, сначала используя тест, примеры с приемом tdd и т.д.
Сначала подумайте, как вы хотите, чтобы он себя вел, вот что. Для алгоритма пример может выглядеть примерно так:
Я считаю, что это всего лишь образ жизни, чтобы четко мыслить, чего вы хотите достичь: D