Jak rozpocząć projekt z użyciem Composera i PHPUnit

Powinniśmy mieć czas i pieniądze na testy tworzonego przez nas kodu, dlatego dziś pokażę Wam, jak przetestowałem kod w projekcie z użyciem Composer’a i PHPUnit. Wartą uwagi techniką pisania testów jest TDD (Test-driven development), która składa się z trzech cykli: red, green i refactor. Najpierw piszemy test, w którym oczekujemy, że nasz docelowy skrypt będzie zwracał, potem go piszemy. Na samym końcu poprawiamy jego wydajność i staramy się zoptymalizować.


Sławomir Kaleta. Full Stack Developer w firmie Web24.com.pl sp. z.o.o. Współtwórca wielu projektów open source, między innymi silnika templatek: SMARTY oraz interpretera php: PHP-SRC. Github.com to jego drugi dom. Posiada 10 letnie doświadczenie w programowaniu oraz 6 letnie administracji systemami. Współpracował z takimi stacjami jak TVN oraz TTV w przygotowaniu programów o tematyce niebezpieczeństw związanych z kradzieżą danych, manipulacjami i wyłudzeniami.


Definicje:

Composer

To narzędzie pozwalające na łatwe zarządzanie zależnościami między bibliotekami w projekcie. Kiedyś pobierało się paczki ze skryptem, który był nam potrzebny, a teraz Composer robi to za nas za pomocą jednego polecenia.

Composer wprowadza pewne standardy grupy ludzi promujących się pod nazwą PHP-FIG — PHP Framework Interop Group (więcej na jej temat możecie przeczytać na php-fig.org). Grupa ta stała się na tyle duża, że część programistów zaczęła uznawać i przestrzegać te (nieoficjalne) standardy. Wynikiem tego dzieła jest bardzo miła spójność kodu u różnych osób. Między innymi standard PSR-4 (następca PSR-0), który stosuje Composer. Wszystkie instrukcje instalacji oraz konfiguracji composera można znaleźć pod adresem Getcomposer.org – Download.

PHPunit

Najpopularniejsze narzędzie do wykonywania testów jednostkowych. W zasadzie framework, który (w wielkim skrócie) sprawdza, czy nasz wynik jest równy naszym oczekiwaniom.


Projekt

Gdy już przejdziemy proces instalacji musimy mieć jakąś podstawę, dlatego przy użyciu konsoli w naszym katalogu (np. htdocs) powinniśmy uruchomić polecenie:

Rozpocznie to w tym przypadku proces instalacji szkieletu projektu Dframe. Na jego przykładzie przygotujemy własną paczkę, którą będzie można w podobny sposób instalować.

Gdy uruchomione polecenie zakończy się, pojawią się nam pliki w katalogu. Jeśli nie masz np. xampa do uruchomienia Apache2, w konsoli z pomocą php wpisz polecenie:

Dzięki temu uruchomi nam to web-server, więcej na ten temat znajdziesz na PHP Manual – webserver. Gdy wszystko zrobimy poprawnie pod adresem http://localhost:8080 znajdziemy nasz projekt.

Composer.json

Teraz przejdźmy do kodu. By wszystko działało poprawnie musimy mieć załadowany plik vendor/autoload.php. Odpowiada on miedzy innymi za załączenie do naszego projektu odpowiednich bibliotek.

W naszym projekcie jest ona includowana w pliku web/index.php. W folderze projektu znajduje się plik composer.json, który co prawda jest już uzupełniony, jednak dla własnych potrzeb trzeba go zmodyfikować.

Package Name – każdą przygotowaną paczkę można umieścić w serwisie packagist.org który zajmuje się jedo dystrybucją
Autoload – to standard zajmujący się autoloaderem, dzięki któremu możemy cieszyć się prostotą używania narzędzia przedstawionego w tym artykule. Różne rodzaje paczek również znajdziemy na packagist.org

Instalacje paczek można wykonać poprzez konsole. Jeśli w naszej paczce chcielibyśmy użyć np. PHPMailer — popularnej biblioteki do obsługi maili — musimy w konsoli wpisać:

W ten sposób w projekcie możemy już go używać. Dla przykładu w pliku app\Controller\Page.php w metodzie index()

Testy jednostkowe

PHPUnit — instalacja testów nie jest potrzebna na produkcji, dlatego w pliku composer.json mamy możliwość instalacji określonych paczek tylko na serwerze testowym.

W projekcie mamy już zainstalowany PHPUnit, ale gdybyśmy chcieli użyć go w innym projekcie, instalacje PHPUnit możemy wykonać za pomocą polecenia.

Jak wspomniałem wcześniej, ciekawą techniką pisania testów jest TDD (Test-driven development). Składa się on z 3 cykli: red, green i refactor. To znaczy najpierw piszemy test, w którym oczekujemy, że nasz docelowy skrypt będzie zwracał, potem go piszemy. Na samym końcu poprawiamy jego wydajność i staramy się zoptymalizować.

Poniższa grafika przedstawia ten proces.

W przykładowym zadaniu mamy polecenie, by napisać prosty kalkulator, który będzie zwracał nam wynik.

Rozpoczynamy więc od napisania naszego testu. W naszym projekcie mamy folder app/Tests/, który z reguły powinien się znajdować poza folderem app, jednak w tym przypadku mamy wyjątek. W podanym powyżej folderze stwórzmy plik o nazwie MyTest.php dla PHPUnit — ważne, by w nazwie była końcówka …Test.php.

W powyższy oto sposób napisaliśmy test dla skryptu, który jeszcze nie istnieje i po uruchomieniu w konsoli poniższego polecenia powinniśmy otrzymać negatywny jego wynik.

Red – Test mamy gotowy i jego wynik jest prawidłowy, gdyż pierwszy test nigdy nie może się udać z uwagi na brak danej klasy. Skoro jej nie mamy, to czas ją napisać. Jak to zrobić?

1. Stwórzmy plik app/Libs/MyLib.php

2. Teraz ponownie uruchamiamy polecenie

Green — Po zakończeniu powinniśmy uzyskać pozytywny wynik.

Refactory — W kolejnym kroku można byłoby poprawić kod, dodając walidacje wprowadzanych wartości.

Podsumowanie

Testy są bardzo ważne i choć wiele osób ich nie docenia, w dłuższym czasie naprawdę sprawdzają się. Potrafią zaoszczędzić sporo nerwów i czasu w przyszłości. Jeśli w firmie, w której pracujesz nie ma jeszcze testów, to warto zarzucić pomysł, bo podstawowych testów można nauczyć się w kilka godzin. Nie musisz też pisać od razu testów do wszystkiego, możesz je wdrażać stopniowo. Jeśli spotkasz się z wymówką, że brakuje na to funduszy to pomyśl, ile czasu się poświęca na CodeReview.


Bibliografia

https://getcomposer.org/doc/
https://dframeframework.com/en/docs/dframe/master/installation/overview
https://cheesecakelabs.com/blog/tdd-mobile-dev-matter-timing/
http://www.jamesshore.com/Blog/Red-Green-Refactor.html
https://pl.wikipedia.org/wiki/Test-driven_development
http://agiledata.org/essays/tdd.html

Zapraszamy do dyskusji

Patronujemy

 
 
More Stories
Jak działają map, filter i reduce w JavaScript?