Comments 8
А что если тест на самом деле хороший, но код который он тестирует содержит race condition, который проявляется только на этом тесте?
Или просто неинициализированные данные… а дальше как повезет.
Это никак не связано с количеством кода теста и оперативной памятью. Это просто отдельная категория тестов. В противном случае, можно было бы говорить о том, что чем длиннее автотест, тем чаще он тестирует race condition, что на мой взгляд, звучит довольно странно.
Глючит, в основном, асинхронщина. И чем её больше в тесте, тем больше шансов получить неожиданный результат. Интеграционные веб-тесты — это особенно запущенный случай — в них обычно участвует много компонентов, поэтому они страдают больше других.
Интересно, есть ли устоявшийся перевод flaky? Мы такие тесты называем "мигающими", а тут "ненадёжные". А ещё кто-нибудь как-нибудь называет?
Тест считался ненадёжным, если показывал хотя бы один ненадёжный результат в течение недели.
Тут непонятно, а что такое "ненадёжный результат". Скажем, произошла регрессия, тест попадал два дня, потом пофиксали регрессию, тест перестал падать. Это явно не flaky. У TeamCity есть четыре эвристики для определения flaky-тестов:
- Частая смена состояния между "падает" и "проходит" в одной и той же билд-конфигурации и/или на одном и том же агенте за определённый период времени (как я понимаю, пороги настраиваются)
- Различный результат для одного и того же коммита, но разных билд-конфигураций (например, под разной OS или на разном железе)
- Различный результат при перезапуске билда без изменений из VCS
- Различный результат при повторном прогоне теста внутри одного билда (например, если задан invocationCount для TestNG-теста)
А что в этой статье имелось в виду?
Согласен. Там говорится о «той же версии кода» — довольно размыто, потому как у кода есть свои зависимости (сторонние модули) и учитывались ли все зависимости этого кода — вопрос. Кроме того, окружение изолированное или нет. Если нет — то еще один фактор сбоя. Кроме того есть зависимости у самого кода теста и чем больше код теста — тем больше он использует код фреймворка.
Можно увидеть, что чем больше тест — тем больше он затрагивает различных зависимостей как внешних, так и внутренних.
И это естественно, на мой взгляд.
Можно увидеть, что чем больше тест — тем больше он затрагивает различных зависимостей как внешних, так и внутренних.
И это естественно, на мой взгляд.
Sign up to leave a comment.
Откуда взялись в Google ненадёжные тесты