Pull to refresh

Comments 10

Есть ненулевая вероятность у этого теста упасть. Это неправильно.

Определять правила соответствия карт комбинации нужно на заданных данных (фикстурах), а не на основе генератора псевдослучайных чисел.
Смею с Вами согласиться, но…
Изначально были созданы также тесты на заданных данных, которые постепенно дополнялись.
Но это подразумевало 100% знание правил расчета «покерной руки», которыми я не владел.
Тест основанный на статистике указал на неточности расчета одной из комбинации.
Разбор этой ситуации позволил найти ошибку, и на основании этого был написан дополнительный тест
уже с фиксированными данными.
Да, как разовый пруф оф концепт — согласен, интересный подход. Но потом такое нужно выпиливать :-)
Да не факт — рандом он тоже помагает.

Но опять же, конечно, не как основной метод.

Да даже с другой стороны — а реальные юзеры это не рандом вообще? Это тот ещё случайный случай.
Тесты должны быть консистентными, потому их запускают в управляемом (или вообще изолированном) окружении.

Результаты тестов не должны изменяться от запуска к запуску.

> Но опять же, конечно, не как основной метод.

Даже как неосновной. Для первоначальной ручной проверки — да. Для последующего автоматического запуска — нет. Научились применять покерные правила к картам — составляйте фикстуры, убирайте рандом.

> Да даже с другой стороны — а реальные юзеры это не рандом вообще? Это тот ещё случайный случай.

Я не совсем понимаю при чём тут это вообще. Я комментировал тестирование, а не эксплуатацию. После того как код отлажен, он должен одинаково предсказуемо работать в тестовом окружении (на основе фикстур) и и продакшне («рандомные» действия пользователей).
В чём суть автотестов? Зачем они нужны?

Для того, чтобы качество повысить и поймать проблемы в коде. ТС как раз и нашёл проблему, которую фикстурами с большой долей вероятности никогда бы не нашёл.

Фикстуры — всего лишь одна из форм, популярнейшая.

Палочки не всегда должны быть попендекулярны.

> Результаты тестов не должны изменяться от запуска к запуску.

Если у нас всё ок с кодом, то результаты и не будут меняться — рандом у нас или «константа».

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

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

В ситуации, о которой идёт речь в посте — будут. В качестве эталонных значений были взяты статистические, а в качестве исходных данных — рандом. Потому, волей случая, тест может падать. Потому этот рандом оставлять нельзя.
А почему он может падать? А, стоп! Сравнивать рандом со стастикой то конечно не есть хорошо.

Я про рандом в исходных данных.

Типа ИКС = рандом от 1 до 20, а ИГРЕК д.б. ИКС * 2.
Хотя когда мы усложняем тесты… Неее, усложнение тестов — нехорошо. Тада понял, отбой.
Угумц.

Хотя лично я и вещи вроде:

> Типа ИКС = рандом от 1 до 20, а ИГРЕК д.б. ИКС * 2.

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

* при портировании из языка А в язык Б
* при разработке экстра-надежных систем

1. Берем тесты из языка А и портируем их. Дополнительно рандомом забиваем в язык А и сравниваем с результатами из языка Б.

2. К примеру мы делаем систему для ракеты. И мы не будем доверять одной группе разработчиков. Это будет две группы и они друг-друга знать не должны. За этим будет у нас ФСБ следить :) Итоги разработки двух групп будет третья тестить на постоянных фикстурах и дополнительно на рандоме. Если где-то одна из разработок группы будет фейлить — пилюли.
Only those users with full accounts are able to leave comments. Log in, please.