Запутался в упаковщиках / адаптерах TDD

Question

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

У меня есть приложение, которое я пытаюсь написать, использующее OpenXML, поэтому оно имеет массу объектов, от которых зависит работа с внешней средой.Я подумал, что было бы неплохо иметь обертки вокруг этих объектов, поэтому я был изолирован от них в случае изменений и т. Д. Моя проблема заключается в том, чтобы представить что-то вроде ячейки, я передаю настоящую ячейку в свою оболочку (так чтоесть что обернуть) в конструкторе.

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

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

В какой-то момент в архитектуре моего приложения мне нужно поговорить со сторонним интерфейсом, и я тестирую этот слой?

Я просто создаю оболочки и не беспокоюсь о части TDDих и просто предположим, что они будут работать, если я пройду через те же запросы и отвечу с теми же ответами, которые ожидают / будут делать фактически обернутые объекты?

Не то, чтобы это имело значение на этом уровне, но я использую c #

спасибо, Нев

Answer 1

Это проблема с кодом интеграции, он не подходит для модульного тестирования.

Выше не означает, что вы должны отказаться от модульного тестирования, только не для кода интеграции.

То, как вы создаете эти обертки, тесно связывает их с внешними объектами. Имхо, это просто перекладывает проблему / перемещает код.

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

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