fbpx
devstyle.pl - Blog dla każdego programisty
devstyle.pl - Blog dla każdego programisty
2 minut

[UT-0] Zapowiedź minicyklu o testach


08.08.2011

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]

Nie przegap kolejnych postów!

Dołącz do ponad 9000 programistów w devstyle newsletter!

Tym samym wyrażasz zgodę na otrzymanie informacji marketingowych z devstyle.pl (doh...). Powered by ConvertKit
Notify of
dasm
dasm

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

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
Galaktyczny_Joe

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… Read more »

Tomek
Tomek

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

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

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
kazio0

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

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
Artur

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

Grzegorz Dziemidowicz

@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

Grzegorz,
Done, dopisałem komentarz:).

Moja książka

Facebook

Zobacz również