[UT-0] Zapowiedź minicyklu o testach

8 sierpnia 2011 06:48 w kategorii: pro
Tagi: ,

Wożę się z tym tematem od nie wiem już kiedy i niejednokrotnie pisałem, że coś takiego zamierzam. Teraz akurat nadszedł taki okres, że mam czas na trochę więcej pisania, więc się mobilizuję i rozpoczynam wreszcie swój blogowy minicykl o testach (głównie jednostkowych) na platformę .NET. O testach napisałem już sporo notek... pora na więcej:).

Od wielu miesięcy spisywałem kluczowe pojęcia i myśli, jakie mnie nachodziły podczas programowania i testowania. Kilka tygodni temu zebrałem to wszystko w kupę i przygotowałem wystąpienie na Politechnice Białostockiej na ten temat. Teraz będę starał się tekstowo wylać z siebie to co mam do przekazania.

Nie będzie to raczej poziom testowej rocket-science, chociaż mam nadzieję, że każdy znajdzie w nadchodzących postach coś interesującego... no i że ja sam także czegoś się nauczę z komentarzy, na które jak zawsze liczę:).

Przewidywana agenda minicyklu (pokrywająca się właściwie z agendą mojej prezentacji - nie ma co wynajdywać koła na nowo, skoro raz już wszystko zorganizowałem):

0. Spis treści

1. Co to są i po co są testy jednostkowe?

2. Czym testować?

3. Mocki

        3.1 O mockach jeszcze słów kilka

4. Co testować, a czego nie testować?

        4.1 (Nie)Testowanie metod prywatnych

5. Kiedy testować?

6. Jak testować?

        6.1 Jak nazywam testy

7. ...

W miarę pojawiania się kolejnych wpisów będę tutaj linkował w odpowiednie miejsca. Let the testing begin!

[update 12/12/2011: pierwotny planowany spis treści uległ zmianie, więc kolejne punkty będą się tutaj pojawiały wraz z postami]


Komentarze

dotnetomaniak.pl

8 sierpnia 2011 08:01

Zapowiedź minicyklu o testach

Dziękujemy za publikację - Trackback z dotnetomaniak.pl

dasm

8 sierpnia 2011 09:35

Super. Pomimo tego, że z .Net mam niewiele wspólnego, to i tak z chęcią posłucham/poczytam na temat unittestów.
Jaki przewidujesz czas publikacji? Co tydzień, tak jak każdy dobry serial (i oczywiście każdy kolejny odcinek z cliffhangerem (chciałem napisać hangoverem, ale na szczęście sprawdziłem, że się mylę ;P)) czy może z większą częstotliwością?

procent

8 sierpnia 2011 09:44

dasm,
Ciężko powiedzieć, nie chcę nic deklarować/obiecywać/zobowiązywać się do czegokolwiek. Pierwsze 3 odcinki mam napisane i one ukażą się pewnie w ciągu najbliższych 2 tygodni. Reszta - zobaczymy jak będzie u mnie z weną i czasem:).

Galaktyczny_Joe

9 sierpnia 2011 07:36

Super! Pełen odjazd! Spadasz mi z nieba, bo właśnie czegoś takiego potrzebuje!

O testach nie raz słyszałem, ba nawet mam czytankę "JUnit. Pragmatyczne testy jednostkowe w Javie" i osobiście nie chcę, abyś zmierzał w kierunku podania regułek i przedstawienia API od biblioteki unitów. Ja jestem z grona osób uświadomionych znaczenia testów, ale mam problemy z praktycznym ich wdrożeniem.

Są opinie, aby testy budować, przed tworzonym kodem, albo tworzyć test zaraz po zbudowaniu funkcji. W moim przypadku to się nie sprawdza, bo co mi z testów, jak za 2-3 dni doznam oświecenia i kod zmienie. Wtedy czas poświęcony na testy szlag trafi.

Druga sprawa to już sposób tworzenia tych testów. Jasne wiem o co biega, mam przed wywołaniem funkcji i po wywołaniu funkcji przebadać tak funkcje, by doprowadzić ją do załamania. W sensie co się stanie gdy podam null, albo liczbę ujemną i tak dalej. W każdym razie taki mój test to koszmar. Kodu testującego jest tyle ile piachu na plaży, i nie jest to ani ładne ani czytelne. Łapie wyjątki, stosuje refleksje pod prywatne metody i na każdym kroku mam wywołania libu junit. Piekło! Sam kod testów stanowił około 80% całej pracy. Najbardziej mnie wkurza rzecz, gdy tworzę małą klasę i na nowo musze do niej testy budować mocno przewyższające ilośc kodu w tej klasie. Ogólnie źle mi się śpi po dniu z testami, może robię coś źle, może jeszcze mało rzeczy wiem?

