Не так давно я слушал доклад про то, как один автоматизатор развивал свой тестовый фреймворк. Сначала у него был один тип ошибки. Потом ему почему-то захотелось сделать их несколько. Ну, ты знаешь, стандартные логгеры позволяют настраивать разные уровни логгирования - INFO, WARN, ERR… Естественно, лог стал нечитаем из-за большого количества сообщений. Наш коллега был находчив и раскрасил лог: ERR теперь были красненькие, а WARN - жёлтенькие. Потом он решил сделать отчёт в виде HTML и специальным js-ом прятать WARN сообщения. Типа нет красненьких - значит всё ок =). Следи за руками: добавил новый тип ошибок -> доработал лог -> доработал отчёт чтобы прятать эти ошибки! Вот это я понимаю инженерная мысль!
А теперь хорошенько подумай, нужны ли тебе эти самые “некритичные ошибки”? Какой в них смысл, если ты закрываешь на них глаза когда тесты проходят без “критичных ошибок”? Представь себя пилотом самолёта. Приборы перед тобой - это твои тесты. Тебе нужно сказать - готов ли самолёт к взлёту, а перед тобой куча лампочек, некоторые из которых - “некритичны”. Ну там турбина немножко разбалансированна или топливо капает потихоньку (но в целом всё ОК!). Хотел бы ты быть пассажиром в таком самолёте?
А теперь давай посмотрим на состояния теста в junit. Их всего 4: passed, failed, broken, skipped. Видишь тут статус half-failed (или half-passed)? И я не вижу =). Так что вперёд - выкидывай свои некритичные проверки или заменяй их обычными. Ты ведь хочешь, чтобы у тебя были стабильные тесты, которым можно доверять?
comments powered by Disqus