Z moich poprzednich artykułów wiesz już, że testy automatyczne możemy podzielić między innymi na testy jednostkowe i testy integracyjne. Do testów jednostkowych wprowadziłem Cię już w ostatnich artykułach (jeżeli się z nimi jeszcze nie zapoznałeś, koniecznie to zrób). Teraz przyszła pora na testy integracyjne. W testach jednostkowych testujemy pojedyncze jednostki, bez zewnętrznych zależności. Może się okazać, że mamy mnóstwo testów jednostkowych, które są zielone, a w rzeczywistości w naszej aplikacji mogą być błędy. Możemy mieć błędy na przykład we wspomnianych wcześniej [...]
Dzisiaj poruszę bardzo ważny temat, bez którego znajomości, nie nauczysz się pisać dobrych testów jednostkowych. Jak przeczytałeś już w poprzednich artykułach, testy jednostkowe nie powinny dotykać zewnętrznych zasobów. Jak w takim razie testować logikę w metodach, które mają odwołanie do zasobów zewnętrznych? Trzeba użyć sztucznych obiektów, tak zwanych mocków. Co to jest mockowanie? Mockowanie, czyli naśladowanie czegoś, jakiegoś zachowania. W polskim tłumaczeniu można się spotkać z różnymi tłumaczeniami słowa mock, między innymi makieta, ja jednak będę używał po [...]
W poprzednim artykule na blogu wprowadziłem Cię do testów automatycznych. Jeżeli jeszcze go nie czytałeś, koniecznie zapoznaj się z nim, zanim przejdziesz do tego artykułu. Testy jednostkowe (unit tests), są właśnie jednym z typów testów automatycznych. W tym artykule najpierw opowiem Ci trochę o testach jednostkowych w teorii, powiem Ci jakie powinny być dobre testy jednostkowe, a następnie napiszemy pierwszy test jednostkowy, a później kolejne. Zaczynajmy! Czym są testy jednostkowe? Zacznijmy od teorii. Testy jednostkowe są to małe kawałki kodu, które służą [...]
Testy automatyczne, czyli kod, który testuje inny kawałek kodu. Jak sama nazwa wskazuje, są to testy automatyczne, dzięki nim możemy testować nasze aplikacje często i szybko - chcąc przetestować jakąś funkcjonalność w naszej aplikacji, nie musimy jej nawet uruchamiać. Jeżeli mamy kod na przykład do skomplikowanych obliczeń, to możemy go przetestować w sposób manualny, czyli poprzez uruchomienie aplikacji, zalogowanie się, przejście do odpowiedniej zakładki gdzie wykonywane są obliczenia, następnie musimy wypełnić formularz i kliknąć odpowiedni przycisk - dopiero wtedy sprawdzimy wynik. Taki sam zabieg trzeba przeprowadzić [...]
Każdy programista w swojej karierze ma różne etapy. Zazwyczaj początkujący programiści starają się pisać swoje aplikacji, w taki sposób, aby spełniały wszystkie wymagania, nie zważając na to, w jaki sposób piszą swój kod. Z czasem, gdy rozwijane są kolejne programy, zdobywamy doświadczenie, mamy do czynienia również z jakimś starym, zastanym kodem - przychodzą refleksję. Widzimy, że kod, który został wcześniej napisany, jest ciężki do utrzymywania. Każde kolejne w nim zmiany są coraz trudniejsze do wprowadzenia. Zastanawiamy się jak to zmienić, jak pisać lepszy, czystszy kod, tak [...]
Pora na rozszyfrowanie ostatniej, ale zdecydowanie nie najmniej ważnej litery SOLID, to znaczy D jak Dependency Inversion Principle, czyli Zasadę Odwrócenia Zależności. Zasada ta mówi o tym, że: -Moduły wysokopoziomowe nie powinny zależeć od modułów niskopoziomowych. I jedne, i drugie powinny zależeć od abstrakcji. -Abstrakcje nie powinny zależeć od szczegółów. To szczegóły powinny zależeć od abstrakcji. Systemy, które piszemy, powinny odnosić się do abstrakcji (poprzez zastosowanie interfejsów lub klas abstrakcyjnych), a nie konkretnych elementów. Dzięki stosowaniu się do [...]
Kontynuując serię artykułów o SOLID, dzisiaj nadszedł czas na omówienie literki I, a dokładniej Interface Segregation Principle (w skrócie ISP). W polskim tłumaczeniu, jest to zasada segregacji interfejsów. Wydaje mi się, że z wszystkich reguł SOLID, właśnie omawiana w tym artykule - zasada segregacji interfejsów jest najprostsza do zrozumienia i zastosowania. Mówi ona o tym, że żaden klient nie powinien być zmuszany do polegania na metodach, z których nie korzysta. Nie powinniśmy stosować tłustych interfejsów (fat interfaces), mające deklarację metod, które niekoniecznie każdy z konsumentów [...]
Kolejną z zasad SOLID, dzięki której nasz kod będzie dobrej jakości jest zasada podstawień Liskov, czyli Liskov Substitution Principle (LSP) została opracowana w roku 1988, przez Amerykańską programistkę Barbarę Liskov. Po raz pierwszy zasada brzmiała tak: "Poszukujemy następującej właściwości podstawiania: Jeżeli dla każdego obiektu o1 typu S istnieje obiekt o2 typu T taki, że dla wszystkich programów P zdefiniowanych w kategoriach T zachowanie P pozostanie niezmienione, gdy o1 zostanie podstawione za o2, to S jest podtypem T." W sumie na tym mógłbym zakończyć ten artykuł, bo [...]
Reguła Otwarte-Zamknięte, czyli Open-Closed Principle (OCP) została zdefiniowana w roku 1988 przez Bertranda Meyera. Mówi ona o tym, że element oprogramowania powinien być otwarty na rozbudowę, ale zamknięty na modyfikację. Dzięki zasadzie otwarte-zamknięte nasze systemy mogą być kompatybilne wstecz. Reguła ta jest szczególnie ważna, jeżeli chcemy tworzyć systemy, które będą miały więcej niż jedną wersję [...]
Programista, pisząc kod, powinien starać się pisać czysty kod. Co to oznacza? Między innymi oznacza to, że kod powinien być zgodny ze wzorcami projektowymi oraz z zastosowaniem dobrych praktyk. Najpopularniejszymi regułami projektowania w językach obiektowych są prawdopodobnie zasady zaproponowane przez Roberta C. Martina, które zostały nazwane SOLID. Większość programistów wie, co oznacza ten termin, ale czy stosuje go w praktyce? Nie do końca, w tym artykule postaram Ci się opisać pierwszą z zasad SOLID, będzie to SRP, czyli Single Responsibility Principle [...]
![[E-Book] Jak Zostać Programistą Od Zera Do Eksperta (PDF)](/content/images/jak-zostac-programista-od-zera-male.png)
![[E-Book] Rekrutacja Programisty C#/.NET (PDF)](/content/images/rekrutacja-programisty-csharp-dotnet.png)