12 – O mockach z Pawłem Klimczykiem
W dwunastym już odcinku (czas leci!) mam przyjemność ponownie podywagować na temat bardzo mi bliski: testy. A konkretnie: testowanie w kontekście wykorzystania “isolating frameworks”, czyli po ludzku: mocków. Partnerem w rozmowie jest Paweł Klimczyk – programista, prelegent i “szef dotnetów na fejsie” :), czyli grup .NET Developers Poland oraz .NET Developers Poland Job Market. Na Twitterze: @pwlklm.
Podczas audycji możecie posłuchać o tym co to są mocki i na jakie grupy się je dzieli (i czy ma to sens). Jakie frameworki w świecie .NET pozwalają na wykorzystanie mocków (i jak je można skategoryzować). Do tego wpada kilka pobocznych wątków, jak na przykład: jak testować metody prywatne?
Konkurs: w tym odcinku mam dla Was egzemplarz książki “The Art of Unit Testing” Roya Osherove. Jak zwykle (ale monotonnie, co? 😉 ) powędruje on do jednej z osób, które wezmą udział w dyskusji która powinna wywiązać się pod tym postem. Piszcie zarówno na temat merytoryki odcinka, jak też ogólnie o DevTalku.
Odcinek jedenasty stoi pod znakiem… czasu. Wszyscy mamy go za mało. A może mamy go wystarczająco dużo, tylko wykorzystujemy go nie do końca optymalnie? O to i inne rzeczy pytam Marcina Kwiecińskiego, który w ramach projektu 
Odcinek był tydzień temu, odcinek będzie za tydzień, więc… co ja robię tu dzisiaj?
Moim towarzyszem w odcinku dziewiątym jest Krzysztof Szabelski. Jako doświadczony programista i lider pomaga różnym zespołom w firmie ogarniać trudne tematy. Występuje na konferencjach i grupach pasjonackich. Techniczne treści tworzy na 
Siódmy odcinek to drugie podejście do tematu “miękkiego”. Towarzyszy mi Andrzej Krzywda – lider polskiej społeczności Ruby, założyciel firmy 
Od razu po Nowym Roku wracamy z mocnym uderzeniem: na warsztacie tym razem znalazło się programowanie funkcyjne! Mój gość to Michał Łusiak – programista, prelegent, 
Paweł Klimczyk • 28/03/2015
@Piotr Perak:
Odnosnie roznic stub/mock – dobrze piszesz. Ja chcialem rozwinac troche wypowiedz i pokazac wiekszy kontekst. W programowaniu przewaznie uzywam mockow.
Metody prywatne wymagajace testowania – kurde, zrobilm bym z tego klase osobna, bo widocznie to co jest w srodku robi sporo i powinnno byc wyabstrahowane.
@Grzegorz:
W tym podkascie chodzilo o pokazanie samej idei mockow.
UI Testing – temat na osobny podcast
@Grzesiek Gałęzowski:
Growing Object Oriented Software Guided By Tests – to juz temat TDD.
Ksiazke przeczytam :). Nawiazajac do Twojego podejscia do mockowania DateTime i wprowadzania abstrakcji to jest ono dobre, gdy buduje sie system. Problem pojawia sie gdy lądujesz w projekcie, gdzie kod ma juz kilka lat i dodajesz nowe funkcje. Wtedy trudno abstrahowac DateTime i (może) łatwiej mockować to co jest.
Ciesze sie, że wywiązała się tutaj taka dyskusja.
Grzesiek Gałęzowski • 03/04/2015
@Paweł Klimczyk GOOS to temat TDD, ale bardzo mocno mocków właśnie (choć nie tylko). Z wstępu do książki: “Our original motivation for writing the book was to finally explain the technique of using mock objects, which we often see misunderstood.”. Chociaż owszem, mocków można używać inaczej trochę niż jest opisane w tej książce, np. do starego kodu. Tylko wtedy nie są to takie mocki w sensie stricte, gdyż oryginalne mocki rzucały wyjątki gdy otrzymały niespodziewane wywołania (w świecie C# i Javy uważa się obecnie to podejście za przestarzałe i prowadzące do kruchych testów, natomiast JMock – biblioteka autorów GOOS – wciąż opiera się na takich właśnie mockach i autorzy twardo stoją przy stanowisku, że w takim sposobie wykorzystania mocków jaki oni preferują jest to lepsze podejście, dlatego że dla nich naturalnym podejściem do projektowania jest projektowanie “protokołocentryczne”).
Z tym Date Time w starym kodzie to zgoda, natomiast pole manewru zależy od narzędzi. Jeśli ma się dobre automatyczne narzędzie do refaktoryzacji, to najczęściej nie trzeba mockować tego co jest – w r# często sprawę załatwia kombinacja “Extract Method-> Extract Class->Introduce Parameter (jako parametr konstruktora)->Extract Interface->Use Base Type Where Possible”, którą można zrobić niemal mechanicznie.