Перезапуск тестов

Время от времени различные уважаемые люди и конторы озвучивают довольно странную для меня мысль - "если тест упал, то запусти его второй раз, вдруг не упадет". Эдакий способ экономить время на разборе результатов тестов. Примерно в этом месте я вижу чудовищную логическую дыру. И, чтобы не спорить с ветряными мельницами в виде выдранных из контекста аргументов в пользу перезапуска тестов, я просто изложу свою точку зрения.

У автоматического теста есть всего один полезный выхлоп - падение теста. Все остальное время автоматические тесты просто греют воздух укрепляя в нас уверенность в нашем продукте (не всегда обоснованную, но это другая история). Это нагревание воздуха, безусловно, полезно для процесса и так далее, но большую часть времени никакой полезной информации не несет. Примерно как ребята в аэропортах, которые могут каждый год рапортовать, что в 100500 проверенных за год пар обуви ни одной бомбы не обнаружено. Работа, безусловно, полезная, но самое крутое что они могут сделать - это, как ни странно, исполнить свое предназначение и найти уже наконец эту чертову бомбу в этих чертовых ботинках. И перезапуск теста это примерно как "ой, кажется у вас в ботинках бомба, пройдите, пожалуйста, повторный досмотр - вдруг мы ошиблись?".

Но у подобных проверок есть ряд концептуальных проблем дизайна. Например, там могут быть ложные "тест прошел" и ложные "тест упал". Первые отлавливать крайне сложно - вы не можете себе позволить перепроверять сотни и тысячи автоматических тестов - теряется весь смысл. Вторые проверяются банальным анализом полученного выхлопа. И перезапуск упавших тестов приводит к увеличению ложных "тест прошел". Да, вы, возможно, спасете себе кучу времени на разгребании ложных падений, но это экономия ставит под сомнение самый полезный результат тестов.

И что же означает это падение тестов? Обычно причины две:

1. Баги в продукте
2. Нестабильные тесты/Баги в тестах/Нестабильное тестовое окружение

Второе в одной группе, т.к. это, как правило, и является основным объяснением перезапуска тестов. И если мы начинаем перекладывать падение наших тестов на второй пункт, то мы попадаем в страну, где хреновые тесты - это норма, и где-то прячутся баги, которые мы могли бы найти раньше (и мы их, возможно, нашли, но успешно проигнорировали).

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

Да, я понимаю, что у всех своя специфика, уникальный внутренний мир проекта, сроки горят, начальство негодует и KPI не выполняется. Все это может заставить вас игнорировать какие-то упавшие тесты. Как правило это просто пустые отмазки. Как правило, но далеко не всегда.  Но тем не менее не позволяйте нестабильным, хреново написанным тестам становиться нормой. Не делайте нормой нестабильное тестовое окружение. Это все инженерные задачи - они решаются (не всегда легко, но тем не менее решаются). Если, конечно, суть вашей работы не заключается в том, чтобы демонстрировать пару тысяч зеленых квадратиков on commit.

Грешки Автоматизатора. Часть 4. Выбор языка

Я как-то давно обещал написать по этому поводу пару строк - исполняю.

Еще ни один стартап не умирал из-за того, что выбрал неправильный дистрибутив Linux - Пол Хаммонд

Да-да. Все именно так. Не имеет абсолютно никакого значения какой язык вы выберете для написания автоматических тестов, если вы вообще взялись этот самый язык выбирать.

Да, иногда мы привязаны к инструментам, которые не дают нам писать на некоторых языках. Но это, как правило, проприетарные инструменты для тестирования веб-морды. Да даже у них, как правило (не смотрим на MS), выбор языков на которых ожно писать довольно широкий.
Да, под разные инструменты/области автоматизации на разных языках разное количество готовых ништяков. Только все равно всеми вы никогда пользоваться не будете, хотя бы потому, что знать их все в наше время практически невозможно, а возникают они быстрее, чем грибы после дождя.
Да, у вас могут быть разработчики, которые знают хорошо какие-то весьма конкретные языки. Но тут тоже куча ньюансов. Во-первых, тесты писать вам, а не им. Во-вторых, если вы очень надеетесь, что они будут вас активно всему этому обучать - вы несколько переоцениваете количество свободного времени у них, и недооцениваете количество времени, которое вам придется потратить на написание. Большую часть изучения деталей вам придется сделать самим.

