84. O implementacji testów backendu i architekturze otwartej na testowanie

Better Software Design

Innehåll tillhandahållet av Mariusz Gil. Allt poddinnehåll inklusive avsnitt, grafik och podcastbeskrivningar laddas upp och tillhandahålls direkt av Mariusz Gil eller deras podcastplattformspartner. Om du tror att någon använder ditt upphovsrättsskyddade verk utan din tillåtelse kan du följa processen som beskrivs här https://sv.player.fm/legal.

1+ y ago 1:20:27

MP3•Episod hem

Jeśli wycena projektu podawana jest w dwóch wersjach, z uwzględnieniem testów i bez, to z software craftsmanshipem ma to niewiele wspólnego. To tak, jakby pytać chirurga, czy może przyspieszyć operację nie dezynfekując skalpela. Jakość nie powinna być elementem przetargowym. Chyba, że pracujemy nad proof-of-concept, ale tego rodzaju projekty często lubią płynnie przejść w fazę protoduction...

Jeśli szukasz sprawdzonych w boju receptur na implementację jakościowych testów, które nie będą wymagały co chwilę refaktoryzacji i modyfikacji przy zmianie kodu projektu, zapraszam Cię na dzisiejszą rozmowę z Piotrem Stawirejem. Napisać test w projekcie to w zasadzie żadna sztuka. Ale napisać test, który dostarczy realną wartość biznesową, będzie łatwy do utrzymania, a przy okazji może zostać wykorzystany na różnych poziomach piramidy testów, to trochę bardziej skomplikowane zadanie.

I pewnie niektóre strategie mogą być trochę kontrowersyjne, jak na przykład rezygnacja z typowego mockowania zależności, czy silnego podziału na wiele różnych testów w projekcie. Ale skoro działa to w praktyce, to w czym rzecz?

W tym odcinku rozmawiamy wraz z Piotrem między innymi o:

organizacyjnych i technicznych problemach z implementacją jakościowych testów w backendzie
metryce code-coverage i jej różnym stopniu przydatności w projekcie
profesjonalnym podejściu do problemu "z testami, czy bez?"
dobrych praktykach doboru strategii testowania
szarej strefie testów Kevlina Henney'a
legacy, testach charakterystyki, szwach i odcinaniu fragmentów systemu dla testów
unitach, czyli fragmentach kodu o pojedynczej odpowiedzialności, mierzonego kohezją
implementacji architektury otwartej na testowanie
eliminacji problemów z nadużywaniem mocków w projekcie

Zapraszam!

Materiały dodatkowe:

Sub-second acceptance tests, prezentacja Aslaka Hellesøy z konferencji SeleniumConf Chicago
Growing Object-Oriented Software, Guided by Tests, wspomniana w rozmowie książka Steve'a Freemana i Nata Pryce'a
Style Guide for Object Design, książka Matthiasa Nobacka
Financial System, repozytorium z przykładowym kodem Piotra

98 episoder

#Mariusz Gil #Domain Driven Design #Ddd #Programming #Software #User experience #Technologie #Rozwój oprogramowania #Software Architecture