Testy jednostkowe w firmach. Typowe przykłady

Pracowałem już w 3 korpo, nigdzie nie było testów jednostkowych. Były inne powiedzmy testy, ale to nie miejsce i cel pytania, by o tym opowiadać.

Teraz zmieniam pracę, podobno mają być testy jednostkowe. Jak to będzie wyglądać w praktyce, to zobacze... ale chcę się trochę przygotować.

Jak u Was w firmach wygląda pokrycie kody testami jednostkowymi ?
Co testujecie, wszystko, czy tylko jakieś bardziej kluczowe elementy coś liczące (jakieś przykłady ?)

No bo np. dajmy na to piszemy endpointy restowe, to chyba bez sensu pisać do tego (dao, manager, wrappery itp.) junity, wystarczy jakis test, ktory odpala gotowe endpointy i porownuje outputy ? (mam racje)

Albo gui, dajmy na to jsf, czy wicket, chyba tylko testerzy to przeklikuja recznie, a gui nie jest junitowane ?

Jakies macie jeszcze przyklady, co junitujecie, a co nie ?

To co opisałeś to tylko test integracyjny i to pewnie na zasadzie "sanity test". Testy jednostkowe pisze się zwykle na małe kawałki kodu żeby później wyłapywać błędy podczas refaktoringu na przykład.

no tak, to integracyjny w kontekscie testowania restow. Bo ja nie widze sensu pisac do nich junitow (moim pytaniem bylo, czy tez sie zgadzacie z takim przemysleniem - jesli chodzi o testy to nie mam wiedzy za wielkiej)

A Wy w firmach (jesli u Was jednostkowe testy sa popularne), to co i jak, tak mniej więcej testujecie ?

U mnie wyznajemy zasadę testujemy jednostkowo logikę biznesową. Jeżeli piszesz 'perfekcyjny' kod, to testujesz tylko serwisy :P

ok, coś czuje, że te slogany typu "wysokie pokrycie kodu" to bardziej pic na wode, niz trend :P

W typowych korpo liczy się dostarczanie bussiness value, a nie jakieś tam testy. Przykładowo teraz walczymy o JEDEN sprint na refaktoryzację i pisanie testów, bo projekt odziedziczyliśmy taki w którym jest 20k linii kodu i 100 linii testów (wszystkich).

Koziołek napisał(a):

W typowych korpo liczy się dostarczanie bussiness value, a nie jakieś tam testy.
To niestety smutna prawda. Wszędzie mówi się o wysokich standardach kodu, testowaniu itp a w praktyce wygląda to tak, że pisze się kod - powiedzmy delikatnie - średnio dobry, testy się pomija i wrzuca na produkcję z założeniem jakoś to będzie. Na 4 firmy dla których kodowałem/koduję tylko w jednej były testy (jednostkowe i funkcjonalne) i jeśli nie przeszły to kod nie był brany do repo.

Znam przypadek gdzie klient chciał 50% pokrycia kodu, potem zaszalał i powiedział 60% aż w końcu stwierdził doszedł do tego że kod musi być pokryty w 90%

Skończyło się na tym że pokrycie było niemal 100 procentowe ale testy niczego nie sprawdzały i zostały napisane tylko po to żeby podbić licznik a wyglądały w stylu

[Fact]
public void JakasMetodaTest()
{
    Assert.DoesNotThrow(() => new JakasKlasa(null, null, 0).JakasMetoda(1, 2));
}

swoją drogą osobiście w firmie nie bawię się w testy jednostkowe - nikt tego tu nie robi, grzebię w cudzym kodzie który w ogóle jest trudno przetestować (twarde relacje, serwisy statyczne) i wydaje się że nie ma na to czasu

Prywatnie w domu klepię sobie jednak projekciki na boku i prowadzę je zgodnie z TDD - czyli najpierw staram się układać testy
Muszę powiedzieć że pisanie w ten sposób znacznie polepsza elastyczność kodu i jego projekt. W ogóle odpada faza projektowania bo projekt tworzy się sam podczas pisania testów; w dodatku projekt ten jest dużo bardziej życiowy niż ten który bylibyśmy w stanie wymyślić na sucho w głowie czy na kartce. Niekoniecznie więc pisanie testów zwiększa nakład pracy - po prostu faza projektowania z układania na szybko w głowie zamienia się na developerkę od pierwszej sekundy.
Suma sumarum może wyjść dużo szybciej a wymówka że nie ma czasu na pisanie testów w polityce firmy to bullshit (ale tego jeszcze nie jestem pewien).

