Jak się nauczyć testować?

Odpowiedz Nowy wątek
2017-10-25 18:17
1

Odczuwam irracjonalną niechęć do zmiany i dodawania nowych rzeczy do działającego kodu. Stwierdziłem, że pomóc mi może pisanie testów jednostkowych.
Szukając czegoś na ten temat w internecie znalazłem sporo artykułów lejących wodę, tłumaczących wszystkie drobiazgi w jUnit, ale nigdzie nie znalazłem faktycznie dobrych przykładów i porad. Same przykłady z testowaniem getterów i innych bzdur.

Jak się nauczyć pisać testy? Czy mam testować każdą metodę/klasę, a po jakimś czasie samemu stwierdzić co warto, a czego nie warto testować?


#define true (rand() % 2)

Pozostało 580 znaków

2017-10-25 18:28
2

Od tego możesz zacząć https://helion.pl/ksiazki/tdd[...]kent-beck,tddszt.htm#format/d.

Później jak się okaże, ze Twój kod to straszne gowno i nie da się testować przeczytaj to: https://helion.pl/ksiazki/pra[...]-feathers,prazav.htm#format/d

Jak juz coś tam zaczniesz testować to możesz czytać dalej w dowolnej kolejności:
https://www.amazon.com/Art-Unit-Testing-examples/dp/1617290890 oraz źródła wypisane tutaj https://stackoverflow.com/a/924639 (pierwsz odpowiedz)

edytowany 2x, ostatnio: Desu, 2017-10-25 18:33

Pozostało 580 znaków

2017-10-25 18:50
zz
0

Ta książka jest niezła (lub polskie wydanie):
https://www.packtpub.com/appl[...]/test-driven-java-development
Jest sporo przykładów nie tak całkiem trywialnych, a poza tym jest też o mockingu i BDD.

Pozostało 580 znaków

2017-10-25 19:08
1

Też polecam "TDD. Sztuka tworzenia dobrego kodu" Kent Beck.

Jak się nauczyć pisać testy?

Trzeba pisać dużo testów, zacznij od dzisiaj - od teraz.

Czy mam testować każdą metodę/klasę, a po jakimś czasie samemu stwierdzić co warto, a czego nie warto testować?

To zależy o jakich testach mówisz. Jeżeli masz na myśli jednostkowe to tak - trzeba testować każdą klasę i jej metody publiczne.

edytowany 2x, ostatnio: Markuz, 2017-10-25 19:09

Pozostało 580 znaków

2017-10-25 21:33
1

Również polecam TDD Kenta Becka - klasyka gatunku ;) Oprócz tego także ksiązke polskiego autora Tomka Kaczanowskiego - Practical Unit Testing with JUnit and Mockito. Jak dla mnie świetna pozycja dla początkujących


Limitations are limitless

> ##### Ola Nordmann napisał(a)
> Moim językiem ojczystym jest C++ i proszę uszanować to, że piszę po polsku.

Pozostało 580 znaków

2017-10-29 17:04
0

Dzięki za odpowiedzi. Zakręcę się przy pozycji pana Becka i po prostu postaram się pisać jak najwięcej testów.


#define true (rand() % 2)

Pozostało 580 znaków

2017-11-01 12:55
1

Jak się nauczyć testowania, a nie testować. Dopełniacz, a nie biernik. Proszę, nie kaleczmy naszego języka.

Co do meritum: testy jednostkowe zazwyczaj nie wystarczają, dopiero testy funkcjonalne potrafią wykryć różne nieprawidłowe zależności i działania.

Polecam także naukę wzorca projektowego TDD, czyli Test Driven Design.


edytowany 1x, ostatnio: TomRZ, 2017-11-01 12:55
Pokaż pozostałe 2 komentarze
Jest biernik (kogo? co?) testować, a powinien być dopełniacz (kogo? czego?) testowania. Jak nauczyć się (kogo? czego?) testowania. To są rzeczy ze szkoły podstawowej. - TomRZ 2017-11-02 11:16
Test Driven Design także jest poprawną nazwą tego wzorca projektowego, i jest używane zamiennie z Test Driven Development. - TomRZ 2017-11-02 11:18
Nie wierzę, że to się dzieje. :D :D :D - somekind 2017-11-02 11:32
Kolega chyba niedawno skończył podstawówkę (szkołę podstawową, ale chciałem specjalnie niepoprawnie - taki ze mnie anarchista) i szpanuje znajomością gramatyki. Szkoda, że w tak nieumiejętny sposób. Aż się ciśnie na usta / palce: "Przypadek? Nie sądzę" :) - Pipes 2017-11-02 17:16
"Jak się nauczyć testowania testować" jest poprawną polszczyzną... - koszalek-opalek 2017-12-04 15:52

Pozostało 580 znaków

2017-11-02 11:35
10
TomRZ napisał(a):

