Nienawidzę pisania testów…

Odpowiedz Nowy wątek
2017-04-20 13:46
1

Tak, wiem, to pewnie źle. Ale nienawidzę tego. To jest żmudne, nudne, uciążliwe do kwadratu.

Jeśli nikt nade mną nie wisi i nie każe pisać testów, to zwykle albo zakładam, że to, co napisałem jest OK (jeśli to jest na tyle proste, że po prostu widać), albo testuję na bieżąco ręcznie, jeśli mam wątpliwości. Sam dla siebie piszę testy tylko wtedy, jeśli coś jest dla mnie naprawdę trudne i przewiduję, że bez tego nic nie zrobię.

Być może jak będą nade mną wisieć dostatecznie długo żądając, bym zawsze pisał testy do wszystkiego, cokolwiek napiszę, to mi to tak wejdzie w krew że tak jak każdy „rasowy programista” nie będę wyobrażał sobie pisać czegokolwiek inaczej jak tylko według test-driven design, a jak tylko ktoś powie mi / napisze to, co ja piszę teraz, to zrobię double facepalm (co niewątpliwie każdy z Was zaraz zrobi). Do tego czasu pozostaje mi zastanawianie się, czemu muszę tracić tyle czasu na coś tak żmudnego, jak pisanie testów.

edytowany 1x, ostatnio: kmph, 2017-04-20 13:46
A wszystko dlatego, że tym razem w zadaniu akademickim zażądano, by oddać zadanie z testami. - kmph 2017-04-20 13:50

Pozostało 580 znaków

2017-04-20 13:52
0

moderatorzy chyba spia ostatnio. Ostatnimi czasy na tym forum coraz wiecej shitpostow sie pojawia od gimbów i żadne stosowne działania nie są w tym kierunku podejmowane..

edytowany 1x, ostatnio: rafallvlup, 2017-04-20 13:53
Co jest złego w pytaniu? Każdy ma prawo czegoś nie wiedzieć bądź nie być pewien - właśnie w tym celu powstało forum: aby wymieniać swoje zdania na dany temat. - Patryk27 2017-04-20 13:57
btw. OP ma trochę reputacji na forum i niekrótki staż - axelbest 2017-04-20 13:59
podobne poglądy wyznają programiści z wieloletnim stażom - LukeJL 2017-04-20 16:34
TDD to nie pisanie testów. - somekind 2017-04-21 02:22

Pozostało 580 znaków

2017-04-20 13:54
8

Jak kiedyś będziesz pracował przy dużym projekcie, w którym nie ma testów i zaczną się różne dziwne rzeczy wywalać, albo ludzie zaczną zgłaszać błędy to sam się przekonasz, że warto pisać testy :). Plus testy to mega dobra dokumentacja. "Tracisz" czas na napisanie testu, ale później nie tracisz na rozkminianie o co Ci chodziło w tej metodzie/klasie/funkcji.

Pozostało 580 znaków

2017-04-20 13:54
3

Czy jeśli dziś napisałeś poprawną funkcję/metodę i ją przetestowałeś ręcznie, to czy przetestowałeś ją dla każdego przypadku?
Czy dałbyś uciąć rękę za swój kod, gwarantując tym samym że będzie działał bezbłędnie w projekcie, którego LOC rozrośnie się do kilku milionów?

Nigdy Ci się nie zdarzyło zaprogramowanie czegoś, żeby po kilku miesiącach mieć problem w stylu "No kurde.... do tej pory działało".

Jeśli miałeś chociaż jedną taką sytuację to jest już pora by pisać takie testy, albo wiedzieć o ich pożyteczności. A jeśli nigdy nie miałeś takiej sytuacji, to ja z wielką chęcią spojrzałbym w jakiś nawet krótki fragment Twojego kodu.

Pozostało 580 znaków

2017-04-20 13:59
3

