Jak pisać testy na selen (lub podobny), które nie zawiodą z powodu drobnych lub kosmetycznych zmian?

Spędziłem mniej więcej ostatni tydzień ucząc się selenu i opracowując serię testów internetowych dla witryny, którą zamierzamy uruchomić. świetnie się uczyłem i wybrałem techniki lokalizacji xpath i css.

Problemem jest dla mnie to, że niewielkie zmiany psują testy - każda zmiana na div, id lub inny numer autoid, który pomaga zidentyfikować widżety, przerywa dowolną liczbę testów - wydaje się po prostu bardzo krucha.

więc napisałeś testy selenu (lub innych podobnych) i jak sobie radzisz z kruchością testów (lub jak je powstrzymać) i do jakich testów używasz selenu?

testing selenium

— Sam J
źródło

Jeśli niewielkie zmiany psują testy, to testy nie są uruchamiane po ich wprowadzeniu - co jest sednem testów. Ponadto wydaje się, że brakuje świadomości programistów na temat (istnienia) testów.

— talonx,

@talonx - nie wystarczy po prostu przeprowadzić tego rodzaju test, jeśli niewielka zmiana spowoduje dużą zmianę w pakiecie, będzie to problematyczne bez względu na to, czy są one uruchamiane przez programistę, ci box czy testerów

— FinnNk

@FinnNK: Zgadzam się - małe zmiany nie powinny powodować dużych zmian. Oznacza to, że przypadki testowe zostały napisane przez kogoś, kto nie ma kontaktu z programistami wprowadzającymi zmiany - pachnie jak przerwa komunikacyjna.

— talonx,

@talonx: Testy interfejsu użytkownika są z natury kruche i trwają o wiele dłużej niż testy jednostkowe. Są szczególnym wyzwaniem, więc nie wyciągnę pochopnych wniosków na temat programistów w organizacji @ Sam.

— azheglov

Zmieniłem tytuł - mam nadzieję, że trochę bardziej reprezentatywny dla pytania i trochę mniej negatywny.

— Jon Hopkins

Odpowiedzi:

Celem Selenium jest tworzenie testów integracyjnych opartych na interfejsie użytkownika .

Testy integracyjne sprawdzają, czy wszystkie składniki systemu działają poprawnie, jeśli są wdrażane razem. Testy integracyjne nie są wystarczające strategia testowania i uzupełniać inne strategie badań mających inną ostrość, na przykład unit-testów i testów akceptacyjnych .

Testy oparte na interfejsie użytkownika są z natury kruche, chociaż Selenium i Watir są krokiem naprzód w stosunku do wczesnych lat narzędzi do nagrywania i odtwarzania . Istnieje kilka sposobów poradzenia sobie z tym problemem - oto zbiór porad niektórych światowej klasy ekspertów:

Nie próbuj uzyskać pełnego zasięgu testu z tego typu testów . Robert C. Martin argumentuje, że Twój zasięg kodu w testach integracyjnych powinien wynosić około 20% . Testowanie wszystkich ścieżek wykonania, gdy wejście znajduje się w odległości kilku warstw aplikacji, jest po prostu niepraktyczne.

Uzyskaj większość pokrycia testowego z testów jednostkowych i akceptacyjnych . Poszukaj linków do artykułów Gojko Adzica w odpowiedzi FinnNk . Adzic wielokrotnie argumentował na temat testowania logiki biznesowej poprzez testy akceptacyjne i omijanie interfejsu użytkownika.

Ale pewna ilość testów opartych na interfejsie użytkownika wciąż wymaga napisania . Tutaj potrzebujesz praktycznych porad oprócz „nie testuj logiki biznesowej za pomocą interfejsu użytkownika”. Jako punkt wyjścia poleciłbym blog Patricka Wilsona-Welsha .

— azheglov
źródło

Link do patrickwilsonwelsh.com nie działa, a inne zasoby do tego .. !!

— MarmiK

Najważniejszą rzeczą przy tworzeniu takich testów po przekroczeniu trywialnej liczby jest pomysł zmiany symetrycznej - niewielka zmiana w kodzie powinna spowodować niewielką zmianę w zestawie testów.

Załóżmy na przykład, że zbieracie czyjeś imię z dwoma polami tekstowymi w 100 testach. Jeśli napiszesz te testy w sposób ciągły (a może używasz odtwarzania nagrań), będziesz mieć 100 testów do zmiany. Jeśli zamiast tego wyodrębnisz krok „wprowadź nazwę” i użyjesz go w testach zamiast bezpośrednio używać selenu, masz tylko 1 miejsce na dokonanie zmiany. Będzie to zależeć od twojego kontekstu, ile warstw abstrakcji używasz - ale użycie abstrakcji znacznie przyczyni się do utrzymania testów w utrzymaniu.

Drugą ważną rzeczą jest upewnienie się, że selektory są oparte na rzeczy, która jest najważniejsza i najmniej prawdopodobna do zmiany. Czasami będzie to identyfikator lub klasa lub może to być tekst w lub otaczający element. Zawsze preferuj najprostszy selektor (np. Identyfikator), ale czasami aby to osiągnąć, będziesz musiał użyć czegoś takiego jak xpath.

Gojko Adzic ma wiele świetnych porad na swoim blogu, jeśli chodzi o tego rodzaju testy - sprawdź jego Sinus śmierci, a w szczególności, jak tego uniknąć .

— FinnNk
źródło

dobre wskazówki FinnNk - Wyodrębniłem popularne metody (logowanie, szukanie widżetów na pasku bocznym itp.) - więc obrażenia są zmniejszane, gdy testy się zmieniają. Niestety używamy systemu poprawności, który tworzy niektóre widżety i tworzy identyfikatory dla widżetów na podstawie ich pozycji w domenie, więc za każdym razem, gdy coś jest przenoszone, testy są przerywane.

— Sam J

Zwykle można znaleźć sposób na identyfikację elementu - być może jakiś tekst, który ten element zawiera, a może zawsze ma taką samą relatywną pozycję do czegoś innego. Wreszcie, w ostateczności, możesz również zdefiniować niestandardowe strategie lokalizacyjne do lokalizowania elementów za pomocą selenu, co daje pełną kontrolę (np. Jeśli szukasz elementów o nazwie podstawowej i niektórych dowolnych dodatków dodanych na końcu, jak w twoim case lub w formularzach internetowych asp.net).

— FinnNk,

Testowanie zapewnia, że kod zachowuje się zgodnie z oczekiwaniami. Jeśli testy psują się regularnie, to albo testy nie sprawdzają się dobrze, albo programiści nie dbają o testy.

Osobiście uważam, że jeśli obecność <div>tagu przerwie test, wówczas test jest niepotrzebnie ściśle zależny od otaczających tagów i należy zastosować łagodniejsze podejście.