Модульное тестирование модуля, проверяющего подключение к Интернету

У меня есть модуль С#, отвечающий за получение списка сетевых адаптеров, которые «подключены к Интернету» на компьютере с Windows Vista. Модуль использует "API диспетчера сетевых списков. " (или NLM API) для перебора всех сетевых подключений и возврата всех тех, для которых значение IsConnectedToInternet равно true.

Я получил несколько предложений по реализации этого модуля в этом ТАК вопрос

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

Альтернативный метод обнаружения, который я выбрал, заключался в попытке подключиться к «www.google.com:80» с помощью TcpClient. Моя проблема: когда у меня есть более одного подключенного адаптера (например, как беспроводного, так и LAN), метод обнаружения не работает для одного из них с ошибкой «Запрос на подключение был сделан на уже подключенном сокете».

Мой вопрос состоит из трех частей:

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

  2. Какую альтернативную логику вы бы предложили? Одна вещь, которая была предложена в вышеупомянутом вопросе, заключалась в просмотре таблицы маршрутизации — как насчет того, чтобы рассматривать каждый адаптер, у которого есть запись маршрутизации с пунктом назначения 0.0.0.0, как «подключенный к Интернету»? Другие предложения?

  3. Вы понимаете, почему я получаю ошибку «уже подключен» с текущей тестовой логикой?


windows networking unit-testing nlm
person Hershi    schedule 12.10.2008    source источник

Ответы (3)


arrow_upward
4
arrow_downward

Я могу только ответить на ваш вопрос о модульном тесте.

Код, который вы тестируете, представляет собой, по вашим словам, «модуль C#, отвечающий за получение списка сетевых адаптеров, которые« подключены к Интернету »на компьютере с Windows Vista. Модуль использует «API диспетчера списка сетей» ( или NLM API) для перебора всех сетевых подключений и возврата всех тех, для которых значение IsConnectedToInternet равно true».

Если бы я писал этот модуль, я бы сначала использовал интерфейс для NLM API, назвав его...NLMAPIService. Теперь для реального кода создайте адаптер, реализующий NLMAPIService и адаптирующий реальный NLM API.

Для тестирования создайте класс FakeNLMAPI, который реализует NLMAPIService и хранит все свои данные где-то в памяти, или в файле XML, или где-то еще. Ваш модуль вызывает методы только в NLMAPIService, поэтому вам не нужно изменять какой-либо «реальный» код в зависимости от того, тестируете вы или нет.

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

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

person moffdub    schedule 12.10.2008

arrow_upward
2
arrow_downward

Внедрение зависимостей — очень удобный шаблон для решения подобных проблем. Вместо того, чтобы просто использовать компоненты API NLM непосредственно в коде, определите интерфейс и класс, который его реализует и служит прокси для API NLM. Передайте экземпляр этого класса вашему модулю в конструкторе и пусть ваш модуль использует его. В ваших модульных тестах вместо реального прокси-объекта используйте фиктивный объект, который возвращает известную информацию — ему даже не нужно ссылаться на NLM API — для использования при тестировании логики вашего модуля. Конечно, ваш прокси-класс также потребует некоторого тестирования, но логика в нем намного проще — возможно, это всего лишь некоторая маршалинг данных. Возможно, вы сможете убедиться в его правильности или, если нет, проведите на нем ручное тестирование, чтобы убедиться, что он работает правильно.

person tvanfosson    schedule 12.10.2008

arrow_upward
0
arrow_downward

UnitTests не должны обращаться к внешним ресурсам. Для UnitTest вашего метода я бы заглушил API Network List Manager.

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

person Kozyarchuk    schedule 12.10.2008