Jest jeszcze taka zasada jak 1-10-100: http://analizait.pl/2012/zasada-1-10-100/
Najgorsze jest gdy klient dostaje aplikację z błędem a potem trzeba tak nanieść poprawki żeby program był ze sobą wstecznie kompatybilny

Polecam: http://www.benedykt.net/2013/08/12/tdd-i-popularne-wymowki/

To że w Twojej firmie nie ma zwyczaju pisać testów to nie znaczy że nie powinieneś ich pisać i jest to żadne wytłumaczenie przed przyszłym pracodawcą

Trochę powiało hipokryzją - mówię że nie ma wymówki na niepisanie testów a jednocześnie przyznaję że ich nie piszę.
Po prostu wydaje mi się że mam jeszcze za małe doświadczenie i zbyt małą pewność siebie - nie jestem pewien czy będę umiał wszystko przetestować i czy nie stracę za dużo czasu w pracy - jak się bardziej wprawię prywatnie to zdecydowanie zacznę wykorzystywać testy także w pracy

Swoją drogą pewnego rodzaju testy pisałem zawsze - nie raz jakiś bardziej skomplikowany algorytm wydzielałem do osobnego projektu w którym go dopracowywałem podając dane w konsoli i sprawdzając wyjście. Gotowy algorytm kopiowałem z powrotem do aplikacji gdzie już uznawałem go za poprawny

Prywatnie w domu klepię sobie jednak projekciki na boku i prowadzę je zgodnie z TDD - czyli najpierw staram się układać testy
Muszę powiedzieć że pisanie w ten sposób znacznie polepsza elastyczność kodu i jego projekt. W ogóle odpada faza projektowania bo projekt tworzy się sam podczas pisania testów; w dodatku projekt ten jest dużo bardziej życiowy niż ten który bylibyśmy w stanie wymyślić na sucho w głowie czy na kartce.

Badania naukowe tego nie potwierdzają [1, 2]. Tzn. nie potwierdzają, że TDD znacząco poprawia elastyczność kodu, projekt, jakość produktu czy produktywność programistów. Moje doświadczenie w recenzowaniu kodu pisanego przez jednych z topowych programistów [3] też pokazują, że TDD nie zastępuje fazy projektowania w głowie czy na kartce. Otóż u nas bardzo rzadko wrzuca się coś bez testów, a mimo to wielokrotnie podczas review wychodziły konkretne zastrzeżenia odnośnie projektu / architektury. Wysokie pokrycie testami jakoś temu nie zapobiegło. Testy jednostkowe są użyteczne, ale nie są "silver bullet" na wszelkie bolączki projektu.

Nie przeczę, że TDD poprawia testowanie kodu w porównaniu z całkowitym brakiem testowania, ale inne efekty są raczej mocno przesadzone. I podejrzewam, że dlatego w wielu firmach się TDD nie stosuje, za to stosuje się inne formy testowania (integracyjne, akceptacyjne itp.). Testy jednostkowe mają tendencję do łapania trywialnych błędów, które i tak łatwo wyłapać i zdebugować, natomiast testy integracyjne/funkcjonalne łapią znacznie "ciekawsze" przypadki i IMHO wnoszą znacznie większą wartość do projektu.

I jeszcze taka ciekawostka: częściej zdarzało mi się, że test jednostkowy się wywalał przez błąd w teście niż przez błąd w testowanym kodzie. Wydaje mi się, że to wynika chyba dlatego, że przypadkom testowym poświęca się jakoś znacznie mniej uwagi, a do tego przypadków testowych jest znacznie więcej niż przypadków w testowanym kodzie - tj. kod jest ogólny, a testy są bardzo specyficzne.

Natomiast jeśli firma nie stosuje testowania w żadnej postaci w ogóle, to zdecydowanie trzymałbym się od takiej firmy z daleka.

[1] http://madeyski.e-informatyka.pl/download/Madeyski05b.pdf
[2] http://dl.acm.org/citation.cfm?id=1968311
[3] że są dobrzy to wiem, bo część pracowała wcześniej w Google/Apple/Microsoft, a część odeszła tamże i raczej nie miała problemów się dostać; część kończyła uczelnie typu Stanford/Berkeley gdzie raczej słabi się nie utrzymują