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?
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 .
źródło
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ąć .
źródło
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.źródło