Weryfikacja stanu obiektu gdy stan nie jest ujawniony

 

Spotkałem się ostatnio z ciekawym przypadkiem weryfikowania wyniku testu jednostkowego. Testowaniu została poddana void'owska metoda Agregatu i nijak nie można było wyciągnąć na zewnątrz stanu obiektu, który powinien ulec zmianie w wyniku wywołania metody under test, by można było go zweryfikować z oczekiwaniami. Agregat nie posiadał powiązanych z tym stanem getter'ów, wygenerowane event'y nie mogły zostać jawnie zwrócone poza obiektu (\Prooph\EventSourcing\AggregateRoot tego nie udostępniał) i żadna inna metoda jakkolwiek nie wyrzucała stanu na zewnątrz. Dodanie takich funkcji na siłę, tylko na potrzeby wykonania testu jednostkowego wydawało się nadużyciem więc też takie rozwiązanie nie wchodziło w grę.

Przez powyższe problemy, trzeba było wykazać się pomysłowością by napisać test - kolega z zespołu wpadła na takie oto rozwiązanie:

public function test(): void
{
    $objectUnderTest = new Person('Jan', 'Kowalski');

    // When
    // ...

    Closure::fromCallable(function () {
        TestCase::assertSame('Jan', $this->firstName);
        TestCase::assertSame('Kowalski', $this->lastName);
    })->bindTo($objectUnderTest, Person::class)();
}

Gdy pierwszy raz zobaczyłem takie podejście byłem zaskoczony że tak się da, zaraz potem uznałem że tak nie powinno się robić. Tyle raz powtarzano, że testowaniu powinno podlegać jedynie publiczne API obiektu, a jego wewnętrzny stan powinien zostać w ukryciu... i jest to mądre podejście. Dzięki temu mamy wolną rękę w przeprowadzaniu refaktoru - raz napisany test, daje nam możliwość weryfikowania czy ulepszanie wewnętrznej struktury obiektu po zmianach działa dalej tak jak tego oczekujemy.   

To rozwiązanie łamię zasadę, wiążąc test z ukrytymi przed resztą kodu produkcyjnego wnętrznościami Agregatu. Potem jednak zacząłem się zastanawiać na ile realnie problematyczny będzie on w utrzymaniu i czy czasem od dawna nie mierzymy się z tego typu problemami.

🔒 Kod produkcyjny dalej nie wie o stanie Agregatu

Niewątpliwą zaletą zastosowania metody Closure::bindTo jest fakt, że nie wpływa ona w żadnym stopniu na kod produkcyjny. Nie utworzyliśmy specjalnych getter'ów wykorzystanych tylko na potrzeby testów co w przyszłości mogłoby skłonić innych developerów do skorzystania z nich. W pewnym stopniu getter jest formą udostępniania wartości 1:1 z tym co jest wewnętrznym stanem obiektu. Dodanie getter'a wygląda jak rozszerzenie publicznego API, ale tylko na pozór. Bo jeżeli zmienimy wewnętrzny stan to będziemy musieli zmienić owego getter'a. Można by zastanowić się nad innymi realnymi problemami z tym związanymi, ale jest to temat na inny wpis.   

W każdym razie wydaje mi się, że problem tworzenia takich getter'ów istnieje w światku PHP, jest stosunkowo często stosowany i tylko sprawia wrażenie niegroźnego - dlatego powinniśmy zwracać na to uwagę. 

Stosowanie Closure::bindTo zamias dedykowanych getterów chroni kod produkcyjny.

🇬🇧 Szkoła Londyńska

Pisząc test jednostkowy klasy typu serwis (np. Event Subscriber'a, Command Handler'a) według paradygmatów tz. Szkoły Londyńskiej musimy najpierw zamockować jego zależności. Można to zrobić za pomocą customowych implementacji InMemoryRepository bądź przy użyciu narzędzi takich jak Prophecy/MockObject.

I tutaj właśnie zacząłem dostrzegać podobieństwo względem opisywanego przykładu. Dokładnie wiemy jak w teście jednostkowym należy zbudować zależność wymaganą przez object under test oraz jak będzie wyglądała interakcja pomiędzy zależnością, a testowanym obiektem.

Musimy jawnie oprogramować to związanie by test mógł przejść na zielono. Test oczywiście weryfikuje publiczne API serwisu, ale wie też coś o jego wewnętrznej pracy. Zmieniając zależności serwisu będziemy musieli zaktualizować testy - dokładnie tak samo jak w opisywanym przypadku wykorzystania Closure::bindTo.

