Откуда взялись в Google ненадёжные тесты

[pftbest]

А что если тест на самом деле хороший, но код который он тестирует содержит race condition, который проявляется только на этом тесте?

[sshikov]

Или просто неинициализированные данные… а дальше как повезет.

[PositiveAlex]

Это никак не связано с количеством кода теста и оперативной памятью. Это просто отдельная категория тестов. В противном случае, можно было бы говорить о том, что чем длиннее автотест, тем чаще он тестирует race condition, что на мой взгляд, звучит довольно странно.

[aml]

Глючит, в основном, асинхронщина. И чем её больше в тесте, тем больше шансов получить неожиданный результат. Интеграционные веб-тесты — это особенно запущенный случай — в них обычно участвует много компонентов, поэтому они страдают больше других.

[tagir_valeev]

Интересно, есть ли устоявшийся перевод flaky? Мы такие тесты называем "мигающими", а тут "ненадёжные". А ещё кто-нибудь как-нибудь называет?

[PositiveAlex]

В терминологии xunit есть определение «нестабильного теста» (Erratic Test) (разный результат без модификации системы) и «хрупкого теста» (Fragile Test) (постоянно падающий тест после модификаций системы).

[tagir_valeev]

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

Тут непонятно, а что такое "ненадёжный результат". Скажем, произошла регрессия, тест попадал два дня, потом пофиксали регрессию, тест перестал падать. Это явно не flaky. У TeamCity есть четыре эвристики для определения flaky-тестов:

• Частая смена состояния между "падает" и "проходит" в одной и той же билд-конфигурации и/или на одном и том же агенте за определённый период времени (как я понимаю, пороги настраиваются)
• Различный результат для одного и того же коммита, но разных билд-конфигураций (например, под разной OS или на разном железе)
• Различный результат при перезапуске билда без изменений из VCS
• Различный результат при повторном прогоне теста внутри одного билда (например, если задан invocationCount для TestNG-теста)

А что в этой статье имелось в виду?

[PositiveAlex]

Согласен. Там говорится о «той же версии кода» — довольно размыто, потому как у кода есть свои зависимости (сторонние модули) и учитывались ли все зависимости этого кода — вопрос. Кроме того, окружение изолированное или нет. Если нет — то еще один фактор сбоя. Кроме того есть зависимости у самого кода теста и чем больше код теста — тем больше он использует код фреймворка.

Можно увидеть, что чем больше тест — тем больше он затрагивает различных зависимостей как внешних, так и внутренних.

И это естественно, на мой взгляд.