Taaaaak... a bez dobrych unit testów robisz tak: uruchamiasz apkę, klikasz tu, klikasz tam, czekasz na zasilenie grida, klikasz tu i masz wynik. Oczywiście jak apka jest webowa to jeszcze IDE odpali Ci serwer www do tego....

A wiesz co robię gdy mam do tego ładnie zrobiony unit test? Wciskam w visualu Ctrl+R+A - tyle i już wiem czy jest poprawnie czy nie. Jakbym miał przeklikiwać się 20 razy przez wszystkie moduły po to żeby przetestować to czy tamto to bym się chyba zastrzelił.

Wygoda ;)

Ja wiem, że na studiach uczą pisać testy do metody typu dwa plus dwa, że to bez sensu etc. ale zaswiadczam Ci, że nauka nie pójdzie w las.

edytowany 4x, ostatnio: grzesiek51114, 2017-04-20 14:06

Pozostało 580 znaków

2017-04-20 14:01
2

Aaa i bym zapomniał o najważniejszym! Testy "chronią" code base przed pisaniem spagetti code! Bo zanim napiszesz funkcję to dwa razy się zastanowisz, jak ja napisać, żeby test przeszedł i żeby test i funkcja była jasna i przejrzysta :).

Nie byłbym taki pewny. Pisząc testy równie dobrze można pisać spaghetti kod, myślę, że nawet łatwiej - bo są mniejsze konsekwencje (w końcu "działa? Działa.") - LukeJL 2017-04-20 16:39

Pozostało 580 znaków

2017-04-20 16:04
1
  1. Testy automatyczne to dopiero któreś z kolei narzędzie w zapewnianiu niezawodności - dość efektywne, ale nie idealne.
    (jak piszę testy to mmi to się zawsze przypomina dowcipy o indukcji wg fizyków (dla 3 się zgadza, dla 4 się zgadza, dla 5 też... czyli prawda)).
  2. Warto zawsze patrzeć wg wagi zagadnienia. Jak robisz coś dla siebie, sam, z powodu "niedziałania" nikt nie straci, i nie zginie : to spokojnie możesz olać :-)

Kiedy pisać test:

  • robisz coś z zespołem i dłużej (mam 8 ludzi w zespole, ponad 150 projektów/modułów (nie żartuje), sam nie wiem co robiłem w zeszłym tygodniu) - testy to wygodne narzędzie do zapisywania uzgodnień biznesowych - inaczej byśmy za często zmieniali zdanie i kręcili się w kółko.
  • pojawił się błąd - tak zwany Bug Driven Test - jak wyszedł Ci bug, to znaczy, że czegoś nie ogarnąłeś i jest duże prawdopodobieństwo, że znowu coś wyjdzie w tym miejscu kodu. Warto więc przed naprawieniem strzelić Test. To chyba najbardziej efektywne testy!,
  • nawet jak piszesz sam i eksperymentujesz, ale projekt może dłużej działać - to warto sobie przygotować fundament pod testy. Czyli w każdej warstwie przygotuj sobie choć test jeden. Wybieraj frameworki i biblioteki pod kątem testowalności. (Na przykład takie Javowe JavaEE w praktyce całkiem obsysa jeśli chodzi o testowanie),
  • testuj rzeczy które mają znaczenie. Przykładowo w wielu projektach WEB - wygląd często decyduje o przyciągnięciu lub odepchnięciu nowych użytkowników, a mimo to CSSy się sypią i nikt nie umie ich testować (btw. niestety nadal nie znam dobrego i prostego narzędzia do testowania wyglądu z automatu),
    ale już JavaScript testuje się bardzo dobrze i dużo to daje jak robisz typową webówkę.

TDD faktycznie pomaga na design systemu i zmniejsza niechęć do testów trochę. Pisze się łatwiej...
Po pewnym czasie tak łatwo, że możesz wpaść w pułapkę zwaną London school of TDD - piszesz szybko i dużo testów... które są bezwartościowe.