W każdym razie jedno jest pewne, nie chce od Ciebie dowiadywać się czym są testy jednostkowe, ale jak powinno się je efektywnie i poprawnie implementować.

Tomek

9 sierpnia 2011 22:40

Witam.

Jestem mało doświadczonym programistą i zastanawiam się, jak wygląda wykorzystanie UT w realnych projektach . W mojej obecnej ( poprzedniej też ) firmie intensywnie korzystamy z SQL Server, wszystko bazuje na procedurach składowych i w nich jest zaszyta logika aplikacji. Kod c# służy właściwie tylko do oprogramowania endpointów: przekazania danych do i z procedur. Da się wdrożyć UT przy takim podejściu ? Da się zastosować UT w procedurach składowych ?

Pozdrawiam.

procent

9 sierpnia 2011 23:32

Galaktyczny_Joe,
Że spadam z nieba - to spoko:). A co się pojawi w nadchodzących postach to już inna sprawa. Jeśli nie spodoba się sposób przedstawienia tematu to zawsze można podrążyć w komentarzach.

procent

9 sierpnia 2011 23:34

Tomek,
Pewnie się da, ale nigdy tego nie robiłem i mam nadzieję że nigdy tak robić nie będę musiał. Miejsce na logikę to cywilizowany język programowania, a nie procedury w SQL.

kazio0

10 sierpnia 2011 10:59

no to teraz przez wpis "Miejsce na logikę to cywilizowany język programowania, a nie procedury w SQL." mam sieczkę w głowie. Bo teraz jestem na etapie prac przygotowawczych w celu napisania pracy inżynierskiej. Ciągle nas na uczelni uczyli, że ze względu na szybkość działania powinno się pisać procedury SQL i wyciągać z bazy już przetworzone dane, ponieważ baza to zrobi szybciej niż nasza aplikacja. I teraz pytanie czy znajdę gdzieś jak powinno się pisać profesjonalne duże aplikacje internetowe? Chodzi mi o dostęp do danych.

procent

10 sierpnia 2011 22:44

kazio0,
Mnie też na uczelni uczyli że procedury to idealne rozwiązanie. Z tym że na uczelni uczą ludzie, którzy programowanie znają tylko z książek a nie z codziennej pracy (tak przynajmniej było u mnie).
Wszystko ma swoje zastosowania, jednak język TSQL służy do operacji na relacyjnych danych, a nie do implementowania logiki biznesowej.
A dostęp do danych w dużych profesjonalnych aplikacjach internetowych... poszukaj hasła "nhibernate in asp.net".

Artur

11 sierpnia 2011 09:22

@kazio0
"ponieważ baza to zrobi szybciej niż nasza aplikacja" - zgadza się. A jak aplikację napiszesz w assemblerze, to będzie działać szybciej niż w C#. Odpowiedz sobie na pytanie, czy Twoja aplikacja tego wymaga.

agilesurfing.pl

11 sierpnia 2011 10:43

Pingback from agilesurfing.pl

Automatyczne testowanie kodu – jak to robić? | Agile Surfing

Grzegorz Dziemidowicz

11 sierpnia 2011 10:56

@Galaktyczny_Joe:
"stosuje refleksje pod prywatne metody" - w jakim celu? ;)

"Sam kod testów stanowił około 80% całej pracy" - takie proporcje mnie osobiście nie przerażają, pod warunkiem że kod testów jest porządnie napisany  (czytelny, "nie kruchy") i testuje to, co ważne dla biznesu.

@procent: Miło mi będzie, jeśli rzucisz okiem na mój post o automatycznym testowaniu kodu i dorzucisz swoje 3 grosze (czy się z czymś nie zgadzasz, czy coś ważnego pominąłem?)

Pozdrawiam
dziemid

procent

11 sierpnia 2011 19:26

Grzegorz,
Done, dopisałem komentarz:).

Maciej Aniserowicz

22 sierpnia 2011 07:00

[UT-3] Mocki

[UT-3] Mocki

mzalewski.net

29 sierpnia 2011 00:49

Pingback from mzalewski.net

JustMock, czyli proste testowanie zależności zewnętrznych - Notatnik programisty .NET | Notatnik programisty .NET

Komentarze zamknięte