WatiN czy Selenium? [Zamknięte]

Wkrótce zacznę kodować automatyczne testy naszej prezentacji. Wydaje się, że wszyscy polecają WatiN i Selenium . Co wolisz do automatycznego testowania formularzy internetowych ASP.NET? Który z tych produktów działa lepiej dla Ciebie?

Na marginesie zauważyłem, że WatiN 2.0 jest w CTP od marca 2008, czy jest to coś, czym należy się martwić?

Chcę tylko powiedzieć, że obecnie ciężko pracuję nad wydaniem beta WatiN 2.0 gdzieś w pierwszym kwartale 2009 roku. Będzie to główne uaktualnienie do aktualnych wersji CTP 2.0 i zasadniczo da ci tę samą funkcjonalność do automatyzacji FireFox i IE, jak wersja 1.3.0 oferuje automatyzację IE.

Więc nie ma obaw.

Mam nadzieję, że pomoże to w dokonaniu wyboru Jeroen van Menen Lead dev dev WatiN

Jeśli chcesz dokonać poważnej, długoterminowej inwestycji w ramy, które będą nadal ulepszane i wspierane przez społeczność, Selenium jest prawdopodobnie najlepszym rozwiązaniem. Na przykład właśnie natknąłem się na te informacje na blogu Matta Raible:

Od piątku Google ma ponad 50 zespołów przeprowadzających ponad 51 000 testów dziennie na wewnętrznej farmie Selenium. 96% tych testów jest wykonywanych prawidłowo przez Selenium RC i maszyny Farm. Pozostałe 4% są częściowo spowodowane błędami RC, częściowo błędami testowymi, ale ustalenie przyczyny może być trudne. Selenium zostało przyjęte jako podstawowa technologia testowania funkcjonalnego aplikacji internetowych w Google. To dobra wiadomość.

Byłem też niedawno na jednym ze spotkań Selenium i dowiedziałem się, że Google wkłada poważne zasoby w ulepszanie Selenium i integrację go z WebDriver, który jest zautomatyzowanym narzędziem testującym opracowanym przez Simona Stewarta. Jedną z głównych zalet WebDriver jest to, że kontroluje on samą przeglądarkę zamiast działać w przeglądarce jako aplikacja JavaScript, co oznacza, że ​​główne przeszkody, takie jak problem „tego samego źródła”, nie będą już stanowić problemu.

Przetestowaliśmy oba i zdecydowaliśmy się na WaTiN. Jak zauważyli inni, Selenium ma kilka fajnych funkcji, których nie ma w WaTiN, ale napotkaliśmy problemy z działaniem Selenium, a kiedy to zrobiliśmy, było to zdecydowanie wolniejsze podczas uruchamiania testów niż WaTiN. Jeśli dobrze pamiętam, problemy z konfiguracją, które napotkaliśmy, wynikały z faktu, że Selenium miało oddzielną aplikację do kontrolowania rzeczywistej przeglądarki, w której WaTiN robił wszystko w trakcie.

Próbowałem ich obu i oto moje początkowe przemyślenia ...

WatiN

Dobra

• Szybka realizacja.
• Narzędzia do tworzenia skryptów to niezależne projekty; są 2, o których wiem: wosk (oparty na Excelu, hostowany na CodePlex) i WatiN Test Record (hostowany na SourceForge). Żadne z nich nie jest tak solidne jak Selenium IDE.
• Bardzo dobra obsługa IE. Może dołączać i odłączać się od uruchomionych instancji. Może uzyskać dostęp do natywnych uchwytów okien itp. (Zobacz przykład skryptu poniżej).
• Pakiety NuGet, łatwe do uruchomienia w środowiskach .NET, w stylu Visual Studio i aktualizowane.

Źli