Jest jednak subtelna różnica, w przypadku Closure::bindTo funkcja anonimowa musi dokładnie wiedzieć w jakim polu znajduje się wartość czyli pożądana przez nas zmiana stanu. W przypadku weryfikowania mock'ów zaś, ta informacja w dalszym ciągu jest przed nami ukryta, ale niewątpliwie w jednym i drugim przypadku odwołujemy się podczas wykonywania asercji do wewnętrznego stanu obiektu.   

Jak widać ten problem towarzyszył w projekcie w którym pracuje praktycznie od samego początku jego powstania, a mimo to dało się z nim żyć - co więcej - nikt nie uznawał tego za problematyczne. W opisywanym przypadku pojawił się jedynie w nieco innej formie (inny typ testowanego obiektu), ale to dalej nic nowego z czym wcześniej się nie borykaliśmy.  

🗃 Dla jakich typów obiektów?

Na samym początku muszę zauważyć, że chodzi o zmianę stanu obiektu dlatego z tego rozwiazania należałoby korzystać tylko w przypadku testowania metod void'owskich. Takich metod nie posiadają obiekty typu:

❌ Event

❌ DTO

❌ Value Object

Serwisy z metodami void'owskimi też weryfikujemy w inny sposób - sprawdzając ich z'mock'owane zależności, dlatego kolejno odpadają nam:

❌ Event Subscriber

❌ Command Handler

❌ Serwis Aplikacyjny/Domenowy

To co właściwie pozostało to:

✅ Encja

✅ Agregat 

Lecz tylko w przypadku gdy takowe już nie udostępniają swojego stanu dla innego kodu produkcyjnego!

🩻 Inny sposób udostępniania stanu

Taki sam efekt możnaby osiągnąć stosując refleksje:

public function test(): void
{
    $objectUnderTest = new Person('Jan', 'Kowalski');

    // When
    // ...

    $reflection = new ReflectionClass(Person::class);
    $firstNameProperty = $reflection->getProperty('firstName');
    $firstNameProperty->setAccessible(true);
    $lastNameProperty = $reflection->getProperty('lastName');
    $lastNameProperty->setAccessible(true);

    self::assertSame('Jan', $firstNameProperty->getValue($objectUnderTest));
    self::assertSame('Kowalski', $lastNameProperty->getValue($objectUnderTest));
}

W porównaniu z zastosowaniem Closure::bindTo wypada podobnie jeżeli chodzi o podejście czy konsekwencje dla potencjalnego refaktoru. Więcej linii kodu negatywnie wpływa na czytelność i w wątpliwość możemy poddawać szybkość działania, co nie powinno stanowić problemu gdy ten kod tak czy inaczej nie będzie działał produkcyjnie. 

♻️ Warstwa abstrakcji na asercję

Można by dodatkowo schować taką implementację przed testem w customowej klasie Assert. Jeżeli z biegiem czasu pojawi się jakiś sposób na lepsze udostępnianie stanu niż za pomocą Closure::bindTo lub refleksji to sama klasa testowa nie będzie wymagała modyfikacji. Dodatkowo wprowadzenie specjalnej klasy asercji wpłynie na poprawę czytelności samego testu.

public function test(): void
{
    $objectUnderTest = new Person('Jan', 'Kowalski');
    
    // When
    // ...
    
    PersonAssert::sameName('Jan', 'Kowalski', $objectUnderTest);
} 

📝 Podsumowanie

Koniec końców uważam, że zastosowanie Closure::bindTo było dobrym pomysłem. Pomimo tego, że udostępniamy prywatny stan na zewnątrz, napisany test jednostkowy przynosi wartość. Co prawda jesteśmy mniej odporni na zmiany klasy poddanej testom, ale z drugiej strony nie mieliśmy zbytniego wyboru. Moglibyśmy użyć testów integracyjnych lecz nie są one tak precyzyjne jak testy jednostkowe. Niekiedy nie dysponujemy takim rozwiązaniem w projekcie co uniemożliwiłoby całkowicie otestowanie takiej klasy. Korzystanie z Closure::bindTo powinno być ograniczone tylko do absolutnej konieczności gdy nie mamy innego wyboru, jest ono obarczone pewnym obciążeniem, ale na tyle małym by w dalszym ciągu utrzymać wszystko w ryzach. 

Jedyne nad czym trzeba się zastanowić to czy weryfikacja działania obiektu jest więcej warta niż poniższe efekty uboczne:

⚠️ zmiana wewnętrznego stanu wymaga naprawienia testu

⚠️ zmiana nazwy pola sprawi że komunikat nieprzechodzącego testu nie będzie do końca jasny (UndefinedProperty)

⚠️ narzędzia do analizy statycznej mogą zgłaszać błąd w związku z nieznanym polem

    

 

Mockowanie Repozytoriów

