Wprowadzenie do ATDD

ATDD czyli Acceptance Test-Driven Development w zasadzie nie polega na testowaniu, ale na komunikacji, współpracy oraz przejrzystości. Bardzo często dochodzi do sytuacji, kiedy wymagania zostają źle zrozumiane. Metody Agile próbują sobie radzić z tym faktem przez pracę z wykorzystaniem historyjek i tworzenie oprogramowania metodą małych kroków. Oczywiście w pewnym stopniu to bardzo pomaga, jednak istotą jest aby wszelkiego typu problemy wyłapać jak najszybciej. Praca z wymaganiami odbywa się na wielu płaszczyznach ponieważ pracują z nimi klienci, udziałowcy, właściciele produktów, programiści, testerzy, wszyscy w innym środowisku z innymi obawami i wątpliwościami.

Tradycyjny sposób podejścia do zbierania wymagań jest dla właściciela produktu kwestią do dyskusji ponieważ zależy mu, aby zespół tworzący produkt zadawał takie pytania żeby rozwiać wszelkie wątpliwości, a końcowy efekt ich pracy realizował zakładane funkcjonalności. Programiści zawsze oczekują jasnego przekazu, naturalnym jest że żądają odpowiedzi na to czego nie są pewni i na to czego nie wiedzą. Jednak to co powoduje największe problemy to pytania, których nikt nie zadaje ponieważ na daną chwilę nie wie że nawet takie istnieją. Pytania będą zadawane, ale tylko o rzeczy których programiści wiedzą, że nie wiedzą. Tu rodzi się największy problem.

ATDD jest sposobem wywołującym brakujące pytania. Koncepcyjnie wygląda to dość prosto. Właściciele produktu, programiści oraz testerzy dyskutują nad wymaganiami, po pierwsze pytając co jest potrzebne, ale w dalszej kolejności zadając pytanie: “Skąd będziemy wiedzieć, że dobrze to zrobiliśmy?”. Rozmowa tworzy konkretne odpowiedzi. Odpowiedzi natomiast przybierają formę testów akceptacyjnych. Testy akceptacyjne powstają dzięki rozmowie oraz współpracy. Dużą zaletą ATDD jest posiadanie testów akceptacyjnych nim powstanie nawet jedna linijka kodu aplikacji. Dzięki dużemu zaangażowaniu wszystkich osób przed napisaniem kodu unikamy nieporozumień, co oczywiście również wymaga odpowiedniego nakładu pracy.

Behat – instalacja i pierwszy test

Automatyczne testowanie oprogramowania przy pomocy Behat oraz metodyki BDD.

Behat jest narzędziem pozwalającym na stosowanie behavior driven development (BDD). Jak już wspominałem we wcześniejszym artykule BDD polega na pisaniu czytelnych historii dla człowieka opisujących zachowanie aplikacji. Implementując stworzone historie uzyskamy automatyczne testy dla funkcjonalności tworzonej aplikacji. Warto wspomnieć, iż inspiracją do stworzenia narzędzia Behat był projekt Ruby Cucumber i wiele rozwiązań jest z niego zaczerpniętych dzięki czemu sam projekt oferuje wiele możliwości w zakresie automatyzacji testów. Testowanie oprogramowania bez automatyzacji choć najważniejszych funkcjonalności w dzisiejszych czasach jest podejściem karkołomnym, stąd gorąco zachęcam do zapoznania się z cyklem artykułów na temat BDD oraz narzędzi umożliwiających jego zastosowanie.

W artykule przedstawię instalację Behat wraz z pierwszą historyjką, którą poddamy automatyzacji. Do dzieła!

Polecenia Behat wykonywane są z linii poleceń, ważne jest aby sprawdzić przed instalacją czy posiadana wersja PHP jest w wersji co najmniej 5.3.1.

Instalacja Behat

Najwygodniejszą metoda instalacji jest instalacja przy pomocy Composera.

1. W katalogu projektu tworzymy plik composer.json:

 2. Pobieramy composer.phar oraz przeprowadzamy instalację pakietów z pliku composer.json.

$ curl http://getcomposer.org/installer | php
$ php composer.phar install

3. W celi zainicjowania projektu należy wykonać komendę:

$ bin/behat –init

W wyniku wykonania powyższej komendy utworzony zostanie katalog features, w którym trzymane będą scenariusze oraz stworzona zostanie klasa FeatureContext.php, w której będziemy implementować poszczególne kroki testowe.wykonanie polecenia behat

