воскресенье, 9 ноября 2008 г.

XML в качестве DataSource для юнит тестов

Что-то в последнее время я вижу просто невообразимое обилие постов на тему TDD, что не может не радовать :)

Регулярно читая посты одного моего уважаемого коллеги по имени Mike Chaliy обнаружил заметку CSV у якості DataSource.

Вначале хотел оставить комментарий, но потом решил сделать это в виде отдельного поста.

Итак, Mike предпочитает CSV. Он достаточно подробно описал причины его решения, поэтому я решил немного пропиарить формат XML :)

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

На мой взгляд, у CSV формата в качестве источника данных для юнит тестов так же есть несколько недостатков, которые я привожу ниже:

1. Изменение структур данных. Добавляется новое либо удаляется старое поле. Приходится менять CSV документ. Причем придется чуть-чуть поколдовать над загрузкой документа в тот же Excel для того чтобы представить его в табличном виде. После чего нужно отредактировать эту таблицу и опять сохранить в CSV.

В случае с XML можно обойтись банальным Find/Replace в текстовом редакторе. Хотя это конечно дело вкуса. В любом случае нужно помнить об этом, поскольку для кого-то это может быть проблемой.

2. Обработка ошибок чтения. В .NET достаточно бедные средства для того чтобы работать с CSV форматом. С другой стороны, связка XML-файл + XSD-схема + класс-контейнер полученный от XSD.exe + чтение файла с валидацией по схеме выглядит очень привлекательно.

Предположим другой разработчик, меняет функциональность подсистемы. Для этого он должен дополнить CSV-файл новыми данными. Он обновляет документ, и тут бац! Оказывается что он ошибся, поэтому документ не читается. Очень часто потребуется немного поднапрячь свой мозг чтобы понять что же там не так.

Если бы он обновлял XML документ он бы получил довольно внятное объяснение почему документ не может быть загружен.

3. Строгая типизация. Если использовать класс-контейнер, то сериализатор сам будет делать все приведения типов. В случае с CSV тебе придется этот код писать самому.

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


Таким образом, для меня выбор между CSV и XML практически эквивалентен с очень небольшим перевесом в пользу XML ;)

1 комментарий:

Mike Chaliy комментирует...

1) Такой же Find/Replace и для CSV..
2,3) Несовсем понял как это все применимо к атрибуту DataSource, они ничегошеньки не чекает, и типизированного там ничегошеньки нет.. Ну или я чего-то не знаю ;)..

По поводу екселя, тока легкость редактирвоания ;). Для меня это очень было даже актуально, так как тестовые данные у меня всякая фигня со всякими там ковычечками, штмл символами и тому подобным. По поводу версионирования Екселя это тока проблема тулзовин, насколько я знаю ТуторСВН потдерживает дифы для екселевских файолв.

По поводу ХМЛ, даже больше чем теги и атрибуты, меня больше настораживают диффы. ИМХО у ХМЛ с этим значительно хуже чем с КСВ. Плюс проблема вайтспейса, решаемая конешно, но морочиться то приходиться...