Как провести модульное тестирование чтения в Excel?

Question

У меня есть класс ExcelReader в моем приложении C # - мне нужно импортировать электронные таблицы Excel в таблицы базы данных. Моя проблема в том, что это один из немногих непроверенных классов - я не могу использовать для этого «фиктивный ввод», а тестирование с использованием реальной электронной таблицы Excel делает тест немного медленным (около секунды). Я знаю, что класс работает правильно - я тестировал его вручную - но мне немного неловко оставлять его без собственных тестов.

Итак, мой вопрос: какой из них лучше: никаких юнит-тестов, медленных юнит-тестов или третьего способа, который я не могу понять?

[Редактировать] Множество замечательных ответов, мне очень жаль, я могу отметить только один.

Answer 1

Вы можете обернуть ExcelReader и издеваться над оберткой. Простой пример:

                              +--------------+
                              | {interface}  |
                              | IExcelReader |
                              +--------------+
                                     ^
                                     |
                                     |
+-------------+ 1       1 +--------------------+
| ExcelReader |-----------| ExcelReaderWrapper |
|             |           |                    |
+-------------+           +--------------------+

Таким образом, любой класс, которому нужен фактический ExcelReader, может вместо этого ссылаться на IExcelReader и вводиться с помощью ExcelReaderWrapper или имитацией этого. Это может создать много классов, но выгода заключается в том, что ExcelReader можно заменить, и вам не придется писать медленный интеграционный тест.

Answer 2

Как насчет этого?

ExcelReader --- has --- ExcelInterop (interface) --- to read --- .xls

Я предполагаю, что ExcelReader имеет больше логики, чем вызов функций Excel Interop Library. Если это так, напишите быстрые модульные тесты для ExcelReader, используя временные интервалы в фиктивной реализации ExcelInterop. Вы можете использовать это, чтобы смоделировать / заглушить вызовы в библиотеку взаимодействия.

Далее напишите контрактные тесты для интерфейса ExcelInterop. Объектом теста здесь будет класс-оболочка (реальная реализация интерфейса), которая делегирует фактической сборке взаимодействия MS Excel. Эти тесты должны убедиться, что используемые вами API работают так, как вы ожидаете; запустить это против золотой / ссылки .xls

Пометьте вторую группу тестов атрибутом LongRunning или эквивалентным и выполняйте их реже (на машине сборки / один раз в EOD), если они слишком медленные.

Answer 3

Я бы пошел на медленный тест. Но вы можете сделать это «интеграционным тестом».

Answer 4

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

Answer 5

Обычно модульные тесты не включают файловую систему или базу данных или какой-либо общий ресурс. Тест, который считывает файл из FS и загружает его в БД, обычно называется интеграционным тестом.

Я обычно разделяю интеграционные тесты в отдельную группу, которая может работать медленно (всего несколько минут).

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

Answer 6

У нас также есть большой набор юнит-тестов, касающихся Excel, из опыта хорошо, что они регулярно запускаются без насмешек. Особенно COM-коммуникация немного утомительна и есть ограничения (в зависимости от того, как вы читаете) в размере строк, доступных для записи / чтения из Excel. Я помню кое-что об ограничении в 911 символов, которое я обнаружил при тестировании. Для некоторых очень длинных тестов (> 15 минут) мы добавляем специальный атрибут категории «LongDuration», чтобы они запускались только в ночных сборках.