Модульное тестирование модуля, который проверяет интернет-соединение

Question

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

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

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

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

У меня три вопроса:

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

Answer 3

UnitTests не должен иметь доступ к внешним ресурсам. Чтобы протестировать ваш метод, я бы заглушил API диспетчера списка сетей.

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