fbpx
devstyle.pl - Blog dla każdego programisty
devstyle.pl - Blog dla każdego programisty
2 minut

DevTalk#12 – O mockach z Pawłem Klimczykiem


16.03.2015

pawel-klimczykW 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.


Montaż odcinka: Krzysztof Śmigiel.
Ważne adresy:

Linki


Muzyka wykorzystana w intro:
“Misuse” Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0
http://creativecommons.org/licenses/by/3.0/

Nie przegap kolejnych postów!

Dołącz do ponad 9000 programistów w devstyle newsletter!

Tym samym wyrażasz zgodę na otrzymanie informacji marketingowych z devstyle.pl (doh...). Powered by ConvertKit
Notify of
Piotr
Piotr

Do mockowania System.DateTime.Now używam takiego rozwiązania:
public static class SystemTime
{
public static Func Now = () => DateTime.Now;
}

Użycie:
DateTime now = SystemTime.Now();

A w testach:
[SetUp]
public void Initialize()
{
SystemTime.Now = () => new DateTime(2018, 01, 01);
}

Piotrek
Piotrek

Apropo auto-mocking containers, to od jakiś dwóch miesięcy używam AutoFixture (https://github.com/AutoFixture/AutoFixture) i przyznam szczerze że świetna sprawa. O ile w nowych aplikacjach (aplikacjach pisanych od zera czy no nazwijmy je bardziej na czasie) duża ilośc zależności klasy rzeczywiście świadczy o bad design,o tyle przy aplikacjach ponad 10-letnich i tzw. legacy code, gdzie klasa przyjmuje 5 zależności i lepiej nie wyobrażam sobie mockowania wszystkich zależności. Zwłaszcza gdy potrzeba przetestować (co głownie jest ideą testowania) jakiś kawałek, w którym user znalazł błąd, a refactoring nie wchodzi w rachubę ;) Używając automocking containers tworzysz sobie sut’a, mockujesz co potrza i jazda. Odnośnie dzisiejszego… Read more »

Grzegorz
Grzegorz

Hej!
Bartdzo ciekawa seria podcastow – dzis przesluchalem 75% z calej serii.
Co do mockowania – zawsze mnie intruguje jak dobrze mockowac ef – bo setup czasami zajmuje caly ekran, a mnie uczono, ze jak cos jest na caly ekran – to znaczy ze jest za duze (a wtedy nie bylo rozdzielczosci fullHD).

Mysle, ze przeslucham podcast dwa, trzy razy i wroce z pytaniami, bo musze zaladowac nowe namesaces do osrodka decyzyjnego…
G

Ireneusz Patalas
Ireneusz Patalas

@Grzegorz: co do Entity Frameworka to niedawno znalazłem coś takiego jak Effort: http://effort.codeplex.com/ Wygląda całkiem zacnie, ale przyznam, że jeszcze nie sprawdzałęm, bo teraz jestem w innym projekcie i EF nie mamy. Co do fake’owania DateTime.Now to jest jeszcze jeden fajny sposób, który mi się bardzo podoba, bo nie wymaga żadnych zmian w kodzie (no prawie… ale o tym zaraz). Fody.Ionad (https://github.com/Fody/Ionad). Dla tych co nie znają Fody to w dużym uproszczeniu można za jego pomocą (a dokładniej jego pluginów) dokonywać “post-processingu” kodu tuż przed jego kompilacją. Nie ma to wpływu na oryginalne pliki z kodem, ponieważ dzieje się to… Read more »

Piotrek
Piotrek

@Maciek
Co rozumiesz pod pojęciem “… nadużywanie automocking containers…”? W tej chwili widzę więcej zalet stosowania ich niż wad, no ale może są jakieś wypowiedzi mądrych głów, które chętnie przeczytam, żeby zgłębić temat… bo może się okazać że mam oczy szeroko zamknięte w temacie ;)

Ireneusz Patalas
Ireneusz Patalas

@procent: Zgadza się, że code weaving to nie jest dobra metodologia do pisania aplikacji, ale… to jest tylko narzędzie i podobnie jak nóż może zostać użyte dobrze lub źle :) Ja Fody znam głównie z pluginu do INotifyPropertyChanged, o którym wspominaliście z Basią przy okazji AOP i tam nadaje się to wg mnie świetnie. Oczywiście zaciemnia częściowo kod, bo to dzieje się jakby poza kontrolą, ale w tym przypadku chyba jednak wole nauczyć wszystkich jak to działa niż mieć klasy modelów z ręcznie zaimplementowanym tym interfejsem dla każdego propsa rozdmuchane na 3 kilometry. W przypadku DateTime.Now jestem nawet w stanie… Read more »

Piotr Perak

