Случайные данные в модульных тестах?

Question

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

Я привел ему несколько разных причин против этого, главные из которых:

• случайные значения означают, что тест на самом деле не повторяется (что также означает, что если тест может случайно произойти, он может сделать это на сервере сборки и прервать сборку)
• если это случайное значение и проверка не пройдена, нам нужно: а) исправить объект и б) заставить себя каждый раз проверять это значение, поэтому мы знаем, что оно работает, но, поскольку оно случайное, мы не знаем, что значение было

Добавлен еще один сотрудник:

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

Может ли кто-нибудь еще добавить дополнительные причины, которые я могу дать ему, чтобы он прекратил это делать?

(Или, альтернативно, это приемлемый метод написания модульных тестов, а я и мой коллега ошибаемся?)

Answer 1

Можете ли вы сгенерировать случайные данные один раз (я имею в виду ровно один раз, а не один раз за тестовый прогон), а затем использовать их во всех тестах?

Я определенно вижу ценность в создании случайных данных для проверки тех случаев, о которых вы не задумывались, но вы правы, иметь модульные тесты, которые могут случайно пройти или провалиться, плохо.

Answer 2

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

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

Answer 3

Я могу предусмотреть три решения проблемы данных испытаний:

• Тест с фиксированными данными
• Тест со случайными данными
• Генерация случайных данных один раз , а затем использование их в качестве фиксированных данных

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

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

Answer 4

Мы только что столкнулись с этим сегодня. Я хотел псевдослучайный (чтобы он выглядел как сжатые аудиоданные с точки зрения размера). Я TODO, что я также хотел детерминированный . rand () в OSX отличался от Linux. И если я не пересаживаюсь, это может измениться в любое время. Таким образом, мы изменили его, чтобы он был детерминированным, но все еще псевдослучайным: тест повторяется так же, как и использование стандартных данных (но более удобно записанных).

Это было НЕ тестирование некоторой случайной грубой силой через пути кода. В этом разница: все еще детерминированный, все еще повторяемый, все еще использующий данные, которые выглядят как реальный ввод, чтобы выполнить ряд интересных проверок на граничных случаях в сложной логике. Еще юнит тесты.

Это все еще может быть случайным? Давай поговорим за пивом. : -)

Answer 5

Как ваш парень может снова запустить тест, если он не смог увидеть, починил ли он его? То есть он теряет повторяемость испытаний.

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

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

Answer 6

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