Можно продолжать еще долго, но суть останется прежней. Попытка обосновать подобными вещами выбор языка это такое же шарлатанство, как и подсчет ROI, автоматизации или прогнозирование цен на нефть на 30 лет вперед.

Собственно главный критерий один - как хорошо лично вы знаете тот или иной язык. Все.

В случаях, когда у вас какие-то корпоративные стандарты - вопрос вообще не должен возникать. Если вы планируете тотальное переиспользование кода приложения - тоже.

Наличие API или хелперов в количестве на том или ином языке - странный аргумент. REST API? Нет вопросов вообще. Хелперы и хуки автоматизации? Если они написаны нормально, то проблем с вызовом быть не должно.

Вы не знаете никаких языков? Учите то, что проще учить - Ruby, Python (это просто пара примеров). Учить Java или еще какие C++ - это путь самурая, но не тот случай когда вам нужно как можно быстрее выучить необходимый минимум (а автоматизация - довольно узкая область, там нужен довольно ограниченный набор) для написания автоматических тестов и тестовой инфраструктуры. Да, какие-то языки было бы неплохо подучить, чтобы набить себе резюме, но это вообще не имеет отношения к выполнению задачи.

Роботу роботово

Without changing our pattern of thought, we will not be able to solve the problems we created with our current patterns of thought

А. Эйнштейн

У нас в тестировании есть волшебный баззворд - автоматизация. В клиническом случае технически подкованное не в тех областях (или вообще никак не подкованное) начальство хочет чтобы тестировщики автоматизировали все настолько, чтобы от них, тестировщиков, потом можно было избавиться (нуачо, долго, ошибаются и вообще agile manifesto не для взрослых дядек они и так сами все знают). И собирают при этом стандартный набор граблей. Но я не буду в этот раз писать про когнитивные искажения, которые по факту приводят к тому, что рациональные и умные люди принимают очень странные и по факту ничем не обоснованные кроме собственных фантазий решения. Про это уже было написано очень много и давно. Достаточно откопать обычную для уважающего себя тестировщика матчасть и перечитать разок-другой.

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

Для простоты будем разбирать простейший случай из автоматизации GUI-тестов. Потому что другой автоматизации не существует и чоткие тестировщики тестируют сложные веб-приложения только через GUI и какие-то unit-тесты которые вообще хз кто пишет. Дао этой странной комбинации мне непостижимо, так что во избежание глупых споров с адептами такого подхода будем считать его расово верным.

Идея проста как валенок, и в наше время может прийти даже дворнику в пьяном угаре - пишем сотни GUI тестов (их почему-то последнее время принято называть "интеграционными"), и с какой-то регулярностью запускаем их в CI. Выхлоп тоже очевиден - быстрая обратная связь (от 20 минут до суток), и робот который все ловит и никогда не ошибается. В идеале все это отлично поддерживается, но это уже упирается в крутость наших писателей автоматических тестов, которые, напоминаю, при благоприятном стечении обстоятельств должны в результате этой деятельности остаться без работы.

И как это все обычно делается? Ну мы, "как настоящий пользователь" жмакаем через какой-нибудь Selenium кнопочки и линочки, и все магическим образом проверяется. Выглядит это обычно как-то так:

Т.е. получаем "быстрый тест, который избавлен от человеческого фактора". Переводя с птичьего на человечий:

• Тест, который совершает дофига телодвижений в браузере, что само по себе медленно даже если мы быстрый HTTP-клиент на коленке сделаем. Это все быстрее, чем это будет делать человек, но для тысяч тестов это все еще очень медленно.
• Тест, который совершает дофига лишних телодвижений в браузере - куча дополнительных проверок, куча дополнительных рисков того, что тест свалится из-за всякой ерунды. И да - когда он начнет валиться в браузере это все будет еще медленнее.

Т.е. по факту такой дизайн теста нифига не приводит к ускорению и будет содержать в себе кучу мест, где он рискует свалиться так и не добравшись до реальной цели. Все это, кстати, совсем не помогает поддерживать тысячи таких тестов быстро и непринужденно (даже если там будут ваши блестящие Page Objects).