Hej! Testy to temat mi również bardzo bliski. Co do różnic pomiędzy stub-ami i mock-ami to trochę zagmatwaliście :). Jest jedna, logiczna. Fizycznie niczym się od siebie nie różnią. Na stub-ach nie robimy asercji/weryfikacji. Robimy to na mockach. Stuby zapewniają niezbędne dane wejściowe, mocki pozwalają weryfikować poprawność działania kodu. Częstym błędem jest robienie asercji na obiektach, które powinny być traktowane jako stub-y w danym teście. Co do testowania metod prywatnych to ja akurat nie widzę żadnego problemu. Tego po prostu się nie robi :) Prywatne metody to szczegół implementacyjny. Testujemy interfejs publiczny klasy. To, że metoda publiczna woła 10 metod… Read more »

Piotr Perak

A jeżeli w wyniku refactoringu z metod prywatnych powstaje klasa to wcale nie trzeba jej wstrzykiwać. Co więcej, wcale nie trzeba pisać dla niej nowych testów. Te testy już istnieją! To testy klasy, która zawierała te prywatne metody wyniesione do nowej klasy. Pisał o tym kiedyś na swoim blogu Uncle Bob.

Piotr Perak

Czy wszystko nazywamy mockami, czy część stubami, a część mockami nie ma takiego znaczenia. Ważne, abyśmy wiedzieli na czym nie powinniśmy robić asercji. Co do SRP to nie musimy o tym pisać. Jasne, że zgodność z nią najpierw. Jakoś nie czuję tego ze złożonością metody prywatnych. Z definicji wykonują one część pracy metod publicznych. Jeżeli złożoność metody publicznej to jej kod + kod wywoływanych metod prywatnych to siłą rzeczy metody publiczne są bardziej skomplikowane niż metody prywatne. I każda ścieżka w metodzie prywatnej jest osiągalna przez interfejs publiczny klasy. Jeżeli nie, to można taką ścieżkę usunąć, bo jest nieużywana. U… Read more »

Grzegorz
Grzegorz

No no ładnie się tu porobiło :-) @Ireneusz Patalas – dzięki za wskazówkę – bedę to maglował z szefem – szczególnie ze zapytania testuje w LinqPad’dzie i nie widze tutaj wiekszego sensu na inne testy. @Maciej Aniserowicz – fajni by bylo uslyszec cos na temat testo UI – ja osobiscie zrobiłem piersze kroki w Selenium z driverem pod IE i firefoxa oraz w zeszlym roku zautomatyzwoalem testy UI dla aplikacji formatkowej uzywając SIKULI (no i się trochę pytona poduczyłem) Testy UI są dla mnie o tyle ciekawe, gdyz dziś UI tak napradę decyduje o sprzedazy aplikacji i odbiorze przez klienta,… Read more »

Grzegorz
Grzegorz

i przepraszam za pozjadane znaki…. byłem przed przerwą śniadaniową :P

Piotr Perak

@Grzegorz

Jeżeli chodzi o mockowanie EF to jest to bardzo proste. Tworzysz interfejs np. IMojDbContext, który jako właściwości ma IDbSet. W testach korzystasz z InMemoryDbSet i ot cała filozofia. Tylko bądź świadom jednej rzeczy. Teraz zapytania to LinqToObjects, a więc przejdzie wszystko. Te same zapytania odpalone na bazie danych mogą być nie wspierane. Więc to kwestia dyskusyjna, czy te testy coś dają.

Bogusz
Grzesiek Gałęzowski
Grzesiek Gałęzowski

Dzięki za dev talka! Zanim skomentuję (i ktoś odbierze mnie jako agresora który się czepia :-)), chciałem napisać, że fajnie się słuchało, miło było poznać Wasze doświadczenia i że ten dev talk był dla mnie pożyteczny. A teraz komentarz :-) Osobiście szkoda mi trochę, że mówiąc o mockach skupiliście się na temacie Constrained/Unconstrained (może tytuł powinien być troszkę inny?), a pominęliście podstawowe źródło wiadomości na ten temat, czyli Growing Object Oriented Software Guided By Tests. Niestety, jakoś w .NETowym środowisku ignorowanie tej książki i tego co w niej jest napisane jest zjawiskiem powszechnym. Chyba nawet sam Roy Osherove przeczytał ją… Read more »

Grzesiek Gałęzowski
Grzesiek Gałęzowski

Eh, wygląda na to, że zjadło mi wszystkie biało znaki :-(. Przepraszam za tę “zupę” powyżej…

Qba
Qba

@Maciej Aniserowicz
Co myślisz o urozmaiceniu dev talków o video w którym byłoby widać prowadzącego i gościa. Oczywiście osobno, wystarczyłoby włączyć kamerke podczas rozmów.

Paweł Klimczyk

@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: UI Testing – temat na osobny podcast :) W tym podkascie chodzilo o pokazanie samej idei mockow. @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.… Read more »

Grzesiek Gałęzowski
Grzesiek Gałęzowski

@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 –… Read more »

Moja książka

Facebook

Zobacz również