O unit testach i testach funkcjonalnych

Dziś w prostych słowach o unit testach i testach funkcjonalnych w kontekście frameworka Symphony.
Jest taka biblioteka PHPUnit, która jest standardem do zapoznania się jeżeli chodzi o testowanie Symphony2 i powinna być wykorzystywana we wszystkich tworzonych projektach z Symphony2.

UNIT TESTY

Unit testy koncentrują się na zbadaniu poprawnego wywołania pojedynczej funkcji bez wywoływania innej funkcji (z tego samego testowanego projektu) – chodzi o to żeby nie wywoływać innej funkcji, bo nie wiadomo będzie która źle się wykona. W obiektowym kodzie, takim jak Symphony2, testowanie obejmuje klasę i jej metody. Przy pisaniu unit testów dane przypadki testowe powinny być zapisywane niezależnie od innych przypadków testowych, tzn. wynik testu B nie powinien zależeć od wyniku testu A. Taki sposób jest użyteczny przy tworzeniu tzw. mock obiektów, które w łatwy sposób sterują funkcjami testowymi. Mocking pozwala na symulowanie wywołania funkcji, zamiast jego wykonania. Przykładem byłoby testowanie klasy, która pokrywa zewnętrzny interfejs API. Taka klasa API może używać warstwy transportowej do komunikacji z zewnętrznym interfejsem API. Można zasymulować metodę żądania warstwy transportowej, aby zwrócić podane wyniki, a nie faktycznie wywoływać zewnętrzny interfejs API. Unit testy nie sprawdzają, czy składniki aplikacji działają prawidłowo, bo to sprawdzają testy funkcjonalne.

TESTY FUNKCJONALNE

Testy funkcjonalne sprawdzają integrację różnych elementów aplikacji, takich jak routing, kontrolery i widoki. Testy funkcjonalne są podobne do testów ręcznych, które można uruchomić w przeglądarce, np. kliknięcie na jakieś łącze i sprawdzenie czy pojawił się właściwy widok. Testy funkcjonalne umożliwiają zautomatyzowanie tego procesu.

Symfony2 zawiera wiele użytecznych klas wspomagających testy funkcjonalne obejmujące klasę Client, która jest w stanie zażądać stron i przesyłać formularze oraz DOM Crawler, które możemy wykorzystać do śledzenia odpowiedzi klienta.

Kolejnym ważnym tematem do zapoznania się przy testowaniu są procesy używające powyższych testów, takie jak Test Driven Development (TDD) i Behavioral Driven Development (BDD).

Napisanie unit testów i testów funkcjonalnych, moim zdaniem pozwala na oszczędzeniu jednego etatu w firmie – dla testera 🙂 Dodatkowo przy każdej zmianie w kodzie wcześniej napisane testy są ponownie wywoływane i najczęściej wykazują błędy niezauważone przez programistę.

Więcej o PHPUnit : https://phpunit.de/

Na początku nie doczytałam do czego służy ten SplitViewController, myślałam że będę miała od razu wysuwane menu, które przerobię na własną wizję. Niestety nie da się – chciałam dodać ToolBar, a tu się wysypuje. Po doczytaniu SplitViewController rozdziela 2 widoki: oddzielny na widok poziomy a oddzielny na poziomy. Oczywiście w zależności od urządzenia. W związku z tym przerabiam na zwykły StoryBoard, czyli zwykłą aplikację z tym samym widokiem dopasowującą się do rozdzielczości ekranu.

Po zostawieniu tylko UITableViewController jako inicjującego kontrolera, podpięłam rozwijane menu i StatusBar z biblioteki CosmicMind, ale nie mogłam podpiąć się pod przycisk rozwijanego menu ani pod przycisk menu, pomimo programowego przypięcia akcji:

newFABMenuItem.fabButton.addTarget(rootViewController, action: #selector(handleNewFABMenuItem(button:)), for: .touchUpInside)

Wydaje mi się, że problemem jest TableViewController, którego deklarację mogę zapisać tak:

class MasterViewController: UITableViewController==

class MasterViewController: UIViewController, UITableViewDataSource, UITableViewDelegate

Nie wiem jak przechwycić zdarzenie z buttona i wskazać TableViewControllera jako delegata, ponieważ lekko zagmatwana dla mnie jest hierarchia w bibiotece Material (Cosmic Mind).

Jak widać powyżej będzie możliwość wyszukiwania, ale muszę się zastanowić co klient w pierwszej kolejności chce widzieć: nazwę sklepu, czy nazwę towaru który kupił? Po wejściu w szczegóły będzie miał możliwość na danych już wprowadzonych dodać kolejny dokument.