Сжатие TDD и JPEG

Question

В пресловутом Stack Overflow # 38 подкасте Джоэл Спольски рассказал о том, как трудно было бы создать TDD для чего-то вроде сжатия JPEG. Боб Мартин хотел рассказать , как сделать TDD для такого экземпляра, как, например, во время подкаста № 41, но я не думаю, что они когда-либо добирались до него. Таким образом:

Как можно использовать TDD для разработки и тестирования сжатия JPEG?

Answer 1

Вопрос Джоэла был примерно таким. Предположим, вы хотите установить бит где-нибудь, чтобы изображение с низким разрешением отображалось, а не изображение с высоким разрешением. Как бы вы использовали TDD, чтобы заставить это работать? Вы бы написали тест, который поцарапал экран, чтобы показать, что изображение было в низком разрешении?

Конечно нет. Вы уже знаете, что библиотека JPEG работает. Вы уже знаете, что если вы вызовете его с правильными аргументами, он будет отображаться в низком разрешении. Вам нужно проверить, что установленный вами бит преобразуется в соответствующие вызовы библиотеки JPEG. Таким образом, вы макете библиотеку JPEG с очень простым модулем, контролируемым вашим тестом. Затем вы устанавливаете бит и запрашиваете отображение. Библиотека Mocked JPEG запомнит, как она была вызвана, и затем тест сможет проверить, правильно ли она была вызвана.

Хорошо, как бы вы протестировали внутреннее содержимое библиотеки JPEG? Я не знаю много о рендеринге JPEG, но я предполагаю, что речь идет о сжатии, распаковке и растровых изображениях. Сжатие и декомпрессия - это всего лишь алгоритмы. Алгоритмы имеют предсказуемые результаты от заданных входов. Таким образом, вы настроили ряд очень простых входных данных и убедитесь, что получаете предсказуемые выходные данные. Вы настраиваете входы таким образом, чтобы охватить внутреннюю часть алгоритмов JPEG. Та же логика верна для растровых изображений. Вам не нужно отображать их на экране. Простые маленькие растровые изображения могут быть преобразованы в буферы памяти, которые могут проверить тесты. Под простым я имею в виду ПРОСТО. 3X3, 5X5, 8X8. Просто. Опять же, вы структурируете свои входные данные, чтобы покрыть большую часть кода.

Ничто из этого не является ракетостроением. Нет, если это идеально. Но набор из 50 тестов, который показывает, что 90% вашей логики верны, может иметь огромное значение, когда вы хотите внести изменения.

Можете ли вы когда-нибудь полностью исключить ручное тестирование? Конечно, нет. Но вы можете значительно смягчить это. Вы можете сократить ручное тестирование до нескольких очень стратегических тестов, а не до тысяч утомительно утомительных планов тестирования.

Answer 2

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

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

Чтобы выйти за пределы правильности, вам нужны доказательства того, что ваш алгоритм является оптимальным. Это может быть разработано только за пределами мировоззрения тестирования. Вам необходим анализ сложности с использованием O ( что-то ), что не является результатом теста; и при этом это не может быть четко определено как результаты теста.

Если, с другой стороны, вы думаете, что «тестируемость» предшествует большей части кода, тогда это просто.

• Создайте свой алгоритм. Напишите доказательство того, что это оптимально.

• Напишите некоторый код, который представляет критические части вашего алгоритма в качестве тестируемых модулей.

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

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

• Соберите техническую статью, чтобы показать, что она также оптимальна.

Это не первый тест. Но это тест-драйв.

Answer 3

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

Сначала подумайте, как вы хотите, чтобы он себя вел, вот в чем дело. Для алгоритма примером может быть что-то вроде:

• «Необходимо выполнить 5 вызовов за 10 секунд»
• «Размер изображения должен уменьшаться до 10%»
• Другие.

Я считаю, что это только образ жизни, чтобы ясно представлять себе, чего вы хотите достичь: D