Automatyzujemy przykładowy test

1. Pierwszy scenariusz

Pierwszą rzeczą, którą należy zrobić to nazwać plik feature, w którym umieścimy scenariusz. Na potrzeby artykułu stworzyłem plik ls.feature w katalogu /features. Zadaniem przykładowego testu będzie skoncentrowanie się na wartości biznesowej jaką stanowi komenda “ls” w systemie Linux.

Definicja feature

 Każdy feature zaczyna się w taki sam sposób czyli nazwa, a następnie opis korzyści, rolę oraz samą funkcjonalność czyli w tym wypadku polecenie “ls”. Dla samego Behata wpis ten jest bez znaczenia, jednak są to bardzo istotne elementy w przypadku kiedy z opisem danego pliku feature zapoznają się inni ludzie.

Definicja scenariusza

Z biznesowego punktu widzenia treść scenariusza może wyglądać następująco:

Jeśli posiadamy dwa pliki w katalogu i uruchomimy komendę “ls” wówczas zobaczymy listę plików znajdujących się w bieżącym katalogu.

Bazując na powyższym opisie dodamy scenariusz testu w pliku ls.feature:

Każda cecha jest określona przez jeden lub więcej “scenariuszy”, wyjaśniające w jaki sposób funkcja powinna działać w różnych warunkach. Jest to część, która zostanie przekształcona w teście. Każdy scenariusz zawsze zawiera ten sam format podstawowy:

 W wariancie rozszerzonym mogą jeszcze dojść kroki And oraz But:

 Będąc w katalogu projektu wykonamy polecenie, które podpowie nam jakie poszczególne kroki musimy zaimplementować w klasie FeatureContext.php.

$ bin/behatszablon kroków do implementacji

Implementacja kroków testowych

Behat automatycznie wyszukuje w katalogu feature plik ls.feature oraz próbuje wykonać jego scenariusz jako test.

Implementacja poszczególnych kroków wygląda następująco:

Po uzupełnieniu metod wydajmy ponownie komendę:

$ bin/behaturuchomienie stworzonych kroków

Doskonale, test przechodzi a więc polecenie “ls” działa zgodnie z jego przeznaczeniem.

Jednak zaprezentowane rozwiązanie posiada pewną wadę, otóż kiedy będziemy chcieli wykonać ponownie test pojawi się informacja, że katalog tworzony w jednym z kroków już istnieje. W celu rozwiązania tego problemu możemy dodać krok, który przywróci po teście warunki początkowe.

 Natomiast to co znajdowało się __construct przenieśmy do nowej metody:

 Dzięki tzw. haczykom metody z @BeforeScenario będą tworzyć warunki początkowe dla testu, a @AfterScenario będą przywracać stan sprzed wykonania testu.

Ciągła integracja dla aplikacji iOS

Testowanie aplikacji mobilnych to nie tylko testy manualne czy automatyczne, wpływ na jakość mają również różnego rodzaju procesy. W artykule przedstawię w jaki sposób można zautomatyzować budowanie aplikacji na platformę iOS. Z pewnością wiele osób spotkało się z potrzebą dopisania wielu dodatkowych funkcjonalności do aplikacji, czasami do projektu dołączały nowe osoby. Kod aplikacji rósł zaczęły pojawiać się problemy z jakością czy integracją całości. Są to typowe problemy, które występują w wielu zespołach programistycznych.

Z pomocą przychodzi ciągła integracja (ang. Continuous Integration) powszechnie używany skrót CI. Jest to nic innego jak proces przeprowadzania ciągłej kontroli jakości podczas cyklu życiowego projektu. W tradycyjnym podejściu sprawdzenie aplikacji oraz jej przetestowanie odbywa się raz na jakiś czas co może prowadzić do występowania częstych problemów w utrzymaniu wysokiej jakości. Jednak w przypadku zespołów używających CI testy przeprowadza się praktycznie nieustannie, na bieżąco cały zespół uzyskuje informację, że integracja nie powoduje błędów. Dzięki CI również mamy pewność, że aplikacja budowana jest zawsze w jednakowy odpowiedni sposób, a testy wykonywane są na prawidłowo skonfigurowanym środowisku, które powinno być zbliżone do środowiska produkcyjnego.

