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.
Montaż odcinka: Krzysztof Śmigiel.Ważne adresy:
- zapisz się na newsletter
- zasubskrybuj w iTunes, Spotify lub przez RSS
- ściągnij odcinek w mp3
Linki
- blog Pawła (http://blog.klimczyk.pl)
- 70. Spotkanie WROC.NET “Paweł Klimczyk – Constrained and unconstrained isolation frameworks in .NET” (https://www.youtube.com/watch?v=P_xmND3sdsY)
- Roy Osherove “Fifteen things I look for in an Isolation framework” (http://osherove.com/blog/2013/11/23/fifteen-things-i-look-for-in-an-isolation-framework.html)
- Martin Fowler “Mocks Aren’t Stubs” (http://martinfowler.com/articles/mocksArentStubs.html)
- mój blog – posty o mockach (http://devstyle.pl/tag/mocks/)
- narzędzia
- nSubstitute (http://nsubstitute.github.io)
- fakeiteasy (http://fakeiteasy.github.io)
- Moq (https://github.com/Moq/moq4)
- Rhino Mocks (http://www.hibernatingrhinos.com/oss/rhino-mocks)
- Typemock Isolator (http://www.typemock.com/isolator-product-page)
- Microsoft Moles (https://msdn.microsoft.com/en-us/library/ff798506.aspx)
Muzyka wykorzystana w intro:
“Misuse” Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0
http://creativecommons.org/licenses/by/3.0/
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);
}
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 »
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
@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 »
@Piotr,
Dokładnie, nawet o tym kiedyś pisałem: http://www.maciejaniserowicz.com/2013/02/14/testowanie-statycznych-wywolan-na-przykladzie-datetime-now/ .
Aktualnie używam innego, bardziej eleganckiego, sposobu (do którego nie ja doszedłem), może o nim też skrobnę :).
@Piotrek,
Ano tak, AutoFixture jest całkiem przyjemne o ile się go nie nadużywa. Dopóki robi co ma robić a ja nie piszę autofac-specific-code to jest spoko, w przeciwnym wypadku AutoFixture wędruje za okno (tak jak Automapper).
Temat automocking containers poruszyłem podczsas rozmowy żeby raczej “odchęcić” od ich stosowania.
Grzegorz,
No to gites, chwała i cześć i tak dalej :).
EF nie używam, ale bym nie mockował (tak jak nie mockuję NH). Kontakt z bazą danych powinien raczej siedzieć w komponentach które nie zawierają za bardzo logiki biznesowej – same klasy “logiczne” przyjmują dane jako parametry i wtedy te dane po prostu tworzysz w teście i przekazujesz. Jeśli mówimy o testach integracyjnych to stawiasz bazkę dla każdego testu i tyle. Ale tych testów w założeniu nie powinno być dużo, bo i za bardzo nie powinno być czego testować (poprawność zapytań linq?).
@Ireneusz Patalas, Fody to “code weaving” – coś wg mnie jeszcze gorszego niż wpinanie się do projektu przez profiler API jak to robi Isolator :). A tworzenie warstwy abstrakcji nad czasem nie jest tylko furtką dla testów jednostkowych – niedawno pisałem małą aplikację konsolową która zarządza procesem fakturowania, wysyłania płatników do windykacji itd. Proceserm tym rządzą oczywiście ściśle określone reguły mające w sobie dużo odniesień do czasu właśnie (wystaw fakturę, po 2 tygodniach wyślij przypomnienie, po kolejnych 2 drugie przypomnienie, potem -> windykacja). Klient mówi “chciałbym zobaczyć jak to działa”… i co ja mam mu powiedzieć: przetestuj dopiero w produkcji… Read more »
@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 ;)
Piotrek,
Automocking containers z mojej perspektywy:
1) ukrywają problem wielu zależności – jeśli mam klasę z 6 czy 10 parametrami, to jej przetestowanie POWINNO BYĆ TRUDNE, powinienem czuć dyskomfort ręcznie tworząc te 6 czy 10 mocków po to, żeby ten kod zrefactorować; automocking container to po prostu ukryje przede mną, a burdel zostanie
2) automocking container tworzy jakieś tam swoje instancje i żeby potem przetestować interackję SUT z zależnościami muszę ponownie robić resolve() na kontenerze w moich testach – samo założenie mi się nie podoba
@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 »
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 »
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, Jeśli trzeba wykonać asercję na obiekcie będącym stubem to oznacza to że to nie jest stub :) dlatego dla mnie wszystko jest mockiem i tyle, o to mi chodziło, Testowanie metod prywatnych – tak jest, nie robi się. Jeśli taka metoda jest na tyle skomplikowana że wymaga przetestowania osobno, to tak jak mówiliśmy wyciąga się ją do innej klasy. Nie jest to po to żeby cos było publiczne tylko dla testów, tylko po to żeby zachować SRP. Jeżeli metoda woła 10 metod pomocniczych to raczej wszystko to nie dotyka tylko jednego aspektu systemu i można z tego zrobić… Read more »
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 »
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 »
i przepraszam za pozjadane znaki…. byłem przed przerwą śniadaniową :P
@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ą.
Updated: DevTalk – Programistyczny głos w Twoim domu
http://groopmark.com/link/details/181/devtalk-programistyczny-glos-w-twoim-domu?cid=11
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 »
Eh, wygląda na to, że zjadło mi wszystkie biało znaki :-(. Przepraszam za tę “zupę” powyżej…
Dzięki za dyskusję,
Książka powędruje do Piotr Perak, a Grzesiek Gałęzowski będzie mógł pić kawę z DevTalkowego kubeczka :). Poszły maile z prośbą o adres.
@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.
Qba,
Zastanawiałem się nad tym i definitywnie tę opcję odrzuciłem. Podcast to podcast, gadające głowy można sobie puścić w tle w TVN24 :)
Piotr Perak wybrał kubeczek zamiast książki, więc książka powędruje do Ireneusz Patalas – poszedł mail z prośbą o adres :).
@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 »
@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 »