Популярный язык автоматизации (опрос)

@staticmethod in nosetests

Оказывается nosetests 1.2.1 имеет проблемы с обработкой функций обернутых staticmethod декораторами.

При запуске класса он выбрасывает

Traceback (most recent call last):
  File "PYTHON/site-packages/nose/loader.py", line 495, in makeTest
    return self._makeTest(obj, parent)
  File "PYTHON/site-packages/nose/loader.py", line 542, in _makeTest
    return self.loadTestsFromTestCase(obj)
  File "PYTHON/site-packages/nose/loader.py", line 466, in loadTestsFromTestCase
    return super(TestLoader, self).loadTestsFromTestCase(testCaseClass)
  File "PYTHON/unittest.py", line 547, in loadTestsFromTestCase
    testCaseNames = self.getTestCaseNames(testCaseClass)
  File "PYTHON/site-packages/nose/loader.py", line 112, in getTestCaseNames
    cases = filter(wanted, dir(testCaseClass))
  File "PYTHON/site-packages/nose/loader.py", line 111, in wanted
    return sel.wantMethod(item)
  File "PYTHON/site-packages/nose/selector.py", line 175, in wantMethod
    plug_wants = self.plugins.wantMethod(method)
  File "PYTHON/site-packages/nose/plugins/manager.py", line 99, in __call__
    return self.call(*arg, **kw)
  File "PYTHON/site-packages/nose/plugins/manager.py", line 167, in simple
    result = meth(*arg, **kw)
  File "PYTHON/site-packages/nose_unittest/plugin.py", line 25, in wantMethod
    if not issubclass(method.im_class, unittest.TestCase):
  File "PYTHON/site-packages/nose/pyversion.py", line 93, in __getattr__
    return getattr(self._func, attr)
AttributeError: 'function' object has no attribute 'im_class'

 После легкого оборачивания строки 93 из PYTHON/site-packages/nose/pyversion.py узнаем, что именно метод тестового класса, обернутый декоратором staticmethod вызвал проблему. Для меня было не критично и я просто убрал это. 

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

Недавно обнаружил для себя интересный вариант записи xpath. Т.е. он не такой и новый, но я увидел первый раз и не могу не поделиться.

//tr[td[2]//div[text()='some text']]

Сначала меня смутила такая запись, тем более, что на ней у меня и падал тест. Но потом немного покопавшись я понял, что это лаконично как все гениальное:
выбрать такую строку таблицы (tr), у которой во второй ячейке есть на любом уровне блок с текстом 'some text'

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

Новый проект, первая шишка, или Как подключить testing.xml для TestNG

Закончился предыдущий проект и начался новый. Задача минимум: автоматизировать тестирование консольного приложения, которое является интерфейсом к фреймворку.

Решили использовать Java как базу для работу. Будем запускать консольное приложение и проверять фалы, базы, немного UI, вообщем все. И потому будем использовать для проверки приложений, написанных на базе этого фреймворка. За основу решили взять не jUnit, а TestNG. Почему? За очень полезную штуку по заданию порядка тестов. А порядок для экономии времени оочень важен. Шутка ли каждый небольшой тест разворачивать новую чистую инфраструктуру.

Почитал немного. Написал несколько примитивных тестов. Назвал test1 и test2. Запустил. Сначала прошел test1, потом test2. Отлично. А что тут с порядком? Оказывается TestNg использует специальный конфигурационный xml-файл. В примерах и у меня он testing.xml. Хотя это не так и важно. Главное преподнести его как конфигурационный проекту.
Создал, в том же месте, где и лежит тестовый единственный класс. Запускаем - ничего. Хмм. Нет потяно, что само по себе мало, что работает.

Что я видел на QA Dnepr Mini Conference

