Wiedz, że coś się dzieje…

Ostatnimi czasy, mam okazję tworzyć dość duże ilości testów jednostkowych. Zwykle tworze je do cudzego kodu, co pozwala mi w pewnym sensie ocenić jego jakość. Zapytacie może, jak proces pisania testów jednostkowych do istniejącego kodu pozwala ocenić jego jakość ?

Otóż, pewna stara programistyczna fama głosi, że gdy kod jest łatwo testowalny, to prawdopodobnie jego jakość, a przynajmniej architektura będzie wysokiej jakości. Automatycznie na myśl przychodzi takie proste rozwiązanie, że skoro kod ma być łatwo testowalny, to najlepiej by było zacząć jego tworzenie od napisania testów. Takie podejście nazywa się TDD (Test Driven Development). Pewnie wielu z Was słyszało o takim podejściu, natomiast jeżeli pracujecie w typowej firmie wytwarzającej “stronki”, to pewnie nie mieliście wielu okazji by zastosować takie podejście.

Oczywiście nie koniecznie jest to grzech – w prostych projektach zastosowanie TDD może być dyskusyjne ze względu na narzut czasowy jaki generuje. Znając jednak życie, prosty projekt zwykle przeradza się w projekt skomplikowany, którego skali nikt nie przewidział.

Abstrahując jednak od TDD, chciałbym się podzielić z Wami, moimi spostrzeżeniami na temat typowych “wzorców” w kodzie, które znacząco obniżają jego testowalność. Przy okazji zaproponuje sposoby ich rozwiązania poprzez refaktoring kodu oraz omówię konsekwencje jakie niosą za sobą poszczególne antypatterny.

Tak więc, jeżeli spotkasz jeden z podanych poniżej przypadków – wiedz, że coś się dzieje 😉

  1. Testując dany obiekt sprawdzam jego stan po wywołaniu danej metody:
  2. Testując dany obiekt tworzymy mocki obiektów od których jest zależny w sposób łańcuchowy
  3. Testując dany obiekt łapiemy się na tym, że testując metodę publiczną w istocie chcielibyśmy przetestować metody prywatne z których ona korzysta
  1. Rodzyn says:

    Ano i wszystko się sprowadza do dobrego “application logic decoupling” oraz “single responsibility principle” :)

    BTW.
    Mogłeś użyć w przykładach jakiś assercji zamiast if’ów i printów – mogłoby być czytelniej (a też chętnie bym zobaczył jak real testing w Scali wygląda :) )

  2. Ano mogłem 😛 ale chciałem, żeby to było jak najbardziej straightforward. Poza tym, solucji do testowania w Scali jest kilka, z tego co się orientuje, oprócz JUnit like, są też oparte na specyfikacjach takich jak w Rubym jest RSpec czy coś.

    Co do SRP i decouplingu to oczywiście masz racje – stosowanie tych technik daje zawsze dobry kod. Ja chciałem jednak pokazać dlaczego kod stworzony przy użyciu tych technik jest lepszy i jak wygląda typowy zły kod i co złego on robi :)

  3. wookieb says:

    O ile dobrze pamiętam to scala sama w sobie posiada narzędzie do testów.

  4. @wookieb – to fakt, jest paczka scala.testing i tam m.in SUnit :)

  5. Hitsu says:

    Ooo Scala, taki pomieszany Ruby z Javą. :)

    Te przykłady to napisałeś w Scali tak “4FUN”, mam rozumieć że nie korzystacie ze Scali w Sabre?

  6. @Hitsu – nie korzystamy ze Scali w Sabre. Natomiast ja osobiście bardzo intensywnie interesuje się tym językiem, dlatego uznałem, że był to dobry powód, żeby coś w Scali przy okazji po kodować :)

  1. There are no trackbacks for this post yet.

Leave a Reply

Notify me of followup comments via e-mail. You can also subscribe without commenting.