Короче говоря - тест этот говно полное, а не тест.

Что мы можем сделать чтобы он перестал быть говном?

• Убрать лишние телодвижения
• Никаких сетапов в браузере (мелкий кусок API или хелпер на "создать псто" и мы уже сэкономили кучу сил и энергии)
• Никакой лишней навигации (хелперы/API на логин и переход к псто... да хоть директ линком в псто)
• Никаких тестов с сотнями проверок (в идеале один тест - один ассерт)
• Никаких трешевых тестов
• CRUD - ок
• Дешевые проверки на безопасность - ок
• Основной функционал - ок
• Выдирание алайнов элементов страницы и их стилей - в другой набор тестов пожалуйста
• И т.д.

Да, возможно в вашем конкретном случае это будет не реализуемо, потому что никто вам не даст никаких клевых API, никто вас не снабдит классными хелперами забирающимися в потроха приложения. Но не отчаивайтесь - дерьмовое testability в наше время в порядке вещей. А отсутствие хороших хуков в приложение, легкости конфигурирования и смены состояний приложения это оно и есть. Для примера можете попробовать автоматически протестировать мало-мальски сложное мобильное приложение (лучше сразу на symbian чтобы жизнь медом не казалась) - после веба ощущения как-будто вам обе руки отрезали. Тестирование веб-приложения с плохим testability после того как вам показали хорошее - точно те же ощущения. Получается эдакий технический долг перед тестировщиками с которым ваши тестировщики будут жить вечно.

Есть и другие причины почему мы можем писать плохие тесты. В них тоже никакой катастрофы нет, пока вы понимаете почему именно, и какие именно тесты плохие.

Вместо послесловия

Выше приведен лишь маленький шаблон, который в принципе может помочь получить быстрые и четкие проверки. Там можно еще оптимизировать с локаторами (перевести на CSS), распараллелить, DRY, рефакторинг, вовлечь ваших разработчиков в процесс (фу ересь какая так не бывает)...

Иногда нам хочется более хитрых тестов. Например тесты на workflow с хитровывернутыми циклами и сотнями проверок внутри. Или проверка навигации. В этих тестах нет ничего страшного, просто их дизайн будет отличаться от дизайна тестов для быстрой обратной связи, и их не всегда стоит пытаться впендюрить в один большой прогон на CI по каждому чиху.

Более того - можно писать полу-автоматические тесты или всякие BVT. Там тоже свои критерии корректности влияющие на дизайн, но это уже другая история...

Грешки Автоматизатора. Часть 3. Xpath головного мозга

На этот раз пишу с привязкой к инструменту. И инструмент этот (СЮРПРИЗ!!!) - Selenium-WebDriver (дальше просто Selenium или Se).

Так вот, в selenium есть одна большая и неутихающая головная боль - локаторы элементов. Головная боль, если задуматься, довольно древняя и растет из того, что текущие (да и прошлые, чего греха таить) биндинги никак не располагают к тому, чтобы:

• Задать много идентификаторов для одного элемента
• Использовать все возможные идентификаторы тегов (title, например)
• Обращаться напрямую к индексу элемента
• Различать элементы по типам (привет findElement!)

Одной невозможности обращаться к элементу по его имени (title) и по индексу уже достаточно чтобы плакать кровавыми слезами.

Но тут нам на помощь приходят два друга - xpath- и css-локаторы. Они умеют все это и даже больше. Причем если в прошлом был только xpath, то сейчас есть клевый и сочный css.

Я долго думал почему же css-локаторы лучше чем xpath, но в итоге не придумал ни одного железобетонного аргумента.

Я мог бы сказать, что CSS лучше уже тем, что он быстрее чем xpath. Но многим автоматизаторам (особенно начинающим) в принципе плевать насколько быстро выполняется скрипт. Им вообще до оптимизации автоматических тестов дела нет - лишь бы работал хоть как-нибудь.

Я мог бы сказать, что CSS читабельней чем xpath. Но это вкусовщина. Если человек привык писать //div[@id='eid'], то div#eid для него может показаться ущербным.

Я мог бы сказать, что CSS это практически jQuerry, но автоматизатору со средней полосы до jQuerry как правило нет никакого дела.

