Автоматическое тестирование сторонней библиотеки, которая поддерживает одноэлементное состояние внутри

Question

Мой код использует стороннюю библиотеку, которая использует шаблон синглтона глубоко внутри него.При первом доступе библиотека использует переменные среды Windows для определения папки конфигурации, из которой она загружена.

Однако я хочу запускать разные папки в разных наборах модульных тестов.В идеале я бы указывал папку конфигурации для каждого класса модульного теста или чего-то такого.

Сторонняя библиотека - это огромная объектная модель, и мой код - это просто набор методов расширения поверх них.Я не вижу простого способа макетирования всей библиотеки.

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

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

Это надуманные подходы.Что я действительно хотел бы, так это «очистить» весь домен приложения между тестами, классами тестов или тестовыми сборками.

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

Любые предложения о том, как этого добиться?

РЕДАКТИРОВАТЬ Я только что обнаружил, что различные тестовые сборки приводят к удалению синглетонов.Следовательно, можно организовать тестовые сборки в соответствии с конфигурацией, в которой они выполняются, а не по зависимости или проблемной области, на которые ориентированы тесты.

Answer 1

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

Я не вижу простого способа издеваться над всей библиотекой.

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

Убедитесь, что ваш фасад реализует один или несколько интерфейсов. В общем случае вы хотите, чтобы одна или несколько фабрик возвращали экземпляры конкретных реализаций.

Весь остальной ваш код использует только фасад. Фабрики должны вызываться только в одном месте (или вы можете добавить фабричные интерфейсы); все остальное делается через Внедрение зависимостей .

Для модульного тестирования остальных классов (всего, кроме фасада) вы можете вводить фиктивные объекты.

Ваш код обертки должен быть очень тонким слоем. Вы все еще захотите провести интеграционное тестирование с реальной библиотекой.

Answer 2

Распределение по разным тестовым сборкам.

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

---

Это решение может быть не для всех, хотяпо следующим причинам:

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

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

Другая основная директива модульных тестов заключается в том, что они должны выполняться быстро.К счастью, мне не придется запускать несколько тестовых конфигураций в обычном цикле red-> green-> refactor.Большим набором тестовых сборок будут регрессионные тесты.