Тестирование итеративного кода с использованием макетов - имеет ли смысл, как? - PullRequest
5 голосов
/ 12 сентября 2011

Я хочу проверить алгоритм, используя макеты.Алгоритм - в текущей реализации - перебирает контейнерный класс за несколько проходов и получает из него значения set () и get ().Цель теста - проверить окончательный результат, хранящийся в контейнере.Окончательное значение зависит от значений, прочитанных и записанных между проходами.например, значение любого элемента может изменяться несколько раз, пока алгоритм не будет завершен, и, скорее всего, его значение в результате итерации n будет зависеть от его значения после итерации n-1.

Мне нравится идеяmocks, и я хотел бы использовать их в сценарии, описанном выше, поскольку это позволило бы мне проверить ошибочное поведение алгоритма, как только он произойдет, а не только когда вычисление закончено.Тем не менее, я не уверен, будет ли это хорошей идеей, потому что тогда мне придется привязать ожидания к макету очень близко к текущей реализации (например, «ожидаем, что получим (элемент n) и вернем x, затем установим (элемент n, значение x + 1), другой get (n) и return x + 1, затем ожидаем set (n, x + 2) и т. д. ").

Хотя это позволяет мне проверить, что промежуточные значения соответствуют ожидаемым, я думаю, что такие ожидания будут противоречить цели теста (убедитесь, что алгоритм вычисляет правильное конечное значение) и, скорее всего, тест не пройдёт, если реализация изменится., независимо от правильности конечного значения.

Теперь мой вопрос: я что-то упустил?Тем не менее, есть ли хороший способ использовать насмешки в этом сценарии?или просто не имеет смысла использовать их здесь?Как другие решают эту проблему?

Последнее замечание: я говорю о тестировании кода на c ++ и использовании googlemock, если это как-то влияет на ваш ответ.

ps: я проверил Google истатьи здесь (особенно Насмешливое итеративное поведение - только решает проблему увеличения возвращаемого значения), однако я не нашел ничего близкого к моей проблеме.

Ответы [ 3 ]

3 голосов
/ 12 сентября 2011

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

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

1 голос
/ 12 сентября 2011

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

В противном случае, используя макетэто пустая трата времени.Будете ли вы использовать поддельную версию std::vector?Я бы не стал;это было бы глупо.

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

1 голос
/ 12 сентября 2011

Модульные тесты были бы более применимы к меньшим частям, составляющим алгоритм.

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

Вы правы насчет насмешек, на самом деле вы не слишком много тестируете.Они могут быть полезны, если вы хотите контролировать некоторые из входов, хотя.Много раз я буду переставлять свои входные данные исчерпывающим образом, когда у меня есть черные ящики, которые я не могу контролировать.Такие тесты выполняются слишком долго.Обычно я закомментирую их полностью или частично, когда они перейдут в систему контроля версий.

...