Comments 14
Просто и доступно. Особенно примечательно, что тестируете не PHP, как в большинстве подобных топиков.
Хотя для себя нового ничего не узнал, но после каждого подобного топика вспоминаю, что хотел вплотную взяться за тесты. И пишу еще десяток тестов. Вот пойду еще напишу.
Вы правильно подметили, что первый путь довольно редко встречается. Потому что начальнику (не разбирающемуся в теме) не докажешь, что это надо. Он видит снижение скорости разработки, а выгоды никакой.
Второй путь, как вы правильно заметили, более привлекателен. Но есть одно но: когда я в свободное время изучал тестирование, я тестировал свои личные проекты, а не рабочие. И тут получается либо тратить личное время на рабочие проекты, либо на свои. Я предпочитаю второе.
За статью спасибо. Очень удачно с темой попали. Я как раз решил плотно заняться c#, а тут про тесты как раз.
Хотя для себя нового ничего не узнал, но после каждого подобного топика вспоминаю, что хотел вплотную взяться за тесты. И пишу еще десяток тестов. Вот пойду еще напишу.
Вы правильно подметили, что первый путь довольно редко встречается. Потому что начальнику (не разбирающемуся в теме) не докажешь, что это надо. Он видит снижение скорости разработки, а выгоды никакой.
Второй путь, как вы правильно заметили, более привлекателен. Но есть одно но: когда я в свободное время изучал тестирование, я тестировал свои личные проекты, а не рабочие. И тут получается либо тратить личное время на рабочие проекты, либо на свои. Я предпочитаю второе.
За статью спасибо. Очень удачно с темой попали. Я как раз решил плотно заняться c#, а тут про тесты как раз.
Я для тестирования web приложений выбрал BDD подход, легко описывается, отчеты прямо из коробки, большая реюзабельность кода.
если честно, близко не сталкивался с этим, почитаю.
Здесь на хабре есть перевод: Введение в программирование через поведение (BDD). Настоятельно рекомендую прочитать
вы много потеряли, поверьте
Для небольшого проекта, такой подход вполне приемлем и оправдан. Ежели проект будет расти, то нужно будет думать о поднятии selenium grid, CI, и писать кросбраузерные обертки для действий, и классы для локаторов(на случай, если поменяется id, или вставится лишний div). У так — успехов в этом не легком деле.
CI используем, насчет grid — пока рановато, но, вероятно, в дальнейшем, буду использовать. Насчет локаторов, на данную секунду достаточно при необходимости менять их в классах страниц. Тесты не работают напрямую с элементами (только через страницы), поэтому небольшие изменения в верстке не очень критичны.
Насчет «кросбраузерных оберток для действий» не совсем понял, поясните плиз. Сейчас за выбор браузера отвечает параметр в конфиг-файле (или же параметр в teamcity).
Насчет «кросбраузерных оберток для действий» не совсем понял, поясните плиз. Сейчас за выбор браузера отвечает параметр в конфиг-файле (или же параметр в teamcity).
Ну у разных драйверов разные особенности работы. Например ff_последней верссии, как правило поддерживается достаточно минималистично. По этому без опции enableNativeEvents использовать его нет смысла. Actions поддерживаются совершенно по-разному и по этому в том же ff actions.click().build().perform() — в зависимости от версии самого драйвера может как выполниться, так выполниться успешно для некого набора элементов, выкинуть ошибку или просто не нажать на элемент. По этому данное действие в ff принято заменять clickAndHold().release().
Или например так: у вас по нажатию кнопки вызывается javascript, который добавляет класс элементу. В своём селениум тесте вы нажимаете на кнопку и потом проверяете, что у элемента появился класс. Так довольно часто selenium успевает проверить элемент до того, как js изменит класс. Про ajax я вообще молчу.
В общем что бы в разных браузерах ваш код выполнялся одинаково, проще написать обертку для всего этого дела. И пользоваться ей, что бы не париться над каждым браузером и каждым тестом.
p.s.
А еще есть интернет эксплорер, который желательно тоже тестить :)
Или например так: у вас по нажатию кнопки вызывается javascript, который добавляет класс элементу. В своём селениум тесте вы нажимаете на кнопку и потом проверяете, что у элемента появился класс. Так довольно часто selenium успевает проверить элемент до того, как js изменит класс. Про ajax я вообще молчу.
В общем что бы в разных браузерах ваш код выполнялся одинаково, проще написать обертку для всего этого дела. И пользоваться ей, что бы не париться над каждым браузером и каждым тестом.
p.s.
А еще есть интернет эксплорер, который желательно тоже тестить :)
Практика показывает что отчетность осуществляется средствами CI, а не самого фреймворка. Используя, например, Jenkins можно просто опубликовать репорт nunit на странице билда. Скорее всего у тимсити это в коробке есть.
Для логирования действий можно прикрутить log4net.
Поиск элементов в веб-страницах удобнее делать с помощью плагина FireBug к браузеру Firefox. Прогодятся также плагины XPath Checker и FireFinder. На мой взгляд это гораздо удобнее чем Selenium IDE.
Советую посмотреть в сторону паттернов Page Object и Page Factory а также аннотациям FindBy.
Для логирования действий можно прикрутить log4net.
Поиск элементов в веб-страницах удобнее делать с помощью плагина FireBug к браузеру Firefox. Прогодятся также плагины XPath Checker и FireFinder. На мой взгляд это гораздо удобнее чем Selenium IDE.
Советую посмотреть в сторону паттернов Page Object и Page Factory а также аннотациям FindBy.
Скорее всего у тимсити это в коробке есть.. Да, он генерит отчеты которые можно посмотреть на странице билда, но, насколько я знаю, по-простому не умеет их автоматически отправлять кому надо, для этого и такой костыль:-)
Для логирования действий можно прикрутить log4net.не хотел перегружать сторонними библиотеками, тем более что на данном этапе самописный класс справляется, возможно позже прикручу
За Checker спасибо, не знал о таком.
Page Object и Page Factoryэто используется
Спасибо за фидбек.
Sign up to leave a comment.
Автоматизация тестирования. Начало пути