2022-10-10, godz. 18:00
Te dwa pytania mogą być potężną przeszkodą na początku przygody z metodologiami takimi jak TDD oraz BDD. Co więcej, wciąż są wyzwaniem po długim czasie utrzymywania poprawnie otestowanego, dużego projektu. Będąc od wielu lat częścią jednego z nich, dochodzę do fundamentalnej konkluzji: testami powinny być pokryte przede wszystkim wymagania biznesowe. “Hola, hola!”, możesz zakrzyknąć, “ale te wymagania się jakoś manifestują w aplikacji! API, UI, CLI… czy nie powinniśmy testować właśnie nich?”. I będziesz mieć rację, choć tylko częściowo. Bazując na doświadczeniu z ogromnego przedsięwzięcia związanego z BDD przeprowadzonego w Syliusie, przedstawię jak podeszliśmy do testowania różnych interfejsów użytkownika (tradycyjnego UI-a opartego na Twigu oraz API stworzonego za pomocą API Platform), nie tracąc skupienia na wartości biznesowej aplikacji.
W trakcie prezentacji opowiem o tym dlaczego utrzymywanie testów w projektach bywa trudne. Zaprezentuję techniki rozwiązania tego problemu co doprowadzi nas do koncepcji imperative shell functional core. Zdefiniuje cechy tej architektury i krótko pokaże jej implementacje w PHP.
Wszyscy popełniamy błędy, a już na pewno nikt ich nie lubi. Niektóre z tych błędów są błahe, inne kosztowne, ale mogą zdarzyć się te niebezpieczne. Każdy błąd wpływa na ostateczną jakość produktu końcowego. Ważne jest by wyeliminować jak najwięcej z nich. Na bazie moich doświadczeń opowiem o tym jak, dzięki testowaniu jestem pewniejszy swojego kodu, oszczędzam czas i mógłbym deployować w piątki. Podzielę się z Wami zasadę CORD, dzięki której bezpiecznie dostarczam oprogramowanie. Używając buzzwordów takich jak: TDD, BDD, Unit/Functional/Integration/E2E Test, Mock, Stub, Regresion, Code coverage, postaram się odpowiedzieć na kilka pytań: - dlaczego tak często nie - piszemy testów - kiedy należy je pisać - czego nie testować - to mock, or not to mock - i inne jeśli starczy czasu.
… ale czy na pewno będzie i czy wszystko stanie się takie proste i ładne? W minionych latach w środowisku PHP bardzo dużo mówi się o wytwarzania oprogramowania z wykorzystaniem wiadomości. Inżynieria oprogramowania na dobre wdarła się do naszego PHPowego światka, a wraz z nią odeszliśmy od wszechobecnych CRUDów, otrzymując jednocześnie cały wachlarz narzędzi do odkrywania i drążenia biznesowych potrzeb. W sporej części te narzędzia opierają się na zachowaniach, przesyłanych komunikatach i skupione są mocno wokół języka naturalnego. Z drugiej strony dostaliśmy narzędzia techniczne wspierające takie podejście, m. in. tak popularny Symfony Messenger. W takim razie "czy mesedż mesedżowi równy"? Czy każda wiadomość jest taka sama w kontekście wykorzystania i znaczenia? Gdzie poszczególne rodzaje wiadomości znajdują miejsce w warstwach naszych heksagonalnych aplikacji i co z nimi zrobić, gdy heksagonów jest więcej? Między innymi na te pytania postaramy się odpowiedzieć sobie w trakcie tej prezentacji.
