Обработка модульного тестирования ухудшенного сетевого стека, повреждения файлов и других недостатков

Я в основном программист на C ++, и до сих пор мне удавалось не писать тесты для весь мой код. Я решил, что это плохая идея (тм), после добавления новых функций, которые слегка нарушили старые функции, или, в зависимости от того, как вы хотите на это смотреть, представил некоторые новые «функции»

Но модульное тестирование кажется чрезвычайно хрупким механизмом. Вы можете проверить что-то в «идеальных» условиях, но вы не увидите, как работает ваш код, когда что-то ломается. Например, сканер, скажем, сканирует несколько определенных сайтов для данных X. Вы просто сохраняете образцы страниц, тестируете их и надеетесь, что сайты никогда не изменятся? Это будет нормально работать в качестве регрессионных тестов, но какие тесты вы бы написали, чтобы постоянно проверять эти сайты в реальном времени и сообщать вам, когда приложение не выполняет свою работу, потому что сайт что-то изменил, вызывает сбой вашего приложения? Разве вы не хотите, чтобы ваш набор тестов отслеживал намерение кода?

Приведенный выше пример немного надуман, и я кое-что не заметил. t нарваться (если вы не догадались). Но позволь мне выбрать то, что у меня есть. Как вы тестируете, что приложение будет выполнять свою работу в условиях ухудшенного сетевого стека? То есть, допустим, у вас есть умеренная потеря пакетов по той или иной причине, и у вас есть функция DoSomethingOverTheNetwork () , которая , как предполагается , корректно ухудшается, когда стек не работает. не работает как положено; но так ли это? Разработчик тестирует его лично, намеренно настраивая шлюз, который отбрасывает пакеты для имитации неисправной сети, когда он впервые записывает их. Несколько месяцев спустя кто-то проверяет какой-то код, который что-то тонко модифицирует, поэтому ухудшение не обнаруживается вовремя, или приложение даже не распознает ухудшение, это никогда не обнаруживается, потому что вы можете ' Можно ли запускать подобные тесты в реальном мире с помощью модульных тестов?

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

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

Что делать в вышеуказанных ситуациях? Если модульные тесты не являются ответом, что это такое?

Edit: Я вижу много ответов, в которых говорится «просто смейтесь». Ну, вы не можете "просто поиздеваться", вот почему: Взяв мой пример деградирующего сетевого стека, предположим, что ваша функция имеет четко определенный NetworkInterface, над которым мы будем издеваться. Приложение отправляет пакеты как по TCP, так и по UDP. Теперь, скажем, эй, давайте смоделируем 10% потерю на интерфейсе, используя фиктивный объект, и посмотрим, что произойдет. Ваши TCP-соединения увеличивают количество повторных попыток, а также увеличивают время отката - все это хорошая практика. Вы решаете изменить X% своих UDP-пакетов, чтобы фактически установить TCP-соединение, интерфейс с потерями, мы хотим иметь возможность гарантировать доставку некоторых пакетов, а другие не должны терять слишком много. Работает отлично. Между тем, в реальном мире ... когда вы увеличиваете количество TCP-соединений (или данных по TCP), в соединении с достаточными потерями вы в конечном итоге увеличиваете потери UDP-пакетов, так как ваши TCP-соединения будут в конечном итоге повторно отправлять свои данные все больше и больше и / или уменьшать свое окно, в результате чего ваша 10% потеря пакетов фактически будет больше похожа на потерю 90% пакетов UDP. Уупси.

Ничего особенного, давайте разделим это на UDPInterface и TCPInterface. Подождите ... они взаимозависимы, проверка 10% потерь UDP и 10% потерь TCP ничем не отличается от приведенного выше.

Итак, проблема в том, что теперь вы не просто тестируете свой код, вы вводите свои предположения в способ работы TCP-стека операционной системы. И это плохая идея (тм). Намного худшая идея, чем просто избежать этого полного фиаско.

В какой-то момент вам придется создать Mock OS, которая ведет себя точно так же, как ваша настоящая ОС, за исключением того, что ее можно тестировать. Это не похоже на хороший путь вперед.

Это то, что мы испытали, Я уверен, что другие тоже могут поделиться своим опытом.

Надеюсь, кто-нибудь скажет мне, что я ошибаюсь, и укажет, почему!

Спасибо!