Jak się nauczyć testowania, a nie testować. Dopełniacz, a nie biernik. Proszę, nie kaleczmy naszego języka.

To nie jest biernik tylko bezokolicznik. To nawet nie jest rzeczownik tylko czasownik.

W tytule nie ma błędu, autor chce się nauczyć testować, tak samo jak mógłby chcieć nauczyć się biegać, jeść czy śpiewać. Mógłby też chcieć nauczyć się testowania, biegania, jedzenia i śpiewania. Bez różnicy.

W pełni popieram ideę niekaleczenia języka, ale żeby to wytykać trzeba mieć po pierwsze rację, po drugie rozróżniać podstawowe części mowy, no bo jednak pomylić rzeczownik z czasownikiem to trochę przypał. Wszakże to wiedza z pierwszych klas szkoły podstawowej.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
edytowany 1x, ostatnio: somekind, 2017-11-02 11:35
Ok, pomyliłem się i dowaliłem jak dzik w sosnę. Jednak dla mnie nadal zdanie brzmi ładniej przy zamianie testować na testowania. - TomRZ 2017-11-02 13:47
@TomRZ: dla mnie np. ładniej brzmi "otworzeniu" niż "otwarciu", ale co poradzę, że obie formy poprawne? :) - somekind 2017-11-02 14:17

Pozostało 580 znaków

2017-11-02 17:28
3

Parę istotnych faktów na temat testowania:

  • 100% pokrycia kodu nie znaczy, że apka działa idealnie
  • 100% pokrycia kodu w dużych projektach to niebotyczne osiągnięcie
  • QA jest ZAWSZE potrzebny - możesz przeklikać apkę, ale pozostali developerzy tego nie zrobią, nie nastawiaj się. Poza tym QA znajdzie coś, na co byś nie wpadł.
  • Testy jednostkowe nie są wystarczające - w grę wchodzą API testy, load testy etc.
  • Testy jednostkowe powinny pokrywać każdą klasę i każdą metodę / funkcję, najlepiej kilkoma różnymi testami, które sprawdzają kilka scenariuszy testowych
  • Nie powinieneś mockować klasy czy metody, a jedynie zewnętrzne zależności
  • CI, które nie puszcza zmian dalej, jeśli build nie przeszedł testów to bardzo dobry pomysł, ale nie jest to gwarancja, że apka się nie wysypie (patrz punkt pierwszy)
  • Testy jednostkowe stanowią istotny wyznacznik tego czy nie zrąbałeś podczas efaktorowania kodu

Przykład: masz metodę, która dodaje liczby.

Co możesz przetestować?
Zaczynasz od scenariuszy wykluczających np. w Javie masz statyczne typowanie, więc nic innego Ci się nie skompiluje i super, ale np. w Pythonie, Rubim czy Elixirze musisz zrobić unit testy, że np. stringi się nie dodadzą itp.

Potem przechodzisz do testów, które powinny Ci dać dobry wynik: duże liczby, małe liczby, liczby zmiennoprzecinkowe, liczby ujemne itp.

Zasada jest taka, że dobre testy jednostkowe zajmują sporo więcej miejsca, niż kod który testują. Jeżeli testujesz funkcję / metodę, która obsługuje logikę biznesową, to testujesz TYLKO ten fragment kodu. Reszta powinna być zamockowana, jeśli jest zależna od czegoś, albo z założeniem, że działa w 100% idealnie, aby móc jednoznacznie i deterministycznie stwierdzić czemu test nie przechodzi tj. czemu coś nie działa. Jeżeli Twój kod robi ify i elsy to powinieneś sprawdzić KAŻDY możliwy przypadek, dlatego dobre testy skłaniają do pisania dobrego kodu - zamiast mieć metodę z 4 ifami i 4 elsami, która sprawia, że masz 16 możliwości, piszesz metody, które mają jednego ifa albo nie mają go wcale- wtedy nie musisz tylu różnych scenariuszy testować.

Z własnego doświadczenia wiem, że jeżeli w życiu kodu nie widziałem to zaczynam od napisania do niego testów - poznaję jak toto powinno działać, widzę kiedy działa i potem dopiero mogę bezpiecznie w tym grzebać. Inaczej bałbym się takiego kodu dotykać.

Pozostało 580 znaków

2017-11-03 20:18
2

Uczyłem się testowania z książek Tomka Kaczanowskiego.

Polecam książki:
Practical Unit Testing (wersja JUnit lub TestNG)
Bad Tests Good Tests

Jak programujesz w .NET to też będą ok, bo w sumie to jest prawie to samo co Java. Pomogła mi też prezentacja Jakub Nabrdalik - Test Driven Traps:

Nie ze wszystkim się zgadzam, ale spoko źródło wiedzy.

edytowany 1x, ostatnio: margor90, 2017-11-03 20:24

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0