• Googlowanie WatiN (watin xyz) często powoduje, że Google zamiast tego poleca „watir xyz”. Niewiele tam dokumentacji.
• To, co tam jest (dokumentacja), jest mylące; na przykład: na pierwszy rzut oka mogłoby się wydawać, że nie ma natywnego wsparcia dla selektorów CSS. Zwłaszcza, że ​​istnieją biblioteki rozszerzeń, takie jak „WatiNCssSelectorExtensions” i wiele artykułów na blogu o alternatywnych technikach (takich jak wstrzyknięcie jQuery / sizzle do strony). Na Stack Overflow znalazłem komentarz Jeroena van Menena, który sugeruje, że istnieje natywne wsparcie. Przynajmniej główny programista spędza czas na przepełnieniu stosu :)
• Brak natywnej obsługi XPath.
• Brak gotowego do użycia zdalnego wykonywania / wykonywania na podstawie siatki.

Przykład skryptu (C #). Nie możesz tego zrobić z Selenium (przynajmniej nie żebym wiedział):

class IEManager
{
    IE _ie = null;
    object _lock = new object();

    IE GetInstance(string UrlFragment)
    {
        lock (_lock)
        {
            if (_ie == null)
            {
                var instances = new IECollection(true);  //Find all existing IE instances
                var match = instances.FirstOrDefault(ie=>ie.Url.Contains(UrlFragment));
                _ie = match ?? new IE();
                if (match==null)  //we created a new instance, so we should clean it up when done!
                    _ie.AutoClose = true;
            }
        }

        return _ie;
    }
}

Selen

• Wolniej niż WatiN (zwłaszcza, że ​​trzeba utworzyć nowy proces).
• Wbudowane selektory CSS / obsługa XPath.
• Selenium IDE jest dobre (nie można powiedzieć, że jest świetne, ale jest najlepsze w swojej klasie!).
• Czuje się bardziej w stylu Java niż .NET ... ale tak naprawdę jest to agnostyk języka programowania; wszystkie polecenia są wysyłane do „sterownika” poza procesem. Sterownik jest w rzeczywistości procesem „hosta” dla instancji przeglądarki. Cała komunikacja musi być serializowana do / z granic procesu, co może wyjaśniać problemy z szybkością związane z WatiN.
• Procesy oddzielone - „Sterownik” i „Kontrola” oznaczają większą niezawodność, większą złożoność itp., Ale także łatwiejsze do tworzenia siatek / rozproszonych środowisk testowych. Bardzo by się spodobało, gdyby mechanizm „dystrybucji” (tj. Komunikacja między sterownikiem i sterowaniem) był realizowany w ramach produktu WebSphere lub innego istniejącego, niezawodnego menedżera kolejek komunikatów.
• Obsługuj Chrome i inne przeglądarki po wyjęciu z pudełka.

Mimo wszystko ostatecznie wybrałem WatiN; Zamierzam głównie pisać małe aplikacje do skrobania ekranu i chcę używać LINQPad do programowania. Podłączenie do zdalnej instancji IE (takiej, której sam nie stworzyłem) to duży plus. Mogę bawić się w istniejącej instancji ... potem uruchomić trochę skryptu ... potem znowu bawić się itd. Jest to trudniejsze do zrobienia z Selenium, chociaż przypuszczam, że w skrypcie mogą być osadzone „przerwy”, podczas których mógłbym bawić się bezpośrednio w przeglądarce.

Największą różnicą jest to, że Selenium obsługuje różne przeglądarki (nie tylko IE czy FF, zobacz http://seleniumhq.org/about/platforms.html#browsers .

Ponadto Selenium posiada serwer zdalnego sterowania ( http://seleniumhq.org/projects/remote-control/ ), co oznacza, że ​​nie musisz uruchamiać przeglądarki na tej samej maszynie, na której działa kod testowy. Możesz więc przetestować swoją aplikację internetową. na różnych platformach operacyjnych.

Generalnie polecam używanie Selenium. Korzystałem z WatiN kilka lat temu, ale nie byłem zadowolony z jego stabilności (prawdopodobnie już się poprawiła). Największym plusem dla Selenium jest dla mnie fakt, że możesz przetestować aplikację webową. w różnych przeglądarkach.

Ani. Użyj Coypu. Otacza selen. O wiele trwalszy. https://github.com/featurist/coypu

Zaktualizuj Ye Oliver, masz rację. Ok, dlaczego jest lepiej? Osobiście uważam, że sterownik Selenium dla IE jest szczególnie delikatny - istnieje wiele `` standardowych '' wyjątków sterowników, które ponownie znalazłem podczas jazdy Selenium do testów jednostkowych na ciężkich stronach Ajax.

Czy wspomniałem, że chcę pisać moje skrypty w języku c # jako projekt testowy? Tak Testy akceptacyjne w ramach ciągłego wdrażania kompilacji.

Cóż, Coypu radzi sobie z powyższym. To opakowanie dla Selenium, które umożliwia testowanie urządzeń, takich jak,

browser.Visit("file:///C:/users/adiel/localstuff.htm")
browser.Select("toyota").From("make");
browser.ClickButton("Search");

... który uruchomi (konfigurowalną markę) przeglądarki i uruchomi skrypt. Działa świetnie z obszarami z lunetą i jest BARDZO rozszerzalny.

Na GitHub jest więcej przykładów i jak wspomina Olvier poniżej, wideo Adriana jest doskonałe. Myślę, że to najlepszy sposób na prowadzenie testów opartych na przeglądarkach w świecie .Net i stara się podążać za imiennikiem Rubiegocapybara

Użyłem obu, oba wydają się działać dobrze. Mój ukłon w stronę Selenium, ponieważ wydawało się, że ma lepszą obsługę Ajax. Uważam, że WaTiN dojrzał od czasu, gdy go ostatnio używałem, więc powinien mieć to samo.

Najważniejsze byłoby to, w jakim środowisku programistycznym lubisz być? Selenium i Watin mają nagrywarki, ale Selenium jest w przeglądarce, a Watin jest w studio wizualnym. + i - do obu z nich.

Do tej pory byliśmy czystym sklepem Microsoft w zakresie dostarczania rozwiązań dla przedsiębiorstw i poszliśmy z WatiN. To może się zmienić w przyszłości.

Jako nowsze źródło:

Firma Microsoft wydrukowała w MSDN Magazine 12/2010 podkład BDD z połączeniem SpecFlow z WatiN (cool BDD-Behavior Driven Development). Jego autor, Brandon Satrom (msft Developer Evangelist), również opublikował w grudniu 2010 r. Wideo w sieci Web, przedstawiające szczegółowo 1: 1 powyższe odkrycia.

Jest to oficjalny dokument od 04/2011 na Wspieranie ATDD / BDD z SpecLog, SpecFlow i Team Foundation Server (Acceptance Test Driven Development / Behavior Driven Development) z chrześcijańskiego Hassa , którego zespół zbudowany SpecFlow.

Używam Watin, ale nie używałem Selenu. Mogę powiedzieć, że szybko wstałem i zacząłem działać na Watin i miałem kilka problemów lub żadnych problemów. Nie przychodzi mi do głowy nic, co chciałbym zrobić, czego nie potrafiłbym pojąć. HTH

Generalnie używam Selenium, głównie dlatego, że lubię wtyczkę Selenium IDE dla FireFox do rejestrowania punktów startowych moich testów.

Polecam WebAii, ponieważ z tym odniosłem sukces, a podczas korzystania z niego moje zastrzeżenia były nieliczne. Nigdy nie próbowałem Selenium i nie pamiętam, żebym często używał WaTiN, przynajmniej nie do momentu, w którym mogłem sprawić, by z powodzeniem działał. Nie znam żadnego frameworka, który z wdziękiem radziłby sobie z oknami dialogowymi systemu Windows, chociaż WebAii ma interfejs do implementowania własnych programów obsługi okien dialogowych.

Rozważałem użycie obu. Użyłem rejestratora dla Selenium do zbudowania kilku testów w FF. Próbowałem zrobić to samo w Watin i stwierdziłem, że Watin Recorder (2.0.9.1228) jest całkowicie bezwartościowy dla naszych witryn . Wyglądało na to, że witryna renderowała się w przeglądarce IE6, przez co nasza witryna nie nadaje się do nagrywania. Nie obsługujemy IE6. Nie mogłem znaleźć żadnego sposobu na zmianę używanej przeglądarki. Znalazłem tylko jeden Watin Recorder. Jeśli istnieje więcej niż jeden lub taki, który jest aktualizowany, skomentuj.

Selenium Recorder IDE dla przeglądarki Firefox jest proste w użyciu i przenosi testy do języka C #. Nie jest w tym świetny. Nie mogłem uruchomić przenoszenia pakietów testowych, pomimo przeczytania jednego lub dwóch postów na blogu, które zawierały obejścia. Jest więc trochę manipulacji wygenerowanym kodem. Mimo to działa w 90% i to lepiej niż alternatywa.

Jak na moje pieniądze / czas, Selenium jest lepsze tylko ze względu na łatwość tworzenia nowych testów . IE nie ma żadnych dobrych pasków narzędzi deweloperskich, które byłyby tak dobre jak Firebug , więc zaczynam od programu Firefox, więc posiadanie dobrego działającego rejestratora w Firefoksie to ogromny bonus.

Mój wniosek był bardzo podobny do cytatu Churchilla na temat demokracji: selen jest najgorszą formą automatycznego testowania interfejsu użytkownika. Z wyjątkiem wszystkich innych.

Ryzykując wypadnięcie na stycznej, poleciłbym Ax / WatiN. Ax umożliwia pisanie testów w Excelu przez testerów „manualnych”, którzy nie znają podstawowego „języka” testu. Potrzebny jest „Technik” do napisania działań na zamówienie (tj. Dzisiaj musiałem wykonać nieco skomplikowane wyszukiwanie w tabeli i odsyłacze), ale po napisaniu czynności mogą być użyte w testach przez testerów niebędących specjalistami.

Słyszałem również, że projekt UK Government Gateway (który, jak sądzę, zawiera testy automatyczne 6K +), niedawno przeniósł wszystkie swoje testy z Ax / Winrunner na Ax / Watin w ciągu tygodnia !! A wiele testów jest dość skomplikowanych - wiem, że pracowałem nad tym kilka lat temu ...

Patrzę na Selenium w tej chwili, ponieważ potencjalny Klient z niego korzysta. Ale sugeruję małe spojrzenie na Axe jako warstwę nad narzędziem „koń roboczy”.

Jeśli musisz mieć dostęp do ramek iframe, okien dialogowych modalnych i międzydomenowych ramek iframe WatiN jest dobrym rozwiązaniem. Selen nie mógł obsłużyć ramek iframe, które generował wyjątki limitu czasu polecenia. WatiN, możesz zrobić o wiele więcej rzeczy, zwłaszcza jeśli strona korzysta z rzeczy specyficznych dla IE, takich jak ShowModalDialog itp. WatiN radzi sobie z nimi bardzo dobrze. Mógłbym nawet uzyskać dostęp do iframe między domenami.

Będziesz musiał zrobić jedno i drugie, jeśli chcesz przeprowadzić testy IE i FF, ale będą one działać tak dobrze tylko do testowania prezentacji. Nie potrafią wykryć, czy jeden element jest lekko uszkodzony, tylko że elementy są obecne. Nie znam niczego, co mogłoby zastąpić ludzkie oko w testowaniu interfejsu użytkownika / prezentacji, chociaż możesz zrobić kilka rzeczy, aby temu pomóc (zrób zrzuty ekranu stron na każdym kroku, aby użytkownicy mogli je przejrzeć).