Czy wszystko jest?

Testować możemy wszystkie składowe Reduxa. Wiemy już jak ugryźć Reducers. Teraz czas na Components i Actions.

Components

W celu sprawdzenia, czy nasz komponent jest w stanie się prawidłowo narysować (wyrenderować) musimy go przesłać jako parametr metody create() renderera z paczki react-test-renderer. Przesłanie Reacta jest proste - możesz mnie użyć wszędzie, gdzie dostępny będzie odpowiedni renderer (nawet na bardzo niskim poziomie, patrz ReactHardware. I proszę bardzo - chcę uruchomić Reacta w testach, więc wykorzystuję renderera :) Obiekt zwrócony przez metodę create w moim przypadku wygląda tak: Odpowiada temu, co wcześniej zakodziłem w BooksList. Operując na tym jsonie jesteśmy w stanie sprawdzać, czy poszczególne elementy naszego widoku są widoczne, czy nie. Gwoli wyjaśnienia - w celu zapewnienia wykonania testu, musiałem dorzucić kilka propsów: store, navigator i route - podobnie jak w użyciu tego komponentu w testowanej aplikacji. Ten test potraktuję jako smoke’a i nic dodatkowo nie sprawdzę.

Actions

A właściwie ActionsCreators zwracają obiekt akcji, która ma wpłynąć na stan aplikacji.

Podobnie jak w przypadku Reducera - odpalamy metodę i sprawdzamy, czy otrzymany obiekt odpowiada oczekiwanemu.

__mocks__

Prędzej czy później - musiały się pojawić. Aplikacja mobilna wykorzystuje signalR, a w testach opieranie się na tym, że gdzieś w cyberprzestrzeni jest uruchomiony jakiś hub, który może wpłynąć na wyniki naszych testów jest… niebezpieczne, niepoważne - jednym słowem - nie. Wykorzystując mechanizm mockowania dostarczony przez jest skrobniemy na szybko mocka signalRa.

SignalR to nie jedyna przeszkoda w testowaniu. Może się zdarzyć, że testowane przez nas komponenty będą korzystać z zewnętrznych zależności - w moim przypadku kontrolki stylu. Na chwilę obecną nie są mi potrzebne, dla nich mock też powstanie. Jedyny zgrzyt, jaki się tu pojawia, to konieczność tworzenia katalogu __mocks__ jak najbliżej mockowanej paczki/biblioteki. I tak dla klienta signalr, który wylądował w katalogu lib, mock musiał sie znaleźć w lib\__mocks__, a mock dla material ui zasłużył na katalog ‘obok’ node_modules. Osobiście nie podoba mi się takie podejście, gdyż logika testów jest rozsmarowana po całym repo - z drugiej strony mocki mamy najbliżej mockowanej funkcjonalności jak się tylko da. Całe szczęście, że Visual Studio ‘skraca’ nam drogę między testem a implementacją rozsądną nawigacją.

Zielono!