Как вы тестируете модуль TCP-сервера? Это даже стоит того?

Question

Я разрабатываю небольшой TCP-сервер, который будет обрабатывать некоторые пакеты TCP и вести себя по-разному в зависимости от запроса.

Как мне написать модульный тест для этого? Если это действительно сложно написать, стоит ли даже усилий?

Answer 1

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

В любом случае, вы в основном хотите смоделировать сетевую сторону вещей, чтобы вы могли проверить реальную логику, не вовлекая сеть вообще. Тестирование сетевого уровня (то есть тонкой логики между классами сети фреймворка и логикой обработки) может быть немного сложнее, но если вы можете сделать его достаточно тонким, тестировать не так уж и много.

Answer 2

Первое, что нужно сделать, это отделить поведение (я) от входящих пакетов TCP. Абстрагируйте это в диспетчерскую таблицу или другую подобную вещь.

Затем напишите модульные тесты для каждого поведения, независимо от того, как оно было вызвано. Вы можете протестировать окончательный уровень TCP -> поведения с помощью инструмента тестирования, который вы пишете или заимствуете. Этот слой должен быть почти тривиальным, если код корректируется.

Answer 3

Если вы пишете TCP-сервер, вы также должны писать клиентскую библиотеку. Если вы не делаете что-то необычное, вы можете просто запустить пакеты через адаптер обратной связи между модульным тестом и сервером-заглушкой. Вам нужно только проверить, правильно ли вы выполняете TCP с этими тестами, так как остальные тесты должны, в правильном порядке модульного тестирования, заглушить / пропустить логику TCP / сокета и перейти прямо к отдельному тестируемому модулю.

Делать все это полностью стоит. Если вы достаточно новичок в TCP, и вы не знаете, как и зачем его тестировать модулем, есть вероятность, что вы сделаете несколько ошибок / ошибочных предположений о том, как вы пишете свой код TCP, и тесты будут неоценимы для вызова это из Вы также обнаружите, что это побуждает вас уделять больше внимания потребностям клиента, что приводит к более чистому протоколу и более чистой базе кода сервера.

Answer 4

Это того стоит.

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

Вы можете имитировать отправку пакетов TCP с помощью нескольких доступных инструментов. Дайте мне знать, как это происходит.

Answer 5

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

Очевидно, это работает только для HTTP-серверов, но вам стоит написать небольшое приложение, которое может запускать TCP-запросы на вашем сервере и сохранять результаты.

Answer 6

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

Однако звучит так, как будто вы хотите написать фиктивный сервер / клиент в зависимости от ваших потребностей. Стоит посмотреть на Rhino Mocks .

Возможно, вы также захотите взглянуть на проект NMemCached от Oren , который реализует сервер кэширования с использованием собственной реализации TCP / IP. В этом проекте есть несколько интересных модульных / интеграционных тестов, написанных с использованием Rhino Mocks.

Answer 7

Вы можете взглянуть на NMock , библиотеку-насмешку для .NET. Если в юнит-тестировании участвуют две стороны, всегда хорошо просто «высмеять» одну сторону (ту, которую вы не тестируете, в этом случае Клиент).

Однако это потребует некоторых изменений в вашем коде, но поверьте, оно того стоит.

Answer 8

Я ничего не знаю о .net, но могу рассказать вам о модульном тестировании.

Тебе нужно все учитывать. Например, ваш сервер может работать в потоке и выполнять некоторую работу. Где это работает, работа должна быть внутри функции. У вас также, вероятно, есть объект запроса. Заставьте «рабочую функцию» tcp-сервера принять объект запроса в качестве параметра. Затем выполните тестовый модуль как обычно: в начале теста настройте запрос и передайте его «рабочей функции» объекта tcp-сервера. На самом деле сервер не имеет открытых сокетов или чего-либо еще. Вы просто проводите модульное тестирование методов, выполняющих эту работу, и только проверяете обработку запроса. Вы не тестируете сокеты или надежность сети или что-то в этом роде. Вам нужно проверить это по-другому.