DevTalk Menu

Viewing all items for tag tests

Permalink:

58 – O Refactoringu z Łukaszem Karskim

(comments are closed)

Łukasz KarskiI stało się, dojechaliśmy do końca trzeciego sezonu podcasta DevTalk! Wielkie dzięki za to, że jesteście, słuchacie i dajecie feedback. Już po raz 58. witam się w Wami przed mikrofonem. Wow.

Dzisiejszym naszym Gościem jest Łukasz Karski. Programista z wieloletnim doświadczeniem, pełen interesujących obserwacji dotyczących naszego rzemiosła, procesów i jakości programistycznej pracy.

Rozmawiamy o refactoringu. Możecie spodziewać się dużo tech-mięsa. Dużo testów. Dużo porad. Dużo dużo!

Ten odcinek dostarcza nam wszystkim firma Ivanti: diamentowy sponsor konkursu Daj Się Poznać. Dzięki serdeczne!

Ivanti_k

 

Czekamy na pytania i uwagi tutaj, w komentarzu do tego odcinka.

Zrób prezent przed wakacjami i kliknij kilka gwiazdek na iTunes, co Ty na to? 😉

Miłych wakacji, dzięki i pozdro! I… PLAY!

Czytaj dalej…

  • Thanks for leaving a comment, please keep it clean. HTML allowed is strong, code and a href.

Permalink:

12 – O mockach z Pawłem Klimczykiem

(comments are closed)

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.

Czytaj dalej…

  • 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. 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

    @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.

  • pokaż wszystkie komentarze (27)
  • Thanks for leaving a comment, please keep it clean. HTML allowed is strong, code and a href.

Permalink:

03 – O testach z Adamem Kosińskim

(comments are closed)

AdamW trzecim odcinku rozmawiam z Adamem Kosińskim – programistą, prelegentem, aktualnie kodzącym C# w Londynie.

Tematem przewodnim są testy jednostkowe – nasza wspólna pasja. Gadamy zarówno o najlepszych jak i najgorszych praktykach. Przestrzegamy też na to uważać podczas przygody z testowaniem. Zastanawiamy się również dlaczego czasami testy nie spełniają oczekiwań programistów i… i wiele więcej :).

Konkurs: dzisiaj rozdaję licencję na NCrunch. Jak miło! To niewiarygodne narzędzie otrzyma autor jednego z komentarzy pod niniejszym postem. Piszcie, piszcie, piszcie! Dzielcie się uwagami, opiniami. Co sądzicie o DevTalku i o tym odcinku? Co byście zmienili, a co się podoba? Nie trzeba napisać komentarza pozytywnego aby być wziętym pod uwagę podczas rozdania NCruncha :).

Uwaga: dzisiejszy odcinek powinien brzmieć lepiej niż poprzednie… bo już nie muszę robić wszystkiego sam! Zgłosił się do mnie Krzysiek Śmigiel wyciągając pomocną dłoń gotową zająć się obróbką “surowego” materiału audio. To zajmowało mi masę czasu, więc pomoc przyjąłem bez chwili wahania. Super, dzięki!

Logo: w poprzednim odcinku został ogłoszony konkurs na logo. Zwyciężył Rafał Sańda przysyłając projekt, który bardzo mi podpasował. Już teraz jest on wykorzystany na twitterze, fejsie, itunes itd. Wypas i awesome, dzięki!

Czytaj dalej…