Obecne rozwiązania CI oferują wsparcie dla pełnej automatyzacji testów, niezależnie czy to będą testy jednostkowe, akceptacyjne czy wydajnościowe. Najczęściej oprogramowanie CI zainstalowane jest na serwerze i skonfigurowane w taki sposób, aby powiadamiać programistów, kiedy ich kod powoduje uszkodzenie budowanej aplikacji.

W artykule przedstawię podstawową instalację oraz konfigurację serwera CI opartego o bezpłatną aplikację Jenkins. Jenkins po uruchomieniu builda będzie pobierać kod źródłowy aplikacji, a następnie go kompilować. W przypadku braku błędów aplikacja zbuduje się poprawnie, oczywiście w przypadku pojawienia się błędów zostaniemy o tym powiadomieni.

Jenkins jest aplikacją napisaną w Javie, posiada interfejs który obsługuje się przy pomocy przeglądarki internetowej, wykorzystuje on również interfejs skryptowy powłoki oraz bardzo bogatą bibliotekę wtyczek.

Pobierz aplikację Jenkins z witryny http://jenkins-ci.org. Aplikacja dostępna na platformę MAC OS X znajduje się pod linkiem http://mirrors.jenkins-ci.org/osx/latest.

Po kliknięciu w plik instalacyjny pojawi się ekran powitalny.
Kliknij Dalej na kolejnym ekranie kliknij Dostosuj.jenkins dostosuj instalację
Odznacz uruchamianie Jenkinsa jako daemon, następnie kliknij Dalej w celu instalacji aplikacji.

Po instalacji zostanie uruchomiona przeglądarka z adresem Jenkinsa http://localhost:8080. Ponieważ jednak wyłączyliśmy automatyczne uruchamianie aplikacji należy przejść w Finderze do Programy i tam w folderze Jenkins kliknąć dwa razy plik jenkins.war. Po odświeżeniu adresu w przeglądarce zobaczymy poniższy ekran.ekran powitalny jenkinsa

Kolejną rzeczą jest instalacja niezbędnych wtyczek. Kliknij w Manage Jenkins, a następnie w Zarządzaj dodatkami. W wyszukiwarce znajdź dwa pluginy Bitbucket Plugin oraz Xcode integration. Pierwszy z nich umożliwia integrację z repozytorium git zainstalowanym na https://bitbucket.org/, drugi jak sama nazwa wskazuje umożliwia integrację Jenkinsa z Xcode. Po ich instalacji należy przeładować aplikację.instalacja pluginów w jenkinsie

W kolejnym kroku klikamy w New Item podajemy nazwę np: iOS APP i wybieramy Freestyle project.dodawanie nowego joba

Na ekranie głównym zobaczymy poniższy ekran. Po najechaniu myszką na nazwie iOS APP pojawią się dodatkowe opcje należy kliknąć Konfiguruj.konfiguracja

W opcji Repozytorium kodu źródłowego należy podać dane do repozytorium, gdzie trzymany jest kod źródłowy aplikacji.konfiguracja git

W opcji Advanced Xcode build options należy jeszcze ustawić dla SDK odpowiedni symulator.konfiguracja pluginu xcode

Po dodaniu ustawień należy kliknąć Zastosuj oraz Zapisz. Po powrocie do dashboard klikamy w ikonkę z zielonym znaczkiem play.jenkins_7

Podczas budowania aplikacji możemy przejść do konsoli z logami, aby podejrzeć co konkretnie w danej chwili jest wykonywane. Widać na poniższym zrzucie, że otrzymaliśmy ** BUILD SUCCEEDED **  Finished: SUCCESS.logi konsoli jenkinsa

W dashboardzie zobaczymy również ikonkę słoneczka sygnalizującą poprawne zbudowanie się aplikacji, w przypadku braku powodzenia ikonka będzie zawierać chmurki.niepowodzenie w buildzie

Oczywiście opis, który przedstawiłem jest totalnym minimum co musimy zrobić, aby wdrożyć proces ciągłej integracji. Sam temat jest bardzo obszerny również jeśli chodzi o obsługę aplikacji Jenkins bowiem oferuje ona uruchamianie wielu opcji. Możemy skonfigurować automatyczne uruchamianie testów jednostkowych, funkcjonalnych (np: Appium), możemy ustawić budowanie aplikacji o danej godzinie oraz wiele wiele innych usług, które przełożą się na jakość budowanej aplikacji.