Теперь Кью работает в режиме чтения

Мы сохранили весь контент, но добавить что-то новое уже нельзя

Как Вы боритесь с тестами Шрёдингера?

Если кому само слово не знакомо, то поясню: на неформальном сленге выражением "Тест Шрёдингера" обозначают Юнит тест, который находится в состоянии суперпозиции. То есть в независимости от количества успешных/провальных запусков Вы не можете гарантировать, что он на самом деле работает или не работает. Вы ничего не можете о нём сказать. Явление может иметь и другие названия, но мне лично известно именно под таким.
Собственно вопрос к тем программистам, которые сталкивались с такими явлениями. Реально интересно, кто как с этим борется?
Это, по сути, опрос мнений. Но выполнен в виде простого вопроса, поскольку я хочу услышать именно мнения, а не получить статистику по выбору из вариантов.
ПрограммированиеМнениеЮнит тесты
Юрий Михайлуц
Юнит тесты
  · 856
Веб-разработчик, геймер, специалист по этике  · 7 окт 2021
Подпись к вопросу, дословно:
Если кому само слово не знакомо, то поясню: на неформальном сленге выражением "Тест Шрёдингера" обозначают Юнит тест, который находится в состоянии суперпозиции. То есть в независимости от количества успешных/провальных запусков Вы не можете гарантировать, что он на самом деле работает или не работает. Вы ничего не можете о нём сказать. Явление может иметь и другие названия, но мне лично известно именно под таким.
Разберём по частям.
Если кому само слово не знакомо, то поясню: на неформальном сленге <...>
За десятилетие профессиональной разработки ПО и целый стеллаж прочитанной профильной литературы на двух языках я ни разу не видел термин "тест Шрёдингера". Я не нашёл этого термина ни на c2 wiki, ни у Мартина Фаулера, ни в Jargon File Эрика Реймонда. У Реймонда есть слово "шрёдинбаг", который не про тест, а про баг, и смысл у него совершенно другой.
Юнит тест, который находится в состоянии суперпозиции
Это будет означать, что он одновременно проваливается и завершается успешно. Такое может случиться, например, если у нашего фреймворка тестирования баг в каком-нибудь из ассертов, и он рапортует неверный результат.
в независимости от количества успешных/провальных запусков Вы не можете гарантировать, что он на самом деле работает или не работает. Вы ничего не можете о нём сказать.
Такой код не называется "юнит тестом" вообще. Например, в своей "Разработке через тестирование" Кент Бек пишет прямым текстом: "Тест — это процедура, которая позволяет либо подтвердить, либо опровергнуть работоспособность кода". (стр. 126 по изданию издательства "Питер" от 2003 года). Если вы запускаете тест и он не говорит вам, работает тестируемый код или нет, это не тест, это просто какой-то левый код.
Собственно вопрос к тем программистам, которые сталкивались с такими явлениями. Реально интересно, кто как с этим борется?
Удалить этот код и написать нормальный тест. Вы, возможно, имеете непродуктивное представление о том, что такое "юнит-тест". Они настолько маленькие и простые, что проще удалить и написать новый, чем разбираться в том, почему он не даёт вам нужной информации.
Учтите, что я отвечаю с позиции того, что любой автоматический тест обязан на 100% контролировать все зависимости кода, которые тестирует, и подразумеваю, что для вас это тоже само собой разумеющееся. Конечно же, самая элементарная причина того, что тесты иногда выполняются, иногда нет - недостаточный контроль над зависимостями кода, которые ещё и ведут себя непредсказуемо.
В xUnit Test Patterns, и в книге, и на сайте, есть раздел под названием Erratic Tests, и последняя из причин такого теста называется Nondeterministic test. Решением проблемы является упрощение теста до такой степени, что он будет полностью предопределённым, что практически дословно повторяет то, что я говорил выше.
Простите, но Вы реально не видите разницы между успешным прохождением теста и реальной работоспособностью того... Читать дальше
@Юрий Михайлуц, так я и говорю вам, что если у вас есть тесты, которые иногда фейлят, иногда проходят, это не какой-то исключительный случай, это просто плохие тесты, так писать нельзя, здесь незачем что-то придумывать новое и переусложнять. Я даю 9 из 10, что в таком случае есть зависимость от чего-то, что не контролируется этапом arrange теста, или есть зависимость от работы другого теста.
В юнит-тестах такого вообще не может быть по определению, каждый такой тест проверяет один конкретный путь выполнения, такое может случайно фейлить только при ошибке аппаратуры. Интеграционные тесты могут так себя вести, когда они слишком сложные или код, который мы тестируем, требует сложной подготовки для изолированного запуска, и мы что-то забыли.
Возможно, решение, которое вы ищете - убедиться, что ваши тесты по-настоящему изолированные, что перед запуском вы полностью контролируете конфигурацию системы и учли её в тексте теста.
Если в Вашем опыте такого не было, то я рад за Вас. Возможно, что Вам не доводилось работать в больших командах. Если же у Вас были такие проблемы, то прошу, всё же, поправить Ваш ответ и рассказать о опыте отлавливания таких проблемных тестов на как можно более ранних этапах.
Так же, если Вы действительно знаете, как такое явление называется по научному, прошу поправить меня. Я с удовольствием добавлю предложенный Вами термин в заголовок вопроса, поскольку это может помочь людям лучше понять о чём же тут речь.
@Юрий Михайлуц, хорошая идея. Я добавил в ответ два абзаца на эту тему.
Разработчик мобильных приложений, Dart/Flutter. Энтузиаст IoT.  · 7 окт 2021
Звучит как необходимость перехода к интеграционному тестированию. Если подумать, то причиной может быть хардкод, который остался незамеченным, ну или тест составлен неправильно, например, моками лишнее переопределено. В мобильной разработке вообще юнит-тесты на два типа делятся - локальные, которые "в песочнице" выполняются, и инструментальные, которые прогоняются на... Читать далее
1 эксперт согласен
Люто бешено плюсую за ответ, основанный на реальном опыте тестирования.
программист  · 15 окт 2021
Если кому само слово не знакомо, то поясню: на неформальном сленге выражением "Тест Шрёдингера" обозначают Юнит тест...
  1. Мне больше знакомо название "гейзенбаг".
  2. По-моему если в вашем тесте завёлся гейзенбаг (который ещё и непонятно как исправлять - судя по вопросу) - то это уже не unit-test. Либо вы тестируете больше одного юнита либо юниты у вас слишком толстые.
Проект слишком жирный. И много старых тестов, которые постепенно приходят в негодность, по мере развития проекта... Читать дальше