Dzisiaj zabrałem się za naukę PhpUnit i mam problem. O ile napisanie testów jest zazwyczaj dość proste i w sumie nie sprawia mi problemów o tyle mam problem z niektórymi testami. Problem polega na tym, że w zasadzie nie wiem jak bym mógł napisać sensowne testy.

Weźmy na przykład mój mały projekcik, który w skrócie pozwala na obrazki nakładać różne filtry (np. resize, b&W itp) i na końcu konwertować je do postaci base64. W tym projekcie mam taką klasę:
https://gitlab.com/hadwao/image-inliner/blo...der/Encoder.php, która można powiedzieć, że jest takim hubem, który korzystając z kilku dependencji przekształca wykonuje całą pracę z przekształceniem obrazka wyjściowego na wersję baser64.


Problem polega na tym, że o ile dobrze zrozumiałem zasadę, to wszystkie dependencje powinienem mockować. Jeśli w tej klasie zmockuje zależności, to w zasadzie okażę się, że nie ma czego tutaj testować, bo sama metoda to po prosu kolejne wywołania metod ze wstrzykniętych zależności. Przyznam szczerze, że trochę tutaj utknąłem i nie mam pomysłu na napisanie testów dla tej klasy.

PS znacie jakiś mały projekt z dobrze napisanymi testami? Chętnie bym popatrzył jak to się robi, ale nie mogę znaleźć niczego na tyle małego aby móc szybko się wgryźć w logikę.

Zanim odpowiem to szybka uwaga:

[PHP] pobierz, plaintext 
protected function validateData(array $data)
    {
        foreach (array_keys($data) as $key) {
            if (!in_array($key, static::EXPECTED_KEYS)) {
                unset($data[$key]);
            }
        }
 
        if (count($data) != count(static::EXPECTED_KEYS)) {
            throw new \InvalidArgumentException();
        }
    }
 
[PHP] pobierz, plaintext 

Mozesz to skrocic juz do:

[PHP] pobierz, plaintext 
protected function validateData(array $data)
    {
        foreach (array_keys($data) as $key) {
            if (!in_array($key, static::EXPECTED_KEYS)) {
                throw new \InvalidArgumentException();
            }
        }
 
    }
 
[PHP] pobierz, plaintext 

Co do pytania:
- mozesz przetestowac czy twoje obiekty zostaly wywolane w okreslonej kolejnosci i zadana ilosc razy. Generalnie nie lubie takiej metody ale tutaj faktycznie malo jest do testowania
- mozesz tez sprawdzic czy zwrocony obiekt zawiera te dane:

[PHP] pobierz, plaintext 
$inlineImageData = [
            'data_url' => (string)$image->encode('data-url'),
            'profile' => $this->profile->getName(),
            'height' => $image->height(),
            'width' => $image->width(),
            'path' => $imagePath,
            'orig_width' => $origWidth,
            'orig_height' => $oriHeight
        ];
[PHP] pobierz, plaintext 

Przegladajac kod widze ze moglbys to sprawdzic

Troche problematyczny jest ten kawalek

[PHP] pobierz, plaintext 
 foreach ($this->profile->getFilters() as $profileFilter) {
            $imageFilter = $this->filterFactory->create($profileFilter->class());
            $imageFilter->execute($image, $profileFilter->config());
        }
[PHP] pobierz, plaintext 

Gdzie zamiast przekazac obiekty filtrow ty przekazujesz ich nazwy i twoja klasa wewnatrz siebie tworzy je samodzielnie

ps: zainteresuj sie php-cs-fixer. Przegladajac twoj kod mam wrazenie ze pisza go przynajmniej dwie rozne osoby - strasznie rozny styl formatowania, czesto daleki od PSR. Az dziw bierze ze jedna osoba moze tak roznie pisac... rozdwojenie jazni?

Dzięki za rady, jutro do tego usiądę i spróbuję zastosować w praktyce.



Do niedawna byłem zupełnym hobbystą - dopiero jak zacząłem myśleć o szukaniu pierwszej pracy w IT(pół roku temu) spotkałem się z kolegą z forum aby rzucił okiem na mój kod i uświadomił mnie o istnieniu PSR, clean code i kilku innych "pierdołach" To rozdwojenie jaźni to "szukanie drogi" + brak wyrobionych nawyków + naturalna skłonność do robienia chaosu . Teraz już jest trochę lepiej bo pracuję nad tym tematem no i używam już cs-fixera ;-)

A po kodzie tego nie widac. Fixer powinien poprawic to i owo w nim. Jestes pewien ze uzywasz czy moze masz tylko w requite-dev ?

W sensie teraz już używam od jakichś 2-3 tygodni ;-)
Libka powstawała jakoś w grudniu i wtedy jeszcze nie używałem.

Dlatego w wielu projektach nie wymaga się otestowania na poziomie 100%, testy jednostkowe są szczególnie przydatne jeśli mamy jakąś współdzieloną bibliotekę, która ma sporo logiki, stabilny interfejs i tak dalej - w przypadku jednak często zmieniających się kontrolerów aplikacji webowej, z których 90% tylko przekazuje dane z repozytoriów do templatek testy jednostkowe słabo się sprawdzają.

Trzeba też pamiętać, że testy jednostkowe mają nie tylko testować kod, ale wymuszać dobre praktyki (TDD/TBD), wykrywać fragmenty martwego kodu i w końcu (moim zdaniem największa zaleta) gwarantować, że zmiany w kodzie będą dokonywane w sposób świadomy i zorganizowany a nie tylko proteza, workaround, wklejka tysiąca linii by użyć jednej metody itp.