Testowanie jednostkowe klas posiadających jako zależności Repozytoria np. Seriwsów/Command Handler'ów może być kłopotliwe. Jeżeli zdycydujemy się na sztuczne implementacje Repozytoriów tzw. *InMemoryRepository – powinniśmy być świadomi kwestii związanych z ich późniejszym utrzymaniem – jakie problemy rozwiązują, a jakie stwarzają. Kod metody poddawanej testom nie jest tym nad czym chaciałbym się skupić w tym wpisie, istotne jest jedynie wywołanie w niej metody Query (CQS) Repozytorium.

 

Podejścia do Mock’owania Repozytoriów

Na potrzeby testu jednostkowego musimy odtworzyć wierną kopię klasy produkcyjnej. Np. posiadamy interfejs repozytorium OrderRepository:

interface OrderRepository 
{
	/** @return Order[] */
	public function getUnpaidOrders(): iterable;
}

 

Abstrahując od tego jak wyglądałaby implementacja klasy produkcyjnej OrderMySQLRepository, skupmy się na jej odpowiedniku utworzonym na potrzeby testu:

final class OrderInMemoryRepository implements OrderRepository
{
	/** @param Order[] $orders */
	public function __construct(private array $orders) {}
	
	public function getUnpaidOrders(): iterable
	{
		return array_filter(
			$this->orders,
			static fn ($order) => $order->isUnpaid() 
		);
	}
}

Implementacja metody OrderInMemoryRepository::getUnpaidOrders została tak napisana by zawsze zwracała odpowiednią kolekcję zamówień - logicznie zgodną z nazwą metody. Dzięki takiej implementacji dysponujemy całkiem poręcznym narzędziem do pisania testów jednostkowych. W przypadku gdy interfejs posiadałby by inne metody – też w takim stopniu odtwarzające rzeczywistą implementację – moglibyśmy używać tego samego obiektu OrderInMemoryRepository w wielu przypadkach testowych. Jest to dość złożony TestDouble typu Fake, który niejako posiada więdzę na temat tego jak działa produkcyjna implementacja.

Moglibyśmy przyjąć inną taktykę w której OrderInMemoryRepository jest maksymalnie okrojony z implementacji:

final class OrderInMemoryRepository implements OrderRepository
{
	/** @param Order[] $orders */
	public function __construct(private array $orders) {}
	
	public function getUnpaidOrders(): iterable
	{
		return $this->orders;
	}
}

 

Jako, że OrderInMemoryRepository::getUnpaidOrders zawsze zwraca taką samą kolekcję jak ta dostarczona do konstruktora – można powiedzieć, że jest to pewna forma Stub’a.Ciężar doboru odpowiednich danych wejściowych spoczywa na metodzie w której sztuczne Repozytorium zostało utworzone – np. Fixtura, metoda testowa/setUp.

Korzystanie z wariantu Stub jest niemal identyczne jakbyśmy używali biblioteki mokującej np. MockObject czy Prophecy. W dwóch przypadkach musimy staranie dobrać zwrotkę metody do aktualnego przypadku testowego. Pomiędzy przygotowaną kolekcją obiektów wrzucaną w metodę obiektu z biblioteki mokującej/czy konstruktorem Stub *InMemoryRepository, a zwróceniem danych z wywołanej metody Repozytorium, nic więcej się nie dzieje - nie następuje żadne filtrowanie.

Fake Repository

❌ jest silnie sprzężony z Produkcyjnym Repozytorium (po każdej zmianie repozytorium MySQL, musimy sprawdzić czy *InMemoryRepository nie wymaga modernizacji, czy w dalszym ciągu wiernie odzwierciedla prawdziwą implemetację),

✅ koncept stojący za nazwą metod jest jawnie zapisany w kodzie,

✅ odpowiednio przygotowany może być wykorzystany w wielu przypadkach testowych.

 

Stub Repository

❌ musi być indywidualnie przygotowany pod każdy przypadek testowy. Dobór zwrotek jego metod stoi po stronie developera – jest więc nie do końca jawny,

❌ w przypadku zmiany metody Produkcyjnego Repozytorium, musimy zweryfikować wszystkie przypadki testowe kodu, który bezpośrednio polega na tej metodzie. Czy w dalszym ciągu przygotowane przez developera obiekty zwracane przez metodę sztucznego Repozytorium spełniają logikę która stoi za ich nazwą? 

✅ zaletą jest mniej kodu do utrzymania, ale to tylko dlatego, że koncepty te nie są zawarte w kodzie z czego wynikają opisane wyżej problemy. W przypadku gdy istnieje tylko jeden klient metody Repozytorium możemy zastosować Stub’a – wraz z rozrostem repozytorium o nowe metody, zwiększeniem się liczby klientów należy rozwarzyć refaktoryzację w stronę Fake’a.

