Мне никогда не удавалось перейти от модульного тестирования к интеграционному тестированию каким-либо изящным или автоматизированным способом, когда дело касалось сетевого кода.
Итак, мой вопрос: Учитывая простое однопоточное сетевое приложение на основе клиент / сервер, как бы вы поделились с интеграцией клиента и сервера в ваш любимый на данный момент набор для тестирования (в настоящее время я использую контрольный).
Я, конечно, готов изменить набор модульных тестов для достижения своей цели.
Редактировать: Хотя я ценю ответы, я больше искал какой-то волшебный способ интеграции интеграционного тестирования в мою структуру модульного тестирования (если это вообще возможно). Например, если бы можно было применить вилка () или что-то еще, не получив слишком много побочных эффектов.





Мы структурируем наши приложения так, чтобы основной код находился в библиотеке, а исполняемый файл генерировался из файла main.c (в нашем случае - на самом деле main.cxx), который представляет собой очень тонкую оболочку, запускающую сервер или клиент. Это позволяет нам создавать наборы тестов, которые могут создавать экземпляры полного сервера и клиента в процессе и выполнять тесты, в которых они общаются друг с другом, используя свой обычный сетевой протокол. Работает неплохо.
Если вы не можете структурировать вещи таким образом, вы можете запустить свой обычный исполняемый файл сервера с помощью fork / CreateProcess, а затем заставить клиентский код внутри теста разговаривать с внешним сервером.
Другой подход состоит в том, чтобы смоделировать оба конца с помощью фиктивного сервера и фиктивного клиента, которые просто отправляют сообщения, которые вы хотите протестировать, и проверяют, соответствуют ли ответы ожидаемым. Эти макеты серверов могут быть действительно глупыми: им нужно только читать / записывать сокеты и выгружать предварительно установленные данные обратно. Вы можете немного улучшить их, создав шаблоны ответов на данные в запросах, если их легко проанализировать.
Выигрыш здесь в том, что вы точно знаете, что будет делать измышленный элемент (включая фальшивые тайм-ауты, отправку мусора, все, что вы хотите).
Вероятно, было бы очень просто использовать библиотеку сокетов Perl или Python для создания ваших макетов серверов и клиентов; если вы используете Perl, вы должны иметь возможность использовать очень способные Test :: классы из CPAN, чтобы помочь сделать фактическую «сделал эту работу» и составить отчет.
netcat - отличный инструмент для тестирования сетевых серверов и клиентов.
man netcat говорит, что netcat - это швейцарский армейский нож TCP / IP. Имея опыт работы как с netcat, так и с швейцарским армейским ножом Victorinox, я могу заверить вас, что netcat намного лучше, чем Victorinox - я бы предпочел сравнить его с Leatherman.