Comments 21
Как бы проверить оба варианта (а лучше все три, тот что с DSL тоже) на десятке живых программистов?
И оценить такие параметры:
— Время затраченное на понимание упавшего теста
— время на исправление теста, например чтобы проверялось второе место
— количество заблуждений после знакомства с тестом
И оценить такие параметры:
— Время затраченное на понимание упавшего теста
— время на исправление теста, например чтобы проверялось второе место
— количество заблуждений после знакомства с тестом
У меня есть статистика только о себе. DSL обычно отлаживается за несколько минут. Чаще всего причина ложных срабатываний: локаторы.
Если все свалено в одну кучу, то безбутылки отладчика не разберешься. На это может уйти от 10 минут до часа. Понимание логики такого теста сравнимо с постижением дзэн.
Если все свалено в одну кучу, то без
Я испол'зую немного проще связку: SpecFlow + Watin + ООП. Общие методы доступа к Элементам страницы инкапсулированы в сервис-классы. На выходе получаю MSTest. Достаточно легко отлаживать. Запускается все с помощью TeamCity. Тесты називаю Acceptance Tests. Unit Testing для бизнес логики и JavaScript никто не отменял. Есть вопрос, зачем используете TeamCity когда есть TFS?
Пример теста:
Пример теста:
Scenario: Uncomplete an existing Expense Claim
Given I have opened "Expense Claim List" screen
And I have sorted "Expense Claim List" grid by "Completed" column
And I have clicked "first" row on "Expense Claim List"
And I have "un-checked" the "Complete" tickbox on header
When I click "Save" button
Then the "Expense Claim successfully saved." success message should appear
And the "Expense Claim Detail" grid "should" be editable
# language: ru
@javascript
Функционал: Управление записями на осмотр
Предыстория:
Допустим я создал компанию
Допустим есть пользователь
Допустим пользователь принадлежит этой компании
Допустим я создал schedule на завтра для этой компании
Сценарий: Отображение списка записей на осмотр
Пусть я залогинился
Если я зайду на '/schedules'
То я должен увидеть 'Антон'
И я должен увидеть '###'
И я должен увидеть '+7 ### ###-##-##'
Если я нажму на '#edit_schedule'
То я должен увидеть 'Текущая'
Недавно обсуждали похожу ситуацию. Договорились в таких случаях делать проверку одним шагом
То я должен увидеть имя: Антон, телефон: ****, не знаю, что у вас во втором пункте: ***
В этом случае, если тест упадет, вы получите больше информации. Например, вы видите не «Антон», а «Вася». Это значит, что кто-то сменил имя пользователя или это ошибка приложения, которая выдала не того юзера?
Это не противоречит принципу «проверять одну вещь за один раз». Просто «одна вещь» = профиль пользователя.
То я должен увидеть имя: Антон, телефон: ****, не знаю, что у вас во втором пункте: ***
В этом случае, если тест упадет, вы получите больше информации. Например, вы видите не «Антон», а «Вася». Это значит, что кто-то сменил имя пользователя или это ошибка приложения, которая выдала не того юзера?
Это не противоречит принципу «проверять одну вещь за один раз». Просто «одна вещь» = профиль пользователя.
TeamCity сейчас используем в тестовом режиме: сравниваем. Есть несколько преимуществ:
Сейчас разбираемся с новыми фишками 2012 ТФС-а. Включим тесты в отчеты, посмотрим, что получится.
- «из коробки» тест-ранер показывает информацию горзадо удобнее, чем ТФС
- тим-сити работает быстрее
- тим-сити крутится на отдельной машине и не путается с CI-билдами и выкладками, можно было бы ограничиться дополнительным билд-агентом, если бы не пункт 1
Сейчас разбираемся с новыми фишками 2012 ТФС-а. Включим тесты в отчеты, посмотрим, что получится.
Интересно было бы почитать о миграции с TFS на TC. Переезд базы кода. И результаты сравнения в целом.
Мы не мигрировали. TFS используется для nightly builds, CI builds, прогона unit-test'ов, выкладок на окружения. TeamCity стоит на отдельной машине и используется только для прогона системных тестов. Получилось быстрее и удобнее, чем выносить билд-агент TFS на отдельную машину. Тесты не путаются с остальными билдами, привязали SpecFlow-отчеты. Получилось довольно удобно. Сравнивать TFS и TeamCity не корректно. Тут надо говорить о связке, скажем, GIT + Jira +TeamCity VS TFS. Вообще есть плюсы и минусы и там и там. У TFS самое слабое место — это чудовищный VCS. Ждем релиза с GIT (пока доступен только в облаке).
Чтобы проверялось второе место, нужно писать два теста
Автору респект, разложено по полочкам. Мог бы — плюсанул.
+1
Отличная статья, вы молодец. Не ожидал на Хабре настолько подробной статьи по автоматизации тестирования, не самая популярная тут тема.
Я занимался разработкой подобного фреймворка на похожем стеке (без SpecFlow и c MbUnit вместо NUnit). От SpecFlow отказались по причине проблем с распараллеливанием тестов, т.к. он только с костылями это умеет делать. Вам не критична параллелизация тестов, или вы нашли хорошее решение?
Я занимался разработкой подобного фреймворка на похожем стеке (без SpecFlow и c MbUnit вместо NUnit). От SpecFlow отказались по причине проблем с распараллеливанием тестов, т.к. он только с костылями это умеет делать. Вам не критична параллелизация тестов, или вы нашли хорошее решение?
С параллелизмом есть еще веб-драйвер, который может «зависнуть». Как вариант делать через remote, но там тоже есть свои прелести.
Мы решили разбивать тесты на сборки «по-интересам»: есть одна сборка для смоуков, дальше по компонентам системы. Каждую сборку можно запустить параллельно. На предыдущем проекте не заморачивались с параллелизмом, на этом, возможно будем. Я подумаю об этом, когда тесты будут выполняться 6-8 часов.
Мы решили разбивать тесты на сборки «по-интересам»: есть одна сборка для смоуков, дальше по компонентам системы. Каждую сборку можно запустить параллельно. На предыдущем проекте не заморачивались с параллелизмом, на этом, возможно будем. Я подумаю об этом, когда тесты будут выполняться 6-8 часов.
Спасибо за статью.
Вы можете выложить код рассмотренного примера?
Вы можете выложить код рассмотренного примера?
Нет ли планов использовать PhantomJS WebDriver? Есть надежда, что он должен быть быстрее и надёжнее не headless драйверов, но пока не было возможности проверить.
спустя столько лет вернулся пересмотреть статью
"Гайдлайн автоматизатора" - все валидно, все совпадает с моим опытом с полей, как раз в свое время искал что-то такое )
в текущем проекте отказались от Specflow и просто пишем Selenium тесты, по факту оказал проще, еле откачали сборку с ними, по факту получился мини фреймворк, по гайдлайнам что вы собрали в одном месте, так что спасибо
del
Sign up to leave a comment.
Автоматизация тестирования Web-приложений