В субботу состоялась первая QA Dnepr Mini Conference. Я там делился своими соображениями по анализу результатов нагрузочного тестирования.
Понравилась идея организаторов об отзывах докладчикам. Каждому участнику в раздаточных материалах выдали и одну бумажку небольшого блокнотного формата. И если участнику понравился доклад он писал свой отзыв на листочке и отдавал докладчику. Или не писал и отдавал докладчику. Я получил 9 таких и не знаю как у меня там с рейтингом отзывов, но ВСЕМ ОГРОМНОЕ СПАСИБО ЗА ЭТО. Я получил помимо спасибо еще и пару комментариев. Моя неспешность была взята на заметку :) К середине доклада я, конечно, проснулся и у нас получился с ребятами неплохая беседа по теме.
Если бы меня попросили придумать номинации, то в номинации "Самый спорный доклад" я бы отметил доклад Артема Розуменко "Как и зачем разрабатывать собственный фреймворк?". Его стандартный подход к автоматизации не вызвали бы такого ажиотажа в ранние субботние 10 утра, если бы не нестандартное применение. Больше всего споров было про независимость вызова фреймфорка: интегрировать c Continious Integration системами или нет. Как я понял - никто не мешает интегрировать, но у вас должна быть возможность запуска и без них или IDE. А также должен ли быть Ваш фреймворк project specific или нет. Немного неправильная с моей точки зрения постановка вопроса, да и Артем имел в виду то, что ядро должно быть независимым (ожидание ajax запросов, логирование, отчетность), а вот вспомогательные методы как логин, отсылка форм и т.п. всегда будет специализированным для проекта.
А как "Самый вызывающий доклад" - доклад Николая Алименкова "Жизнь без тестировщиков: миф или реальность?". Хотя что вы еще ожидали от доклада на конференции с почти 150ью тестировщиками, когда им со сцены говорят, что есть подходы позволяющие обойтись без тестировщиков в команде :) Вот народ с вызовом принял все доводы. Но, благодаря девушке из зала, Николай сознался, что тестировщика им не хватает. Хотя я бы использовал (и используем некоторые) такие подходы для улучшения качества выпускаемого продукта.
В общем и целом получилась очень хорошая конференция с домашней атмосферой, интересными докладами, конкурсами от спонсоров и подарками.

Надеюсь на приглашение организаторов на следующую конференцию.

Нет элемента? Давайте посмотрим

Если просто вызвать нажатие на любой контрол, а его нет, то Selenium просто вернет соответствующую ошибку как то: null com.thoughtworks.selenium.SeleniumException: ERROR: Element Control not found


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

В текущем тестовом фрэймворке реализован механизм, когда почти все методы селениума перегружены или расширены и расширеные методы используются намного чаще. Я всегда обрабатываю ситуацию присутствует ли элемент на странице перед тем как сделать с ним какое-либо действие. Поэтому эта проверка была включена в реализацию функции click. Точнее clickIfPresent. Есть два варианта реализации:

1) public void clickIfPresent(String elementLocator) {

        if (super.isElementPresent(elementLocator)){

            click(elementLocator);

        }

        else

            logHtmlSource("Element " + elementLocator + " doesn't exist");

    }

2) public void clickIfPresent(String elementLocator) {

        try {

            click(elementLocator);

        }

        catch (SeleniumException e){

            logHtmlSource("Element " + elementLocator + " doesn't exist");

        }

    }

Как тест инженер я разницы не вижу, но наши Java-разработчики говорят, что второй правильнее :)

Мелкие кремниевые полезности

Selenium - это бесплатное и очень удобное средство автоматизации веб приложений. Работает как библиотека на разных языках (Java, C#, Ruby, PHP, Perl, Python), подключаемая к вашему тестовому сьюту. Там большое количество атомарных методов, но для большего удобства постоянно приходится немного дорабатывать различными дополнительными методами.

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

Приведу пару примеров, а заодно сохраню их у себя :)

Автоматизировать можно быстрее

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

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

Основная идея: более дешевые решения иногда больше помогают в решении текущей задачи. Можно наступить на горло своему профессионализму (в частности автоматизатора) и сделать что-то быстро и просто. А профессионализм проявится в том насколько на этапе проработки более основательного решения вы учли, что можно придется быстро встраивать простые такие вот решения.

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