Как делают Вас модульный тест Сервер TCP? Это даже стоит того?

Попробуйте:

ktutil:  add_entry -password -p $user_id@DOMAIN.COM -k 1 -e aes256-cts
Password for $user_id@DOMAIN.COM:
ktutil:  add_entry -password -p $user_id@DOMAIN.COM -k 1 -e aes256-cts
Password for $user_id@DOMAIN.COM:
ktutil:
17
задан Mark Cidade 12 April 2009 в 16:14
поделиться

8 ответов

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

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

9
ответ дан 30 November 2019 в 11:18
поделиться

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

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

17
ответ дан 30 November 2019 в 11:18
поделиться

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

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

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

4
ответ дан 30 November 2019 в 11:18
поделиться

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

4
ответ дан 30 November 2019 в 11:18
поделиться

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

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

2
ответ дан 30 November 2019 в 11:18
поделиться

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

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

2
ответ дан 30 November 2019 в 11:18
поделиться

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

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

2
ответ дан 30 November 2019 в 11:18
поделиться

I can't give you any specific helpers as your question is fairly open-ended.

However it sounds as though you'd want to write a mock server/client depending on your needs. It'd be worth looking at Rhino Mocks.

You might also want to take a look at Oren's NMemCached project which implements a cache server using a custom TCP/IP implementation. That project has some interesting unit/integration tests written using Rhino Mocks.

2
ответ дан 30 November 2019 в 11:18
поделиться
Другие вопросы по тегам:

Похожие вопросы: