Projektowanie zewnętrznej klasy do testów SoapUI

W poprzednim artykule opisałem krok po kroku w jaki sposób utworzyć i wczytać zewnętrzną klasę  pomocniczą do testów SoapUI. W kolejnym chciałbym omówić możliwości które ona nam daje, oraz omówić sposób w jaki powinniśmy podejść do projektowania takiego narzędzia do naszych testów.

Tak jak zdążyliście się pewnie przekonać czytając poprzedni artykuł, nasza klasa jest zbudowana na podstawie SoapUI API, które daje nam praktycznie nieograniczone możliwości edycji elementów naszego projektu.

Natomiast przy wykorzystaniu narzędzia jakim jest SoapUI – nie jest nam potrzebna aż taka pula funkcjonalności – stąd przed rozpoczęciem pracy nad taką klasą, zalecam mocno zastanowić się do czego tak naprawdę jej potrzebujemy.

Na samym początku powinniśmy zadać sobie pytania i znaleźć na nie odpowiedzi. Nie sztuką jest znaleźć funkcjonalność i zastosowanie do niej. Sztuką jest znać funkcjonalność i stwierdzić czy opłaca się ją wprowadzić. Stąd jeśli jest mała potrzeba automatyzacji przypadków testowych a utrzymanie kosztuje minimum czasu, nasze testy nie wymagają specyficznego podejścia do danych testowych – zdecydowanie bardziej opłaca się utrzymywanie samych przypadków testowych zamiast utrzymywania także narzędzia które je wspiera.

W momencie w którym jesteśmy pewni, że taka funkcjonalność jest nam potrzebna – powinniśmy wiedzieć już gdzie są słabe punkty naszych testów, i w których miejscach taka klasa mogła by je wesprzeć możliwie najlepiej – pamiętajmy także, że wprowadzenie takiego narzędzia do projektu testowego w zaawansowanym stadium także jest czasochłonne, powinniśmy to dokładnie wyestymować – uwzględniając czas na poprawki.

Z doświadczenia jestem w stanie wymienić kilka najbardziej przydatnych miejsc w których zastosowanie zewnętrznej klasy jest naprawdę pomocne i opłacalnie:

• Utrzymanie dużej ilości przypadków testowych
• Wymaganie dynamicznego zmieniania dużej ilości danych testowych
• Operacje na plikach wykorzystywanych w testach ( załączanie do request’a, edycja elementów wewnątrz)
• Optymalizacja kroków groovy (kroki te często zawierają powtarzalne fragmenty kodu które możemy wyciągnąć na poziom wyżej – do klasy zewnętrznej i tym samym spowodować, że nasz kod jest w jednym miejscu i jest reużywalny)
• Wymaganie użycia mechanizmów niewbudowanych do SoapUI (np. kodowanie / dekodowanie danych testowych)
• Jednorazowa edycja przypadków testowych
  • Przykład: Przy 240 przypadkach testowych, gdzie w każdym z nich co najmniej raz następuje tworzenie elementu na podstawie którego pozostałe kroki wykonują operacje zmiany statusów i sprawdzanie asercji – specyfikacja projektu zmienia się, ten krok zostaje zmodyfikowany, a jego asercje muszą zostać zastąpione nowymi.
    Musimy wykonać co najmniej 240 razy podobną operację, przy założeniu że jedna taka zmiana zajmie nam około 7 minut, dodane nam zostało około 1680 minut pracy – co daje nam 28 godzin, 3,5 dnia pracy bez przerwy. Napisanie metody która przejdzie przez cały projekt i wykona dla każdego kroku w projekcie sprawdzenie czy wymaga zmiany i jej ewentualne dokonanie, oraz uruchomienie jej, to około 2 godziny pracy, oraz ponad 3 dni więcej czasu na inne obowiązki i odrobinę odpoczynku.

Najważniejsze elementy na które należy zwrócić uwagę:

1. Upewnienie się że w łatwy i prosty sposób jesteśmy w stanie przekazać do niej elementy odpowiedzialne za operacje wykonywane na projekcie, które wymieniłem w poprzednim artykule (context, testRunner)
2. Zastosowanie wszystkich konwencji zgodnych z programowaniem obiektowym (enkapsulacja, dziedziczenie, reużywalność kodu etc.)
3. Rozdzielenie klas przez nas napisanych względem implementowanej funkcjonalności (generatory danych testowych, klasy do edycji plików, konwertery, modele testowe etc.)

Prawdopodobnie ww. rzeczy są oczywiste, ale i tak należy o nich wspomnieć – należy pamiętać, że zewnętrzną klasę trzeba utrzymywać i zawsze podmieniać – każdy musi mieć tą samą wersję dlatego zaleca się wersjonowanie – aby nie było wątpliwości czy problemy występują w czyimś projekcie, ponieważ nie ma odpowiedniej wersji, czy jest tam po prostu błąd.

Reasumując, jeśli klasa do testów zewnętrznych jest naprawdę potrzebna, należy się mocno zastanowić do czego. Z tą wiedzą powinniśmy podzielić te funkcjonalności na grupy i w ten sposób je zaimplementować tak aby ich późniejsze utrzymanie kosztowało nas jak najmniej czasu.

W następnym artykule zaprezentuję jak powinna wyglądać tak przygotowana biblioteka i jak wygląda jej zastosowanie. Pokażę także jak napisać i wykorzystać elementy klasy,  pokrywające obszary wymienione przeze mnie wcześniej, które najczęściej wymagają użycia takiego rozwiązania.

Chcesz lepiej zrozumieć aplikacje i systemy, które testujesz? Dołącz do ModernTester, poznaj najpotrzebniejsze narzędzia, frameworki oraz języki programowania i ćwicz na specjalnie przygotowanych środowiskach testowych: Platforma e-learningowa ModernTester