Co do alternatyw na testy: Ogólnie to wiele można osiągnąć na poziomie kompilatora, chłopaki od dependent types coraz więcej ciekawostek pokazują ... ale zanim zaczniemy tak programować to trochę jeszcze czasu minie.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 1x, ostatnio: jarekr000000, 2017-04-20 16:06

Pozostało 580 znaków

2017-04-20 16:10
1

Docenisz testy kiedy zaczniesz pracować nad niebanalnymi funcjonalnościami albo refaktoruzację kodu. Uwierz, ulepszanie kodu, które skutkuje psuciem już istniejącej funkcjonalności jest wk*****jące i mało produktywne. Mając testy automatyczne przynajmniej wyłapiesz to szybciej.

edytowany 2x, ostatnio: nalik, 2017-04-20 16:11

Pozostało 580 znaków

2017-04-20 17:08
1

Jeśli nikt nade mną nie wisi i nie każe pisać testów, to zwykle albo zakładam, że to, co napisałem jest OK (jeśli to jest na tyle proste, że po prostu widać), albo testuję na > bieżąco ręcznie, jeśli mam wątpliwości. Sam dla siebie piszę testy tylko wtedy, jeśli coś jest dla mnie naprawdę trudne i przewiduję, że bez tego nic nie zrobię.

Jeśli masz małą apkę to spoko, ale jeśli robisz coś większego to wcześniej czy później możesz dojść do sytuacji, kiedy zmiana jednej rzeczy w aplikacji może spowodować jakiś dziwny bug, który ujawnia się w jakiejś konkretnej sytuacji. Powiedzmy, że żeby temu zaradzić będziesz za każdym razem ręcznie sprawdzał wszystko czy działa. I okej - jak zaczynasz coś robić to odpalisz apkę, klikniesz dwa razy i widzisz czy działa. Narzut czasowy jakieś 10 sekund. No ale potem apka się rozrasta, Żeby posprawdzać wszystko będziesz potrzebował z minuty. A potem i z półgodziny nie starczy na ręczne przetestowanie wszystkiego.

Pisząc odpowiednie przypadki testowe można przyspieszyć sobie pracę i przetestować wszystko w parę sekund (czy nawet jeśli będzie to większa apka, to odpalenie wszystkich testów może trwać z kilka minut - ale to i tak szybciej niż byś to klikał samemu. Chociaż moim zdaniem testy trwające po kilka minut to też trochę patologia).

Można też zwiększyć niezawodność rozwiązań, bo jeśli zdefiniujesz konkretnie od a do z, jak aplikacja ma się zachowywać, to wystarczy, że odpalisz testy i sprawdzisz, czy dalej się tak zachowuje. To może cię ochronić przed błędami regresji ("działało, a nie działa").

Łatwiej też fiksować bugi. Gdy znajdziesz buga (które nie uwzględniły twoje testy), to piszesz przypadek testowy, i dzięki temu specyfikujesz jak system powinien się zachować. A potem fiksujesz buga i wiesz od razu "kiedy się zreperowało". Czyli masz szybką pętlę zwrotną nie działa - działa (czerwone czy zielone). A jak już zafiksujesz buga, to dzięki testom nie pojawi się ten sam bug w przyszłości (a raczej: jeśli się pojawi, to będziesz miał to wykryte od razu w testach)

Poza tym - czasem piszesz jakiś oddzielny moduł, który będzie dopiero później zintegrowany z resztą aplikacji. Nie możesz go ręcznie przetestować, bo po prostu nie bardzo się da (bo np. nie jest zrobiona jeszcze integracja z resztą projektu). Wtedy taki test może być twoim jedynym miejscem, w którym możesz faktycznie odpalić swój moduł (na tym etapie developerki)

Czyli testy są bardzo przydatne.

Chociaż zgadzam się z tobą, że nie zawsze się chce pisać (ale nie zawsze wszystko się chce - testy są nudne, ale takie właśnie mają być). Nie zawsze też wiadomo jak je w ogóle pisać, i w zasadzie co testować, co po łebkach, a czego testowanie można sobie w ogóle darować.

