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

Я понимаю, что автотесты окупаются, если многократно запускаются, и что хорошо покрыть ими регрессию, как более стабильный участок. Но столько строчек кода, а проблемы могут найтись только в самих автотестах? 

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

«Призрак» понравился своей кажущейся простотой. Я как раз ожидала новой волны информации и практических работ из универа, и считала копание с автотестами поздними вечерами после пар замечательной отдушиной. Если б не они, то некоторые пары по программированию были б гораздо тяжелее, чем они есть(требования растут гораздо быстрее, чем растет средний уровень в группе, да что там, первый семестр за 3й курс оставил группу поредевшей).

Итак, выбор был сделан, а для создания тестов взята уже знакомая связка selenium-Java-testNG-maven-eclipse. Да простит меня блог, названный в честь питона, за выбор джавы. Я не обладаю достаточной компетенцией, поэтому лично для себя, чтобы никто не видел, составила сравнительную табличку своих впечатлений от написания тестов на обоих языках для одного приложения. Затем поставила оценки и с перевесом в полбалла победил не питон. Сейчас понимаю, что надо было ее выбирать, поскольку в этом семестре мне нужны C, Java и C#, а так не придется слишком переключаться из одного контекста в другой.

Чтобы упростить себе задачу, взяла пустую заготовку от учебного проекта. Оставалось продумать, какие сущности, согласно ООП, PageObject  и здравого смысла, мне понадобятся. Поэтому открыла  приложение и составила простейшую майндкарту , чтобы уже на ее основе писать тесты.

 

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

Объяснение Мастера можно прочитать здесь. 

Дальше, казалось, все просто, главное начать. Первый совет из притчи как раз для меня.

И началось веселье :). Оказалось, что в приложении айдишники генерируются динамически, из плагинов браузера (Firebug, Firepath) больше надежды на «Copy CSS path» (затем вырезав участки с id)  в Firebug, чем на xpath  в Firepath.

Также столкнулась с элементами, которые видны,  а их поиск возвращают пустоту вместо текста. 

Сами тесты получались очень хрупкими, несмотря на стратегически правильные ожидания наступления конкретного условия и т.д. Их часто преследовали NoSuchElementException  за ручку с TimeoutException. 

Как они могут дать хоть какую-то уверенность, что, например, форма авторизации работает как нужно, если сами падают?

К тому времени я завела в экселе чеклист, который следовало превратить в автотесты. Поняла, какая простыня из тестов получается, и что мне уже не захочется в них лишний раз лезть... скормила автотестам сам чеклист при помощи Data Provider.

С одной стороны, занимаешься интересным занятием – составляешь чеклист как положено, с вводными данными и ожидаемым результатом, а с другой стороны, вспоминаешь былые времена за экселем во время такой мелочи как перекидывании тестов на отдельные вкладки книги при помощи vlookup (чтобы ничего не потерять), группируя по ожидаемым результататам. И с третьей стороны, это используется автотестами прямо в том же виде.

Тесты начинают упрямо падать. Поэтому важно в ассерты добавлять сообщение, выводимое в случае падения теста и предусмотреть добавление в него информации об использованных вводных данных. Иначе получится, что тест зафейлился потому что ожидал [true], а получил [false]. И ищи потом на котором из пунктов чеклиста возникла проблема. 

И вот тесты упали. И не потому что нестабильные или ищут что-то не то.

Оказывается, разрешено использование почты, содержащей спецсимволы, а при приглашении пользователя с почтой в  кириллице проблема с кодировкой доменной части.

Совсем мелочь, но приятно.

Автотесты начали наносить пользу.  :)

И они нашли это используя чеклист. Так что,  чем лучше чеклисты – эффективнее ловля багов автотестами.