Recenzja The Art of Unit Testing

the art of unit testing cover

Będzie o cytatach z książki, jak również przemyśleniach do których skłoniła mnie książka (nie napisałem recenzji od razu po przeczytaniu i teraz nie pamiętam, co tam rzeczywiście było a co sam sobie dopowiedziałem;).

Ogólnie na plus

Żałuję, że nie przeczytałem tej książki już dwa lata temu. Dotychczas rzeczy w niej zawarte poznawałem dzięki czytaniu różnych artykułów, blogów itp. Zdecydowanie prościej przeczytać książkę, która to wszystko od razu systematyzuje i układa. Bardzo dobry punkt wyjścia.

Każdy kto chce wprowadzić u siebie testy (czy to we własnych jednoosobowych projektach czy w firmie), powinien wiedzieć, że na tym można się przejechać. Jest to sensownie podkreślone w książce. Są też ogólne porady w jaki sposób przekonywać ‚górę’ czy ‚dół’ do pisania testów.

Istotą testów jest to, że zwracają się na dłuższych dystansach, trzeba mieć tego świadomość. Jest też kwestia tego co to znaczy „zwracają”. Trzeba na cały proces tworzenia softu trochę inaczej spoglądać.

Mockowanie

moq logo

Dużo było poświęcone temu tematowi. Warto wiedzieć jak robić to dobrze.

Nie robiłem researchu, który framework (moq czy RhinoMocks) jest lepszy, ale z kilku opinii wynika, że moq. Jego wadą jest to, że można mockować tylko interfejsy i wirtualne składowe klasy. Osobiście moq załapałem od razu (już z rok temu?) posiłkując się tutorialem, a z Rhino szło mi jakoś oporniej. Może dlatego, że test, który poprawiałem był napisany metoda Record&Replay zamiast Arrange Act Assert.

Zrozumiałem też, że w niektórych testach zbyt dużo korzystałem z frameworków mockujących. Czasami trzeba napisać własny kod mockujący, lepiej dostosowany i czytelniejszy w naszej domenie.

Niektóre techniki były dla mnie trochę kontrowersyjne

Use property injection when default will not cause problems.

Zawsze wydawało mi się, że property injection jest jakieś dziwne. To niby muszę wstrzyknąć jakąś zależność, ale mogę też nie wstrzyknąć. Myślę tutaj nie tylko o zastosowaniu w testach ale ogólnie w kodzie. Nie przekonuje mnie nawet podany przez autora przykład gdy domyślna implementacja wystarcza na większość przypadków, a explicite ustawiamy inną.

Czynienie metod wirtualnymi dla potrzeby testów i ich przeładowywanie.

Może w Javie to działa lepiej (metody by default są wirtualne), ale w .NET jakoś wolę nie otwierać kodu w ten sposób. Wolę zawsze interfejs wstrzykiwać. Spróbuję jednak poeksperymentować z tym podejściem. W wielu przypadkach testy napisałyby się szybciej.

Krótko o tym co ważne

  • Autor proponuje ćwiczenie, żeby nie debuggować testów, tylko pisać je na tyle proste, żeby było wiadomo, że test nie ma buga i że implementacja nie ma buga. Już patrząc na kod powinniśmy wychwycić błąd.
  • Czytelność, czytelność, jeszcze raz czytelność.
  • Dobre testy trudniej napisać niż dobry kod.
  • Mock to nie stub.
  • Tylko jeden mock per test.
  • In chapter 7, we’ll take a look at the three basic pillars of good unit
    tests—readability, maintainability, and trustworthiness—and look at
    techniques to support them. If you only read one chapter in the book,
    this should be it.

Wdrażanie

Opisana była conwencja nazywania metod tekstowych:
[MethodUnderTest]_[Scenario]_[ExpectedBehavior] – akurat takiej konstrukcji nie widziałem nigdy (może dlatego, że jest słaba i po czasie nikt z niej nie korzysta;), więc wypróbowuję ją w zaciszu domowego kodu.

Napisałem w kilku miejscach czego się nauczyłem i co zamierzam stosować, ale na razie są to tylko teorie, po miesiącu korzystania może się okazać, że coś jest do bani. Postaram się wtedy tutaj zrobić jakieś podsumowanie. Czy ja napisałem po miesiącu? To są testy i na podsumowanie przyjdzie czas, gdy już zapomnę o tym poście.

Jakieś uwagi lub bardziej konkretne pytania co do książki?

Reklamy
Ten wpis został opublikowany w kategorii Programowanie i oznaczony tagami , , . Dodaj zakładkę do bezpośredniego odnośnika.