0:00 / 0:00

Zasady SOLID na Backendzie: SRP - Testowanie

Tworzenie kodu według najlepszych praktyk

2 godz. 45 min · Full-stack i Programowanie

Rafał PiekaraSoftware Komandos

Czego się nauczysz

Teoretyczne wyjaśnienie każdej z 5 zasad SOLID
Przykłady zastosowania SOLID w kodzie Ruby i Typescript
Zadania teoretyczne polegające na zaprojektowaniu kodu zgodnie z SOLID
Praktyka i refaktoring kodu legacy w kierunku zasad SOLID
Przykłady testowania kodu implementującego zasady SOLID

Teoretyczne podstawy

Nie zrozumiesz SOLIDa bez teoretycznych podstaw. Przejdziemy przez założenia stojące za każdą z nich. Przeanalizujemy problemy, które możesz spotkać oraz dowiesz się dlaczego ciągle jeszcze tak wielu programistów nie stosuje się do tych zasad.

Przykłady zastosowania SOLID w kodzie Ruby i Typescript

Ruby i Typescript to technologie, które świetnie odzwierciedlają uniwersalizm SOLIDa. Te złote zasady działają w językach dynamicznie typowanych i interpretowanych jak Ruby oraz przy statycznym typowaniu na przykładzie Typescript.

Projektowanie kodu zgodnie z SOLID

Zanim zabierzesz się za programowanie warto poćwiczyć SOLIDny sposób myślenia. Zmierzysz się z zadaniami, w ramach których będziesz projektować kod tak, aby wszystkie zasady SOLID znalazły w nim swoje zastosowanie.

Praktyka i refaktoring w kierunku SOLID

Prawda jest taka, że kod, z którym w większości pracujemy ma swoją historię. Czasami historia ta jest tak bolesna, że klasy i metody są zagmatwane, poplątane i trudne w utrzymaniu. Gdy dotrzesz do tego miejsca będziesz mieć w arsenale wszystkie potrzebne narzędzia, żeby zmierzyć się z zadaniami praktycznymi, które przekształcą kod legacy w SOLIDne arcydzieło.

Testy, testy, testy

Tak ważny temat, jak testowanie nie może zostać pominięty. Między innymi po to też stosujemy zasady SOLID, żeby nasz kod praktycznie sam się testował. Napiszesz więc testy, których wzorce możesz wykorzystać w dowolnym projekcie, dowolnej technologii, jeśli tylko kod, który testujesz będzie spełniał wymagania zasad SOLID.

Dla kogo jest ten kurs?

Nie ma znaczenia, czy dopiero zaczynasz przygodę z programowaniem, czy też jesteś starym wyjadaczem, który klasami i interfejsami myśli przy zagryzaniu tosta na śniadanie. Ten kurs jest właśnie dla Ciebie. Technologia ani język programowania też nie mają znaczenia. Zasady SOLID to uniwersalny zbiór. Ich znajomość sprawi, że Twój kod będzie lepszy, łatwiejszy w utrzymaniu i odporny na perturbacje i zmiany.

0:00Zobaczmy teraz, jak nasz faktoring klasy Telekom Service wpłynął na jakość

0:05i wygodę testowania naszego kodu.

0:08Dla wygody wydzieliłem tutaj wszystek kod, który wcześniej napisaliśmy do osobnych

0:13plików, żeby zwiększyć czytelność w tym momencie.

0:16Kiedy patrzymy sobie na ten kod, widzimy, że każda klasa ma swój osobny plik.

0:21Jesteśmy w stanie łatwo ocenić, jakie operacje będą w naszej

0:24aplikacji wykonywane.

0:26Pojawiły się dwa katalogi katalog lib i katalog sp i to samo zobaczysz

0:30też w innych przykładach.

0:32Później w kolejnych lekcjach.

0:33Więc w katalogu lib mamy całą logikę biznesową, czyli to są wszystkie nasze

0:38klasy, które wykonują nasze operacje biznesowe.

0:41Natomiast katalog SPEC ma w sobie napisane testy.

0:45Testy zostały napisane.

0:46We frameworku Respect jest framework służący do testowania kodów Ruby.

0:51Tak jak kod przykładów mamy tutaj testy napisane w Rubi i zobacz,

0:55że te testy są mega proste.

0:57Testy dla customer notice Mayera testują powiadomienie dla klienta, testy info

1:04z serwisu, testują generowanie faktury.

1:06Tutaj możemy sprawdzić czy ta wygenerowana faktura ma odpowiednie wartości,

1:10czy jest odpowiednio stworzona. Mamy Payment Service.

1:13Możemy sprawdzić sobie statusy błędów, które mogą być rzucane w trakcie

1:17procesowania płatności, ale wszystko odbywa się w tym małym, jednym

1:21zamkniętym w kapsule teście.

1:23Tak samo w Planet Serwis.

1:24Mamy bardzo prosty kod, w którym tworzymy test double, czyli mocujemy

1:29wywołania do różnych klas.

1:30Te wywołania klas przekazujemy jako parametry, te nasze double testowe i

1:35sprawdzamy czy wszystko działa tak jak powinno.

1:38Jak widzisz, ten kod nie testuje wykonania logiki biznesowej w sposób integracyjny.

1:43Natomiast testujemy tutaj implementację, a mianowicie to czy nasz

1:47serwis deleguje wykonanie operacji do poszczególnych klas

1:51z pojedynczą odpowiedzialnością i przekazując im odpowiednie parametry.

1:55Więc tak wyglądają te testy.

1:57Możemy tutaj dodać jeszcze jeden test integracyjny, który już nie będzie

2:00operował na kablach na mocach, ale będzie wykonywał właściwą logikę biznesową

2:05i sprawdzimy jak to wszystko wygląda.

2:08W ten sposób możemy testować kod napisany zgodnie z zasadą SRP.

2:12Jeśli przypomnisz sobie jak to wyglądało w poprzedniej lekcji, jak telekom serwis

2:16wyglądał wcześniej, to ten test dla samego serwisu telekom Serwis

2:20raz, że byłby bardzo długi, a dwa, że byłby mniej czytelny.

2:22Musielibyśmy uwzględniać wiele warunków brzegowych, a trzy po prostu

2:27byłby trudne w utrzymaniu.

2:28Teraz możemy sobie testować każdy z tych elementów w izolacji i sprawdzać,

2:32czy nasz system działa poprawnie.

2:34Dzięki temu zyskujemy spójność i większą testowanie naszego kodu.