Показаны сообщения с ярлыком Test Automation. Показать все сообщения
Показаны сообщения с ярлыком Test Automation. Показать все сообщения
четверг, 7 июля 2016 г.
среда, 25 декабря 2013 г.
@staticmethod in nosetests
Оказывается nosetests 1.2.1 имеет проблемы с обработкой функций обернутых staticmethod декораторами.
При запуске класса он выбрасывает
При запуске класса он выбрасывает
Traceback (most recent call last):После легкого оборачивания строки 93 из PYTHON/site-packages/nose/pyversion.py узнаем, что именно метод тестового класса, обернутый декоратором staticmethod вызвал проблему. Для меня было не критично и я просто убрал это.
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'
пятница, 1 февраля 2013 г.
XPath как условие для выбора элемента с помощью XPath
Недавно обнаружил для себя интересный вариант записи xpath. Т.е. он не такой и новый, но я увидел первый раз и не могу не поделиться.
//tr[td[2]//div[text()='some text']]
Сначала меня смутила такая запись, тем более, что на ней у меня и падал тест. Но потом немного покопавшись я понял, что это лаконично как все гениальное:
выбрать такую строку таблицы (tr), у которой во второй ячейке есть на любом уровне блок с текстом 'some text'
Т.е. накладывается не просто условия значения атрибута, а условия наличия в потомках определенного элемента через задание его xpath. Уровень вложенности не ограничен
//tr[td[2]//div[text()='some text']]
Сначала меня смутила такая запись, тем более, что на ней у меня и падал тест. Но потом немного покопавшись я понял, что это лаконично как все гениальное:
выбрать такую строку таблицы (tr), у которой во второй ячейке есть на любом уровне блок с текстом 'some text'
Т.е. накладывается не просто условия значения атрибута, а условия наличия в потомках определенного элемента через задание его xpath. Уровень вложенности не ограничен
среда, 4 января 2012 г.
Новый проект, первая шишка, или Как подключить testing.xml для TestNG
Закончился предыдущий проект и начался новый. Задача минимум: автоматизировать тестирование консольного приложения, которое является интерфейсом к фреймворку.
Решили использовать Java как базу для работу. Будем запускать консольное приложение и проверять фалы, базы, немного UI, вообщем все. И потому будем использовать для проверки приложений, написанных на базе этого фреймворка. За основу решили взять не jUnit, а TestNG. Почему? За очень полезную штуку по заданию порядка тестов. А порядок для экономии времени оочень важен. Шутка ли каждый небольшой тест разворачивать новую чистую инфраструктуру.
Почитал немного. Написал несколько примитивных тестов. Назвал test1 и test2. Запустил. Сначала прошел test1, потом test2. Отлично. А что тут с порядком? Оказывается TestNg использует специальный конфигурационный xml-файл. В примерах и у меня он testing.xml. Хотя это не так и важно. Главное преподнести его как конфигурационный проекту.
Создал, в том же месте, где и лежит тестовый единственный класс. Запускаем - ничего. Хмм. Нет потяно, что само по себе мало, что работает.
Решили использовать Java как базу для работу. Будем запускать консольное приложение и проверять фалы, базы, немного UI, вообщем все. И потому будем использовать для проверки приложений, написанных на базе этого фреймворка. За основу решили взять не jUnit, а TestNG. Почему? За очень полезную штуку по заданию порядка тестов. А порядок для экономии времени оочень важен. Шутка ли каждый небольшой тест разворачивать новую чистую инфраструктуру.
Почитал немного. Написал несколько примитивных тестов. Назвал test1 и test2. Запустил. Сначала прошел test1, потом test2. Отлично. А что тут с порядком? Оказывается TestNg использует специальный конфигурационный xml-файл. В примерах и у меня он testing.xml. Хотя это не так и важно. Главное преподнести его как конфигурационный проекту.
Создал, в том же месте, где и лежит тестовый единственный класс. Запускаем - ничего. Хмм. Нет потяно, что само по себе мало, что работает.
среда, 30 марта 2011 г.
Как в SQL получить то, чего в базе нет
Я не назвал бы себя знатоком SQL. Я просто знаю как мне выбирать, вставлять и изменять нужные мне данные. Поэтому решить мне такую задачку просто с ходу не хватило знаний. Хотя она не такая и сложная.
Предыстория: регистрировал 1000 пользователей через http-запросы к системе. Получил отказы в 70% случаев. Регистрировал по маске u000
Задача: Выбрать список пользователей не зарегестрированых в системе. Если известен список зарегестрированых пользователей. А список пользователей, которых надо зарегестрировать соответствует определенной с буквенным префиксом и цифровым суффиксом, вырастающим инкрементально с шагом 1.
Получил решения от своих коллег разработчиков :)
четверг, 10 февраля 2011 г.
Нет элемента? Давайте посмотрим
Если просто вызвать нажатие на любой контрол, а его нет, то 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-разработчики говорят, что второй правильнее :)
среда, 15 декабря 2010 г.
Мелкие кремниевые полезности
Selenium - это бесплатное и очень удобное средство автоматизации веб приложений. Работает как библиотека на разных языках (Java, C#, Ruby, PHP, Perl, Python), подключаемая к вашему тестовому сьюту. Там большое количество атомарных методов, но для большего удобства постоянно приходится немного дорабатывать различными дополнительными методами.
Пожалуй правильнее всего с точки срезния разработки не встраивать такие методы в свои тестовые методы, т.к. они не связаны с логикой приложения, но используются в тестах, а унаследовать от основоного класса библиотеки Selenium и добавить такие дополнительные методы именно туда.
Приведу пару примеров, а заодно сохраню их у себя :)
Пожалуй правильнее всего с точки срезния разработки не встраивать такие методы в свои тестовые методы, т.к. они не связаны с логикой приложения, но используются в тестах, а унаследовать от основоного класса библиотеки Selenium и добавить такие дополнительные методы именно туда.
Приведу пару примеров, а заодно сохраню их у себя :)
четверг, 4 февраля 2010 г.
Автоматизировать можно быстрее
Вот прослушивал один из подкастов ИТ-радио "Промразработка" и мне понравилась высказанная там идея. Она не такая и новая на самом деле, но отлично легла на сложившуюся у меня ситуацию.
Занимаюсь автоматизацией, в том числе, но более плотно и стабильно, последние полгода. В динамично разрабатывающемся проекте. И проблема как положено с изменением тестов, написанных основательно, со своим небольшим высокоуровневым фреймворком.
Писать не всегда обязательно основательно, со взглядом в будущее из под могучей руки опытного автоматизатора (скорее про некоторых читающих, чем себя :) ). Достаточно просто решить текущую проблему и покрыть функциональность не устоявшуюся еще обычными записываемыми тестами, пусть и придется перезаписывать их чуть ли не каждый раз (или слегка корректируемыми тестами) в пределах разработки. Вопрос исключительно в том, что в текущей итерации (если они не длятся порядка недели-двух) трудозатраты будут меньшими на более простое решение, а в начале следующей вполне можно изменить имеющиеся сценарии и интегрировать в основное решение по автоматическим тестам. Ну или просто оставить как есть. Последняя версия работает же :) Но тут ни на чем не хочу настаивать. Решение надо подбирать под конкретную ситуацию.
Основная идея: более дешевые решения иногда больше помогают в решении текущей задачи. Можно наступить на горло своему профессионализму (в частности автоматизатора) и сделать что-то быстро и просто. А профессионализм проявится в том насколько на этапе проработки более основательного решения вы учли, что можно придется быстро встраивать простые такие вот решения.
З.Ы. надеюсь, что этой быстрой статье наконец-то пробью затишье в своих записях и не только доведу до ума свои черновики, но и сяду за описание своих идей и мыслей
Занимаюсь автоматизацией, в том числе, но более плотно и стабильно, последние полгода. В динамично разрабатывающемся проекте. И проблема как положено с изменением тестов, написанных основательно, со своим небольшим высокоуровневым фреймворком.
Писать не всегда обязательно основательно, со взглядом в будущее из под могучей руки опытного автоматизатора (скорее про некоторых читающих, чем себя :) ). Достаточно просто решить текущую проблему и покрыть функциональность не устоявшуюся еще обычными записываемыми тестами, пусть и придется перезаписывать их чуть ли не каждый раз (или слегка корректируемыми тестами) в пределах разработки. Вопрос исключительно в том, что в текущей итерации (если они не длятся порядка недели-двух) трудозатраты будут меньшими на более простое решение, а в начале следующей вполне можно изменить имеющиеся сценарии и интегрировать в основное решение по автоматическим тестам. Ну или просто оставить как есть. Последняя версия работает же :) Но тут ни на чем не хочу настаивать. Решение надо подбирать под конкретную ситуацию.
Основная идея: более дешевые решения иногда больше помогают в решении текущей задачи. Можно наступить на горло своему профессионализму (в частности автоматизатора) и сделать что-то быстро и просто. А профессионализм проявится в том насколько на этапе проработки более основательного решения вы учли, что можно придется быстро встраивать простые такие вот решения.
З.Ы. надеюсь, что этой быстрой статье наконец-то пробью затишье в своих записях и не только доведу до ума свои черновики, но и сяду за описание своих идей и мыслей
Подписаться на:
Сообщения (Atom)