В момента използваме SWEA (http://webiussoft.com), за да изпълняваме автоматизирани тестове на сайта по време на нашия CruiseControl.NET през нощта изгражда.
Ние търсим по-стабилно решение и разглеждаме „Изкуството на теста“ (http://www.artoftest.com) решение.
Някой има ли опит с този инструмент?
Най-важното е колко лесно е да се поддържат тестове с помощта на този инструмент?
Или има ли други C#/NUnit/CruiseContol.NET решения, които бихте препоръчали?
Работя за ArtOfTest. През последните няколко дни проучвах какво е необходимо, за да накараме нашата рамка да работи добре с CruiseControl.NET. Основният ключ е да стартирате сървъра CruiseControl.NET в конзолен режим (вместо като услуга на Windows). Причината за това е да се позволи фазата на изпълнение на теста на модула да може да взаимодейства директно с работния плот, което е необходимо за тестване на потребителския интерфейс. Обикновено кодът, който се изпълнява под услуга на Windows, няма право да взаимодейства с работния плот (което нашият изисква) и по този начин ще се провали, когато се опита.
TeamCity също е друг добър CI сървър. Гледам това в момента и най-вече го разбрах.
Ако имате други по-конкретни въпроси, не се колебайте да се свържете с нас на [email protected]. И аз ще следя тази тема.
WatiN не е лош. За съжаление липсва каквато и да е интеграция на VisualStudio и липсват много други функции, които предлагаме.
Благодаря, Коди
Връзката по-долу е документация за това как да накарате WebAii да работи с всички популярни CI сървъри (CC, TeamCity и TFS Build)
http://www.artoftest.com/support/webaii/topicsindex.aspx?topic=cioverview
Изглежда, че двете големи са Watin & Selenium. Не съм работил със Selenium, така че нямам мнение.
Използвал съм Watin прилично количество и е доста добро, но има много проблеми. Може да е трудно да се справите с изключително вариращите времена за отговор от браузър... задаване на времетраене на изчакване и други подобни.
Последната версия на Watin поддържа IE & Firefox, което е доста готино.
Що се отнася до тестовата поддръжка, според моя опит най-важното нещо е напълно да се отдели кодът на "тестовия драйвер" от "кода за обвиване на страници". Под „тестов драйвер“ имам предвид действителната тестова логика (NUnit или подобна), която може да има код, който изглежда така:
...
var wrapper = new SearchPageWrapper(browser);
wrapper.ClickAdvancedSearch();
wrapper.EnterSearchPhrase("dog");
wrapper.SetSortBy(SortType.Date);
wrapper.ExecuteSearch();
... обвивката на страницата излага този логически интерфейс на самата страница, като същевременно скрива подробностите за изпълнение (които могат да бъдат сложни и да се променят често с оформлението на страницата):
public class SearchPageWrapper {
...
public void ClickAdvancedSearch() {
_browser.Buttons("advSearch").Click();
}
public void EnterSearchPhrase(string phrase) {
_browser.TextBox(Find.ByName("phrase")).TypeText(phrase);
}
... etc ...
}
По този начин изграждате библиотека от обвивки, която улеснява добавянето на нови тестови случаи и също така прави по-малко болезнено справянето с промени в оформлението, които засягат начина, по който Watin намира и взаимодейства с елементите на страниците.
