Уже не первый раз натыкаюсь на примеры использования случайных тестовых данных, как в наших, так и в зарубежных блогах о тестировании. Казалось бы, что здесь такого? Вроде бы очевидно, что использование случайных тестовых данных “бесплатно” увеличивает тестовое покрытие. Но ты и сам знаешь, где бывает бесплатный сыр, поэтому давай копнём поглубже.
В обсуждении с Игорём в коментах к его посту (не нашёл прямой ссылки на обсуждение в G+, превед, гугл =)), мы пришли к тому, что баги, пойманные с использование случайных данных, являются следствием плохо продуманных сценариев. Поэтому для начала нужно определить, о каких тестах идёт речь - о тестах на новую функциональность или регрессионных.
В первом случае важно поймать как можно больше проблем до момента релиза. И тут использование случайных данных действительно может быть оправдано. Например, если нет времени хорошенько продумать сценарии и покрыть их. Хотя и в этом случае, я бы предпочёл сначала нагенерировать разумный (с точки зрения времени выполнения) объём случайных данных, а затем прогнать тесты на всём множестве полученных данных. Этот вариант хорош тем, что эти данные можно будет использовать затем в регрессии.
В случае с регрессионными тестами, использование случайных данных, на мой взгляд, неразумно. Здесь нам важно удостовериться, что старая функциональность работает так же, как раньше. При использовании рандомных данных, каждый тестовый прогон будет уникальным, а значит не может этого гарантировать. Получается, что регрессионные тесты не выполняют свою основную задачу.
Еще один кейс использования случайных данных - создание уникальных сущностей в системе. По возможности, такой сценарий стоит избегать в регрессионных тестах (лучше удалять созданные тестом сущности). Но если такой возможности нет, я бы предпочёл использовать системную дату/время. По крайней мере, это гарантирует что рандом не выкинет то же самое значение и мы не получим еще один ложно-упавший тест (а их обычно и без этого хватает =)).
А вы используете рандом в тестах? Для чего?
comments powered by Disqus