Но больше всего раздражает в xpath-локаторах то, что люди пытаются делать вот такие вещи:

html/body/div[2]/div[2]/div/div/ul/li[2]/div/img
//div[@id='ui-datepicker-div']/div/div/select[2]

Только xpath тут совсем ни при чем. Огромная, зловонная куча таких вырвиглазных примеров локаторов на xpath скорее всего существует только потому, что CSS-локаторы штука относительно новая и применяя их не успели еще создать столько мусора. Это просто гипотеза, но справедливости ради стоит заметить, что вырвиглазные примеры css-локаторов я тоже вижу, но в разы реже.

Не пишите глупых локаторов просто потому, что иначе нельзя. Борьба за testability (это, кстати, атрибут качества, если кто забыл) как правило в интересах автоматизатора, так как от ее отсутствия он страдает чаще и больше тех, кто занимается тестированием ручками. Тестирующие ручками, на самом деле, тоже страдают очень сильно, но им, как правило, сложнее увидеть корень проблемы. Попытайтесь найти выход.

Например можно подойти к разработчикам и сделать вот такое лицо (мне подсказывают, что бить палкой людей плохо, так что лучше так):

Тогда они, может быть, начнут наконец проставлять идентификаторы на все элементы, что вам могут понадобиться.

Или предложите вашему разработчику написать тесты самому - он первый побежит проставлять идентификаторы.

Или проставьте их сами.

Только не рисуйте бессмысленных и беспощадных локаторов. Это зло, которое вам потом придется переписывать. И если у вас нет никакой возможности это зло побороть - переписывать, скорее всего, придется много и часто. И если смену имени/id элемента еще можно быстренько поправить (хотя в частой их смене тоже нет ничего хорошего), то переписывать развесистые локаторы, где упоминается добрая половина элементов DOM-дерева, сильно дольше. А уж читать эти развесистые локаторы после вас...

Грешки Автоматизатора. Часть 2. Sucker Punch Effect

Для не шпрехающих по англицки:

Sucker punch - запрещенный удар (удар исподтишка)

Самый тривиальный пример такого удара можно назвать "смотри, птичка!". Работает так же, как и называется:

1. Говорим "смотри, птичка" явно указывая, что птичка где-то в стороне.
2. Когда противник отвлекается - бьем его в лицо.

Чаще работает в случае дружеских мордобоев. Это я не сам придумал, это за меня посчитали психологи в ходе свои бесчеловечных экспериментов.

Почему такая банальность вообще работает? А потому что у всех у нас есть условные рефлексы. Мы верим, что информация получаемая из одного источника более достоверная, так как мы к этому привыкли. Это экономит нашему несчастному мозгу кучу времени каждый день.

Автоматизация же используется в тестировании там, где главного инструмента тестировщика - его мозгов - для выполнения задачи явно недостаточно. Эдакий костыль для мозга, который помогает жить.

Увы, у этого костыля есть ряд побочных эффектов.

Первый, и самый главный - если у нас в голове дерьмо, то костыль тут ничем не поможет. Даже если вы начнете делать все это дерьмо в 1000 раз быстрее, золотом оно от этого не станет. Оно просто станет очень быстрым дерьмом. Как это лечить, и что нужно делать - тема долгая и отдельная. Первая часть "грешков" была лишь об одном из тысяч аспектов.

Второй побочный эффект - мы начинаем этому костылю верить. А он нас начинает бить. Причем чем меньше мы о нем знаем, тем больнее он бьет.

Автоматизация это софт. Она пишется, живет и работает точно так же как и любой другой софт. У нее точно те же жизненные циклы. У нее точно те же проблемы. В ней точно так же бывают баги. Не только функциональные, кстати. И эти баги нужно чинить. Или придумывать обходные пути, то есть самые натуральные софтовые "костыли" уродующие как код тестов, так и саму логику тестов.

Хорошо, если ваш софт для автоматизации написали вы сами - вы же сами его сможете пофиксить, если вам понадобится. Никакой магии - если надо срочно починить проблему - правим сами или ждем пока случится чудо. При этом вы скорее всего будете знать его хорошо. Да, свой инструмент можно написать очень плохо, но тут как и с любым другим софтом - паттерны разработки, TDD и так далее.

