Создайте фиктивный запрос, который обработает cffile action = upload

Question

Я пишу функцию загрузки для ColdFusion of Wheels , и мне нужно проверить ее по окончании. Однако у меня проблема в том, что я понятия не имею, как создать в ColdFusion фиктивный пост из нескольких частей, который я могу использовать в своих модульных тестах.

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

Я видел в онлайн-справке ColdFusion , пример создания такого запроса с использованием cfhttp, однако он должен публиковать на другой странице, что побеждает всю эту цель.

Answer 1

Отличный вопрос. Что бы это ни стоило, я внес вклад в MXUnit (написал плагин eclipse), и этот сценарий появился в презентации, которую я сделал на cfobjective в этом году по написанию более простого для тестирования кода (http://mxunit.org/doc/zip/marc_esher_cfobjective_2009_designing_for_easy_testability.zip).

В этом случае я бы посоветовал НЕ проверять загрузку. Я считаю, что мы не должны тратить время на тестирование вещей, которые не являются нашим кодом. Вероятность того, что мы поймаем ошибку или другую странность, достаточно мала, чтобы я мог оправдать ее оставление без проверки. Однако я считаю, что мы должны тестировать «наш» код.

В вашем сценарии у вас есть два поведения: 1) загрузка и 2) поведение после загрузки. Я бы протестировал поведение после загрузки.

Теперь это освобождает ваш модульный тест, чтобы не заботиться об источнике файла. Обратите внимание, как это на самом деле приводит к отделению логики загрузки от "что мне делать с файлом?" логика. В итоге это, по крайней мере, создает потенциал (теоретически) для повторного использования этой логики пост-загрузки для чего-то другого, чем просто загрузка.

Это значительно упрощает ваш тест, потому что теперь вы можете просто протестировать файл, который вы положили где-то в setUp самого модульного теста.

Таким образом, ваш компонент меняется с

<cfffunction name="uploadAndDoStuff">

до

 <cffunction name="upload">  

, а затем

<cffunction name="handleUpload"> 

, или "handleFile", или "doSomethingWithFile", или "processNetworkFile", или что-то другое. и в своем модульном тесте вы оставляете upload () непроверенным и просто проверяете свой обработчик после загрузки. Например, если бы я делал это на работе, и мои требования заключались в следующем: «Загрузить файл; переместить файл в очередь для сканирования на вирусы; создать миниатюры, если изображение или JPG; добавить материал в базу данных и т. Д.», Тогда я бы оставил каждый из них шаги как отдельные функции, и я бы протестировал их изолированно, потому что я знаю, что «загрузить файл» уже работает, так как он работает с CF1.0 (или что-то еще). Имеет смысл?

Еще лучше, полностью исключить «загрузку» из компонента. нет ничего плохого в том, чтобы хранить его в файле CFM, так как нет смысла (насколько я вижу) в попытке его обобщить. в насмешках могут быть преимущества, но это совсем другая тема.

Answer 2

Я быстро выполнил поиск MXUnit, проверяя загрузку формы, и нашел следующую ветку групп Google: Проверка загрузки файла

Это обсуждение между Питером Беллом и Бобом Сильвербергом, результатом которого является то, что тестирование загрузки файла фактически является частью приемочного тестирования, а не модульного теста.

Я знаю, что это не совсем отвечает на ваш вопрос, но я надеюсь, что это поможет.

Answer 3

Строго говоря, вы правы. Если вам нужно выйти из внешнего ресурса, чтобы что-то протестировать (база данных, веб-служба, загрузчик файлов), это не отвечает цели модульного тестирования. Лучший общий совет - смоделировать поведение внешних ресурсов и предположить, что они функционируют или подпадают под действие собственных модульных тестов.

Прагматизм может изменить это, хотя, на базе кода платформы Model-Glue, у нас есть ряд модульных тестов, которые обращаются к внешним ресурсам, например, для сохранения значений во время перенаправления, подключения функциональности AbstractRemotingService и так далее. Они считались достаточно важными функциями для модульного тестирования, и мы решили создать внешние зависимости наших модульных тестов, чтобы обеспечить хорошее покрытие. Ведь в фреймворковом коде НЕ проходят приемочные испытания. Это делается нашими пользователями, и пользователи фреймворка ожидают безупречного кода, как и должны.

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

Дэн Уилсон