Koniec końców, czy stosujemy jedną czy drugą metodę – cały czas jesteśmy w tej samej sytuacji – musimy inscenizować dostarczanie danych do testowanej metody. W przypadku Fake’ów z bardziej skomplikowaną implementacją, dysponujemy po prostu bardziej wszechstronnym narzędziem kosztem jego późniejszego utrzymania. 

 

Utrzymanie klasy Fake InMemory Repository

Nowe wymagania biznesowe w czasie kolejnych iteracji wymuszają zmianę repozytoriów - prawdziwych i sztucznych.

Przedstawione na diagramie zmiany interfejsu Repozytorium, są oczywiście napędzane decyzjami biznesu co do nowych feature’ów. Jak widać testując jednostkowo metodę wywołującą metody Repozytorium, musimy wprowadzić do systemu testowego nowy byt. Każda zmiana implementacji repozytoriów będzie wymuszała na nas prace związane z jego utrzymaniem. Można wywnioskować, że klasy *InMemoryRepository to dodatkowy koszt jaki musimy ponieść za cenę bezpieczeństwa czyli łatwiejszego wprowadzania zmian w projekcie.

Błędne będzie jednak założenie, że Mock’owanie Repozytoriów zawsze daje nam wspomniane bezpieczeństwo. W przypadku gdy pomiędzy Klasą Produkcyjną, a Test Double pojawią się rozbieżności w działaniu – wprowadzone nieświadomie/omyłkowo przez programistę – testy jednostkowe mogą przechodzić na zielono, podczas gdy tzw. Produkcja będzie rzucał błędami lub działała niezgodnie z oczekiwaniami. Jest to ryzyko z którego powinniśmy zdawać sobie sprawę podczas synchronizacji Fake InMemory Repository z Repozytorium Produkcyjnym.

Warto też zauważyć, że im bardziej uniwersalna jest metoda repozytorium tzn. posiada filtry, tym trudniej utworzyć jej imitację potrzebną do testów jednostkowych. Odtworzenie poprawnego zachowania wszystkich filtrów może być skomplikowane, a wprowadzona złożoność z tym zwiazana - podatna na błędy w przyszłości. Przy tego typu pracach należy zachować szczególną ostrożność, gdyż jak na ironię, nie posiadamy testu jednostkowego klasy InMemory.

Jeżeli zaś chodzi o sam design, na tak uniwersalnej metodzie Repozytorium polegać będzie zapewne dużo klientów, co będzie skutkowało pojawieniem się zależności między nimi czego wspólnym mianownikiem jest wspomniana „uniwersalna” metoda Repozytorium.

 

Podejście funkcyjne

Możemy przyjąć zupełnie inną taktykę. Zamiast zastanawiać się nad najlepszym sposobem testowania metod które pozyskują dane z repozytoriów - nie testować ich w ogóle. Wiąże się to z destylacją logiki biznesowej zawartej w testowanej metodzie poprzez wydzielenie wszystkich wyowłań metod Query (CQS) do warstwy wyżej.

Metoda Serwisu samy pozyskuje dane z Repozytorium. Taka implementacja wymaga ich mock'owania.

 

W wyniku takiej zmiany design’u: wydestylowany byt staje się Serwisem Domenowym, a warstwa która pozyskuje Encję/Agregaty/VO z repozytoriów – Serwisem Aplikacyjnym, którego domenowy odpowiednik otrzymuje wszystkie potrzebne do przeprowadzenia operacji obiekty, jako parametry metody.

 

Testowany Serwis Domenowy poddawany nie wie nic o klasach Repozytoriów.

Testowaniu jednostkowem podlegać będzie wtedy tylko Serwis Domenowy, dla którego nie będziemy musieli już szykować żadnego Test Double Repozytorium. Serwisy Aplikacyjne będą testowane tylko Integracyjne.

Niektóre przypadki mogą okazać się problematyczne do zaimplementowania – bo jak mamy rozwiązać problem jakiegoś bytu który jest pobierany z repozytorium na podstawie jakiejś decyzji biznesowe?

Podsumowanie

Jak widać mockowanie repozytoriów wiąże się z pewnego rodzaju problemami z których należy sobie zdawać sprawę – jak zwyklę w programowaniu nic nie jest czarno białe i rozwiązując pewien problem godzimy się na wprowadzenie mniejszego. Testy Integracyjne niejako rozwiązują sprawę tworzenia Test Double Repozytoriów w ogóle, niemniej jednak nie zawsze takowe z łatwością można wprowadzić w projekcie.