W każdym razie myślę, że pytanie nie powinno brzmieć "czy testować", ale "jak testować".


((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);
edytowany 4x, ostatnio: LukeJL, 2017-04-20 17:10
W każdym razie myślę, że pytanie nie powinno brzmieć "czy testować", ale "jak testować". - dokładnie - Maciej Cąderek 2017-04-22 19:28
Co jest często trudne, zaprojektować testy, które będą sprawdzac to, co trzeba i które przetrzymują próbę czasu (tj. nie będzie trzeba przepisywać testów przy każdej zmianie implementacji). Sam tego do końca nie opanowałem jeszcze. - LukeJL 2017-04-22 19:49

Pozostało 580 znaków

2017-04-20 17:11
V-2
8

Z twojego wpisu można wywnioskować, że wg ciebie zadaniem testów jest tylko i wyłącznie wyłapywanie bugów.

Tymczasem to nie jest jedyna, ani nawet - zaryzykowałbym - w praktyce nie jest to wcale główna funkcja kodu testowego.

Po pierwsze, jest on żywą dokumentacją tego, jak działa system. To jest bardzo istotny atut. W praktyce zawodowej nie pracuje się tylko z własnym kodem, i to kodem np. sprzed tygodnia. Komentarze się starzeją, a aktualność testów jest wymuszona ich naturą. Kiedy dziedziczę po kimś skomplikowany kod, w którym nie wszystko rozumiem, ale testy są wyczerpujące i nienagannie napisane - idę poczytać testy, i wszystko staje się jasne. To jak najlepszy tutorial. Dobre testy to żywa specyfikacja systemu.

Po drugie, testy same w sobie wymuszają lepszy i zdrowszy design: np. stosowanie luźnych zależności, SRP i inne.

Wydaje mi się, że prawdziwe pytanie, które powinieneś sobie postawić, brzmi - dlaczego pisanie (i utrzymywanie) testów jest dla ciebie tak żmudne, że aż go nienawidzisz.

Moim zdaniem świadczy to o tym, że się po prostu nie umie pisać dobrych testów... ani - tym bardziej - kodu produkcyjnego z myślą o testowym.

To nie zarzut: jest to trudna umiejętność i wyższa szkoła jazdy dla zaawansowanych. Nawet programiści ze sporym zasobem doświadczenia mają z tym kłopot.

Warto na ten temat poczytać i pouczyć się od ekspertów. Polecam np. stronę i wykłady tego gościa: http://artofunittesting.com/ - to niezły guru właśnie od tego tematu.

testuję na bieżąco ręcznie, jeśli mam wątpliwości

Ile trwa to testowanie ręczne, jeśli wywołanie buga wymaga uruchomienia aplikacji, zaaranżowania pewnej sytuacji, przeklikania paru ekranów? Ile zabierze łącznie czasu, jeśli musisz powtórzyć wszystkie IDENTYCZNE kroki każdorazowo po naniesieniu poprawki, żeby sprawdzić, czy już działa? Pisanie testów jest żmudne, a TO nie jest żmudne? :))


Nie ma najmniejszego powodu, aby w CV pisać "email" przed swoim adresem mailowym, "imię i nazwisko" przed imieniem i nazwiskiem, "telefon" przed numerem telefonu, "GitHub" obok linku do naszego profilu na serwisie GitHub, "typ niniejszego dokumentu" przed "curriculum vitae" ani "zdjęcie mojej głowy od przedniej strony" obok ewentualnego zdjęcia.
edytowany 2x, ostatnio: V-2, 2017-04-20 17:14

Pozostało 580 znaków

2017-04-21 00:59
0

Testy nie są po to, żeby testować czy coś działa zaraz po napisaniu.


"A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects." Robert Heinlein.
edytowany 1x, ostatnio: datdata, 2017-04-21 01:01

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