 |
| Не отменяй меня!! |
Сейчас читаю книгу «Непрерывное развертывание ПО» и там прочитала такой лайфхак:
Неуспешные тесты не должны отменять сборку. В некоторых системах настроено автоматом так, что при неудаче какой-то задачи сборка немедленно завершается. Это почти всегда плохое решение. Если процесс не прерывать, а только отмечать неудачу, то в конце мы увидим, какие задачи провалились.
Проблема возникает вследствие того, что в проектах обычно выполняется много тестовых задач. Например, в тесте фиксации могут присутствовать набор модульных тестов, интеграционные тесты и предварительные дымовые. Если неудача любого завершит сборку, вы не узнаете результатов интеграционных тестов вплоть до следующей регистрации.
Сразу вспомнилось, как у нас как-то настроили так, что при падении теста выводились ошибки только по одному таблице БД. А у нас в одном тесте обычно проверяется штук 5 таблиц... И ошибки могут быть на каждой... И вот я прогоняю автотест, огребаю ошибку на листе 1, исправляю ее, прогоняю снова... Получаю новую ошибку! Снова исправляю, снова прогоняю, снова огребаю... Получается куча времени на отладку одного теста. Ничего, починили ツ
Или другой пример. У нас есть четыре уровня тестов:
- сервисные;
- SOAP;
- Task (задачи);
- MATS (интеграционные);
При сборке в ТС выполняются все, кроме интеграционных (они запускаются отдельно). И вот бывают случаи, когда что-то меняется в билде, что разваливает ВСЕ. Например, добавляется новое поле. Чтобы понять, какие тесты поднимать, проще всего запустить сборку в ТС и посмотреть, что именно падает.
Вот только смотришь в ТС, какие упали сервисные тесты, поднимаешь их, коммитишь, весь такой довольный сидишь, «тесты теперь зеленые будут». А тут облом, все равно развалились. Смотришь почему — сервисные то прошли, только теперь SOAP-ные развалились. Поднимаешь их, следишь за сборкой... И снова облом, ведь есть еще task-тесты. Бесит неимоверно =)
Так что при настройке системы Continuous Integration учтите этот момент. Если упал какой-то тест, выводите полную информацию по падению. И не останавливайте сборку, чтобы тестировщик и разработчик сразу увидел все падения: и сервисные, и soap-ные, и task...
Причем сегодня прочитала этот пример в книге, а потом пошла доделывать лекцию про логи для студентов, а там я ровно то же самое говорю! Про то, что логи не должны выводить по одной ошибке за раз =)
Так что явно пришло время написать этот блог-пост! ツ
Ольга, а в чем определение, смысл и назначение smoke testing?
ОтветитьУдалитьНе в том ли, чтоб не тратить ресурсы на дальнейшее тестирование?
Если ресурс (машинное время, время) ограничен, а он всегда ограничен, и следующий уровень тестов занимает на один-два порядка больше этого ресурса, то сборку нужно именно прерывать.
А еще есть статистика падения тестов, отчего-то мне кажется, что ситуация когда 100 тестов падают по одной причине, на два-три порядка более вероятна, чем когда 10 по разным.
Конечно, лучше экономить время людей, а не машин, но и голову включать не вредно.
Честно говоря, мне сложно представить такую ситуацию, когда на прогон тестов есть минута, но нет 10-30 минут. Тяжеловесные тесты надо уносить отдельно, да. Ну и если все ТАК плохо с ресурсами билд-агентов, то остается только страдать.
УдалитьНо по вашей логике получается, что время как раз придется тратить человеку, а не машине. Когда в проекте тысячи тестов, найти "упавшие 100", пусть даже по одной причине, это сколько времени надо потратить? Намного быстрее прогнать тесты и узнать, какие из них падают и их потом поднимать.
Если "поднял один, подождал, пока упадет второй, поднял второй, подождал, пока упадет третий" — это вообще повеситься можно.
Smoke testing в случае автотестов — это сборка билда БЕЗ тестов. Вот если он вообще не билдится или на чек-стайле падает, тогда да, тесты тоже не пройдут. А если падают тесты, то лучше знать сразу, какие и на чем
Это очень очень хорошая книга! Правда она больше про QA, тестирование там очень мало рассмотрено.
ОтветитьУдалить>>Неуспешные тесты не должны отменять сборку.
Имеется ввиду следующее. Если у вас есть CI и тесты стали его частью, то у вас должны быть четкие критерии для прохождения каждого этапа тестирования.
Например, если сломались модульные тесты ядра, то не стоит продолжать сборку. Слишком много ложных срабатываний. Но если сломались тесты отчетов, то бог с ними с отчетами :)
Вот как раз QA меня и интересует :) Хотя читать книгу бывает тяжеловато, сплошь замудреные термины, чтобы под любой процесс подошло.
УдалитьПо поводу тестов — поэтому авторы и пишут «почти всегда это плохо» :) Я вон тоже привела примеры из практики, когда это ооооочень печально, но да, там именно тесты отчетов уже, не самой сборки
Термины обычные :) QA это ведь про процессы, это про ISO9001, CMMI... И если хочется этим заниматься то надо к ним привыкать.
УдалитьПодобное поведение удлиняет цикл обратной связи - ты не узнаешь что что-то сломал пока не пройдут все тесты. Я бы назвал это антипаттерном, нарушающим одну из основ agile - fail fast. Вместо этого достаточно разбить билд на несколько билдов, каждый из которых будет запускать свои тесты.
ОтветитьУдалить>> А у нас в одном тесте обычно проверяется штук 5 таблиц.
А это - тот же самый антипаттерн, только уже на уровне теста.
Делать 10 тестов на одно действие, чтобы в каждом проверять по 1 таблице? Я бы скорее это антипаттерном назвала, все равно что 100 ручных тест-кейсов написать: шаги одни и те же, но в первый раз мы проверим, что верстка не поехала, во второй посмотрим, что отчет в целом загрузился, в третьем проверим его первую строчку, в четвертом вторую итд... В чем смысл?
УдалитьЗдорово, что ты привела аналогию с ручными тест-кейсами, потому что процесс тестирования, выполняемый человеком и машиной совершенно разный. Основных отличий на мой взгляд 2:
Удалить1. Человеку сложно выполнять одни и те же действия, машине - без разницы. Поэтому человек старается охватить максимальный спектр проверок при прохождении сценариев.
2. При нахождении дефекта, человек может его затем локализировать, машина - нет. Поэтому автотесты должны быть написаны так, чтобы при падении было сразу понятно, где ошибка. В случае с большим числом проверок - придётся лезть в отчёты/код тестов чтобы понять, в каком месте упало и почему.
Ну вот, я о том и говорю — при падении должно быть сразу понятно, где ошибка. По всем таблицам собрать инфу, а не только первое падение. Потому что «машина — нет» скорее относится к локализации унылых ГУИ тестов, а я говорю не о них)
УдалитьИ вот бывают случаи, когда что-то меяется
ОтветитьУдалитьВот только смотришь в ТС, какие упали сервисые
Опечатки в последних словах =)
Исправила, спасибо!
Удалить