Я в основном программист на C ++ и до сих пор обходился без написания тестов для всего моего кода. Я решил, что это плохая идея (тм), после добавления новых функций, которые слегка ломают старые функции, или, в зависимости от того, как вы хотите на это смотреть, добавлены некоторые новые собственные «функции».
Но модульное тестирование представляется чрезвычайно хрупким механизмом. Вы можете проверить что-то в «идеальных» условиях, но вы не видите, как работает ваш код, когда что-то ломается. Например, это сканер, скажем, он сканирует несколько конкретных сайтов для данных X. Вы просто сохраняете образцы страниц, тестируете их и надеетесь, что сайты никогда не изменятся? Это бы хорошо работало как регрессионные тесты, но какие тесты вы бы написали, чтобы постоянно проверять эти сайты live и сообщать вам, когда приложение не выполняет свою работу, потому что сайт что-то изменил, что сейчас вызывает сбой вашего приложения? Разве вы не хотите, чтобы ваш набор тестов отслеживал намерение кода?
Приведенный выше пример немного надуманный, и я не столкнулся с ним (на случай, если вы не догадались). Позвольте мне выбрать то, что у меня есть. Как вы тестируете приложение, которое будет выполнять свою работу перед лицом деградированного сетевого стека? То есть, скажем, у вас умеренная потеря пакетов по той или иной причине, и у вас есть функция DoSomethingOverTheNetwork(), которая предполагается , чтобы изящно ухудшаться, когда стек работает не так, как предполагалось к; но так ли это? Разработчик лично тестирует его, специально настроив шлюз, который отбрасывает пакеты для имитации плохой сети, когда он впервые пишет. Несколько месяцев спустя кто-то проверяет некоторый код, который слегка изменяет что-то, так что ухудшение не обнаруживается во времени, или приложение даже не распознает ухудшение, это никогда не обнаруживается, потому что вы не можете запустить реальный мир такие тесты с использованием модульных тестов, не так ли?
Далее, как насчет повреждения файла? Допустим, вы храните список серверов в файле, и контрольная сумма выглядит хорошо, но данные на самом деле не так. Вы хотите, чтобы код справился с этим, вы пишете код, который, по вашему мнению, делает это. Как вы проверяете, что это делает именно это в течение жизни приложения? Вы можете?
Следовательно, хрупкость. Модульные тесты, кажется, тестируют код только в идеальных условиях (и это продвигается, с фиктивными объектами и тому подобным), а не с тем, с чем они столкнутся в дикой природе. Не поймите меня неправильно, я думаю, что модульные тесты - это хорошо, но набор тестов, состоящий только из них, кажется разумным способом внести незначительные ошибки в ваш код, в то же время чувствуя себя неуверенно в его надежности.
Как мне разрешить вышеуказанные ситуации? Если юнит-тесты не являются ответом, что это такое?
Редактировать: Я вижу много ответов, которые говорят "просто издевайся". Ну, вы не можете "просто высмеять это", вот почему:
Взяв мой пример деградирующего сетевого стека, давайте предположим, что ваша функция имеет четко определенный NetworkInterface, который мы будем издеваться. Приложение отправляет пакеты как по TCP, так и по UDP. Теперь, скажем, эй, давайте смоделируем 10% потерь на интерфейсе, используя фиктивный объект, и посмотрим, что произойдет. Ваши TCP-соединения увеличивают количество попыток повторных попыток, а также увеличивают время отката, что является хорошей практикой. Вы решаете изменить X% своих пакетов UDP, чтобы фактически создать соединение TCP, интерфейс с потерями, мы хотим быть в состоянии гарантировать доставку некоторых пакетов, а другие не должны терять слишком много. Работает отлично. Между тем, в реальном мире ... когда вы увеличиваете количество TCP-соединений (или данных через TCP), при достаточно потерянных соединениях вы в конечном итоге увеличиваете потери пакетов UDP, так как ваши TCP-соединения будут - отправляя их данные все больше и больше и / или уменьшая их окно, в результате чего ваша потеря пакетов в 10% фактически будет больше, чем потеря пакетов UDP в 90% сейчас. Whoopsie.
Не важно, давайте разберем это на UDPInterface и TCPInterface. Подождите минуту ... они взаимозависимы, тестируют 10% потерь UDP и 10% потерь TCP не отличаются от указанных выше.
Итак, проблема в том, что вы не просто тестируете код, а вводите свои предположения в работу стека TCP операционной системы. И это плохая идея (тм). Гораздо худшая идея, чем просто избежать всего этого фиаско.
В какой-то момент вам придется создать Mock OS, которая ведет себя точно так же, как ваша настоящая ОС, за исключением того, что она может быть проверена. Это не похоже на хороший путь вперед.
Это то, что мы испытали, я уверен, что другие тоже могут добавить свой опыт.
Я надеюсь, что кто-то скажет мне, что я очень неправ, и укажет, почему!
Спасибо!