Нормально, если у вас много опенсорсных решений. Хорошенько разобравшись, вы сможете их починить. Опенсорс это тоже не щеночки и единорожки, там может быть ад в коде и чинить свою проблему ASAP придется самим. Ручками. Все еще никакой магии.

Хуже, если там есть проприетарный софт с закрытым кодом. Вам придется отправлять запросы на починку/фичи. Смотреть как их отклоняют/принимают. Ждать новых версий. И все это время писать костыли, так как у вас нет возможности прожить с этой кучей багов годик до нового релиза.

Еще опаснее, если под этот проприетарный тестовый софт вам придется подстраиваться всем продуктом.

Итого. Вернемся к исходной позиции.

Есть мы. Мы пишем тесты.
Есть тесты. Хорошие, автоматические тесты. Будем считать, что тут никаких проблем нет, иначе все станет сильно сложно.
Есть наш любимый костыль. Наш инструмент. Мы в него верим.

И этот наш инструмент, наш друг, бьет нас в лицо. Нагло обманывает, так сказать. А мы об этом догадаемся когда будет уже поздно. Самый натуральный sucker punch.

Как с этим бороться?
Очень просто:

1. Изучайте свои инструменты
2. Тестируйте свои инструменты

Взять selenium и начать писать под него тесты просто. Хорошую инфраструктуру под тесты написать сложно, да. Но сами тесты в большинстве случаев писать не очень сложно.

Взять jenkins, xUnit и приклеить туда тесты написанные на selenium еще проще.

Сложнее адекватно понимать и оценивать риски этой поделки, бороться с костылями, которыми грозит нам наш любимый инструмент.

И как тестировщик добавлю - софта к которому у меня нет претензий я еще не видел. Инструменты тестирования не исключение.

Грешки Автоматизатора. Часть 1 и, думаю, не последняя

Не автоматизируйте thirdparty компоненты.

Каждый раз, когда вы пишите автоматический тест на проверку thirdparty компонент, умирает пушистый котенок.

Нет, ну серьезно, зачем писать автоматические тесты проверку получения почты через GMail-морду? Или виджеты типа кнопочки like? Зачем писать автоматические тесты на проверку thirparty процессора кредитных карт? Зачем писать автоматические тесты на авторизацию вашего приложения через твиттер?

Даже не так.

Что вы хотите узнать?

Если GMail перестанет работать, то вы с этим ничего не поделаете. А ваш тест свалится.
Если банк не проведет платеж через кредитную карту, то что вам это даст? Вы узнаете много нового о своем приложении?
А если платеж где-нибудь зависнет? Вы сможете из теста автоматически узнать, где там в банке завис ваш платеж? А сколько ваш тест готов будет ждать? Час? День? Неделю? Или нужно ставить тест в зависимость от состояния счета?
Вы действительно хотите, чтобы ваши тесты зависели, скажем, от того, упадет ли сеть в Берлине? Или получить кучу ложных срабатываний из-за того, что заглючило корпоративную прокси и у вас не открылось окошко твиттера на авторизацию приложения?

Нет.

Конечно, вам может быть и правда нужно проверить почту. Например, когда туда отправили линку на авторизацию. Только не нужно делать работу ребят из Google, занимающихся тестированием вебморды GMail. То же про виджеты facebook. То же про twitter. То же про системы процессинга кредитных карточек.

Делая это вы убиваете котят.

Всегда есть решения проще, к тому же не пахнущие плохим дизайном тестов.

• Можно проверить почту через POP/IMAP напрямую, используя библиотеки доступные в вашем языке (а они есть почти наверняка)
• Можно вставить свич и фактически замокировать thirdparty компоненту. Если это сделать аккуратно, то с точки зрения вашего приложения ничего не изменится. Правда тут есть риск выкатить не с тем свичом на продакшен, если деплой у вас идет ручками (в простанородье - "handjob")
• Можно забраться в базу скриптом и там сделать нужные переключения

У всех этих решений будет пара общих свойств:

1. Ни одно решение не ставит вас в зависимость от погоды в Ирландии.
2. Все решения могут сильно ускорить выполнение автоматических проверок.

И это даже не все возможные решения. Можно придумать еще.

На этом с первым грешком автоматизатора все.

Не убивайте котят - пишите хорошие тесты.