Mekkora nálatok a kódbázison a test coverage?

Szerszám

99-100% és ez így van jól
2% (4 szavazat)
99-100% és nem értem miért kell a legtriviálisabb függvényeknek is külön unit test
0% (0 szavazat)
50-99% és ez így van jól
13% (24 szavazat)
50-99% és szerintem csomó dologra felesleges volt unit tesztet írni
3% (5 szavazat)
10-50% és ez így van jól
4% (7 szavazat)
10-50% és keveslem, csomó minden máshoz is kéne szerintem
9% (17 szavazat)
<10%, inkább integration tesztjeink vannak, és ez így van jól
2% (4 szavazat)
<10%, inkább integration tesztjeink vannak, de szerintem sokkal több függvényre/osztályra kéne unit teszt
5% (9 szavazat)
Nincsenek se unit se integration tesztjeink és ez így van jól
8% (15 szavazat)
Nincsenek se unit se integration tesztjeink, pár integration teszt kéne legalább
1% (1 szavazat)
Nincsenek se unit se integration tesztjeink, nagyon sok helyre kéne unit teszt is
5% (10 szavazat)
Elvileg vannak unit tesztjeink, de régóta nem buildel / nem megy át senkinél, ignoráljuk
1% (2 szavazat)
Nem dolgozom / nem programozással kapcsolatos a munkám
40% (74 szavazat)
Egyéb, leírom hozzászólásban
7% (13 szavazat)
Összes szavazat: 185

( zeletrik | 2019. 02. 22., p – 08:50 )

Persze az excluded osztályokat leszámítva van nálunk meghatározva a coverage. Ez 80%+ ami szerintem teljesen korrekt. Előző munkahelyemen nem írtunk unit teszteket, elvétve volt 1-2. A mostani ahhoz képest nagy lépés volt mert az elején nem voltam otthon bennük de így belátom, hogy szukség van rájuk főleg mert egy b@szott nagy kódbázissal dolgozunk több országból, több százan így bérmikor félremehet valami amit a jól megírt tesztek egyből jeleznek.

Persze láttam már olyan tesztet is ahol csak a coverage elérésére mentek és pl a mock-ot vizsgálta, hogy az jól adja-e vissza. :D

return signResponse.getSignForUser("zeletrik").map(SignResolvable::getSign).orElse(StringUtils.EMPTY);

"Persze láttam már olyan tesztet is ahol csak a coverage elérésére mentek és pl a mock-ot vizsgálta, hogy az jól adja-e vissza"

Pontosan, ezert baromsag szerintem a 100% coverage-et betargetelni (halistennek nem is jellemzo). Tesztet irni arra kell, ani elromolhat (unit es integrationt is).

( Hevi v | 2019. 02. 22., p – 08:51 )

Elozo helyemen a kodbazis minosege miatt minimalis teszt lefedettseg volt; minden egyes valtoztatast at kellett tolni manualis feature es regression testingen.

Nyilvan, ha 3-4 fejleszto tolja ki a featureket, ennyi meloval nem bir a csapatban levo 1 szem tesztelo, szoval a deveknek is be kellett segiteni.

Soha tobbet ilyet!

Mostani helyemen szerencsere van normalis lefedettseg, szinte nulla manualis teszteles kell, sokkal elvezetesebb, es kevesbe monoton a melo...

A feature-t igen, meg sanity teszt is kell. Viszont a regressionhoz ne kelljen mar minden masnap vegigkattintgatnom ugyanazokat a testcase-ket. Nem is az ido a lenyeg, mert megvan fel ora, ora alatt. De ha maualisan akarnek szenvedni a tesztelessel akkor manual tesztelonek mentem volna, nem fejlesztonek.

Unit teszt regressziós hibák ellen jó tud lenni, illetve gyakran javítja közvetve a kódbázist is (fejlesztő kénytelen tényleg belegondolni mi a szöszt kell csináljon a cucc, illetve úgy megírni, hogy minél modulárisabb legyen, minél kevesebb függőséggel).

"Az ellen nem véd", hogy a fejlesztő(csapat) benézi a specifikációt (esetleg alapból rossz), mindig kell utólagos manuális validáció.

( haspokember | 2019. 02. 22., p – 15:42 )

Hianyzo opcio:

* nem tudom / nem erdekel, a code coverage merese a quality szempontjabol nagyjabol irrelevans, inkabb a tesztek minosege lenne az erdekes. Sot, nem hogy irrelevans, de egyenesen karos, mert a coverage szazalekos kijelzese sokaknal kivalthatja a pavlovi reflexet, igy telesz*rjak a kodot felesleges / ertelmetlen / irrelevans tesztesetekkel, csak hogy nojon a szazalekuk...

+1
Fogalmam sincs mennyi a coverage, de szvsz jo ahogy van, majdnem minden lenyeges dolgogra van teszt (amire nincs arra tobbnyire azert mert maceras lenne ra automatizalt tesztet csinalni, nem azert mert nem erdekel/nincs ra ido/...)

I hate myself, because I'm not open-source.

Egyrészt kérdés, hogy a code coverage hogy van mérve (többfajta módon is lehet ám!), másrészt a coverage minimális bővítése is iszonyatos módon növelheti a tesztelendő eseményteret (akár exponenciálisan). Ennek eleve van egy jelentős belépő költsége, ami a tesztek megírása, hiszen ezek jó eséllyel LOC-ban mérve a tesztelt, "pénzt termelő" kódnak a többszörösét jelentik. De ez még semmi ahhoz képest, hogy utána _minden_, a tesztelt funkciót érintő módosításnál frissíteni kell ám a teszteket is (azaz még egy ok, miért ne refaktoráljunk soha).

És akkor még mindig ott tartunk, hogy a branchekre számolt 100% coverage nem biztosíték semmire (már ha nem kizárólag true-false értékekkel dolgozol), illetve se nem véd a váratlan eseményekkel szemben (kimockolt servicek hibái, külső függőségek, futtatókörnyezet bugjai), se nem véd a specifikációt kitaláló, vagy a kódot + tesztet író fejlesztők hibái, lustaságe ellen.

Valójából a unit tesztelés is olyan, hogy határhaszon alapján érdemes dönteni, kell-e egyáltalán és ha igen, milyen coverageben.

> Egyrészt kérdés, hogy a code coverage hogy van mérve

Szerintem cyclomatic complexity egy jozan paraszti meroszam. Line eseten ugye ott a lehetoseg es a veszely, hogy ha a line le van fedve, akkor mondjuk a feltetel masik aga nem lesz letesztelve, viszont CC eseten ezt el lehet kerulni.

> másrészt a coverage minimális bővítése is iszonyatos módon növelheti a tesztelendő eseményteret (akár exponenciálisan)

CC-t tobbfele keppen is lehet novelni, nem muszaj csak unit tesztekre hagyatkozni. Jol elosztva unit, integration, acceptance es system integration tesztek kozt azert eleg nagy reszt le lehet fedni, meghozza ugy, hogy semmi extrat nem csinaltal, csak a valtoztatasodat nem manualisan tesztelted, hanem automatizaltad, egyfajta futtathato API dokumentaciot keszitettel kodban.

> Ennek eleve van egy jelentős belépő költsége

Ezt a mondatot fejtsd ki legysz, nem feltetlenul jott at a lenyeg. LOC mit jelent?

> De ez még semmi ahhoz képest, hogy utána _minden_, a tesztelt funkciót érintő módosításnál frissíteni kell ám a teszteket is (azaz még egy ok, miért ne refaktoráljunk soha).

Erre nyujt megoldast az enpassant kollega altal mar par eve feletett funkcionalis stilusu, mock es stub nelkuli teszteles modszere.

Abban a topicban talan nem lett elegge kihangsulyozva, de az ilyen stilusu tesztelesnek meg van az az elonye, hogy implementacio valtozas eseten nem, csak API valtozas eseten kell modositani a tesztet. Ami vegulis ertheto, hiszen a fordito amugyis jelezne, hogy valami nem koser. API viselkedes valtozas eseten is modositani kellhet a teszteket, viszont ez azt jelenti, hogy a VCS historyban jol kovetheto modon eltarolodik minden design dontes, es remelhetoleg semmilyen uzleti vagy tervezesbeli resztet nem vesz feledesbe.

> És akkor még mindig ott tartunk, hogy ... nem biztosíték semmire...
> Valójából a unit tesztelés is olyan, hogy határhaszon alapján érdemes dönteni, kell-e egyáltalán és ha igen, milyen coverageben.

Ne legy mar ilyen negativ :) Nyilvan nem oldja meg minden problemadat, de nagyon-nagyon sok manual regression test effortot levesz a valladrol egy jol osszerakott automata teszt csomag. Ehhez nyilvan nem art egy szakmajahoz jol erto automated teszter se a csapatba, hiszen ez egy kulon szakterulet (barmennyire is hajtogattak egyik elozo cegnel, hogy az automata tesztelore mar nincs szukseg; mintha a fejlesztok olyan jo teszteket tudnanak irni maguktol, vagy ugy egyaltalan elgondolkodnanak rajta :)).

Hiszen nem csak az ops devesedik el, hanem a tesztelok is (jobb helyeken). Az teljesen mindegy, hogy konkretan ki irja a tesztet, de az autoteszter el tudja jol donteni, hogy o azt milyen szinten szeretne tesztelni unittol kezdve (hiszen erti, hogy mirol van szo, szoval optimalis helyen tudja tesztelni a kodot).

Eddig ket helyen voltam olyan csapatban, ahol cross-functional teamek voltak autoteszterrel egyutt, ott szerettem dolgozni, nyugi volt. Ahol manualisan kellett tesztelni, ott nem szerettem, ott kaosz volt.

Szerk: amugy nem is baj, hogy beszelgetunk errol; ugyis akarok errol egy prezentaciot tartani, most legalabb osszeirom a nagyjat :)

>CC-t tobbfele keppen is lehet novelni, nem muszaj csak unit tesztekre hagyatkozni.

És? Attól kisebb lesz a tesztelendő eseménytér? :D
A felsorolt teszt módszereidből egyébként a unit teszt a "legolcsóbb", a többi csak tovább növeli a tesztenkénti költségeket.

>Ezt a mondatot fejtsd ki legysz, nem feltetlenul jott at a lenyeg. LOC mit jelent?

LOC = Lines Of Code

A fejlesztőnek nem a ~100 soros funkciót kell "csak" lefejlesztenie, hanem mellé írnia még ~400 sornyi tesztet. Amit ki kell találni, szintén el lehet rontani, debugolni kellhet, stb. Az meg nem feltétlenül áll, hogy cserébe nem kell kézzel tesztelnie, mert pl. frontend cuccokat úgyis érdemes végignyomkodnia, illetve utána valakinek levalidálnia.

>Erre nyujt megoldast az enpassant kollega altal mar par eve feletett funkcionalis stilusu, mock es stub nelkuli teszteles modszere.

Régebben talán olvastam, de majd átfutom megint. A második linken amit írtál, azzal rögtön adtál egy pofont a kakinak, mert üzleti alkalmazásoknál az üzleti logika rész általában annyira nem fekete mágia, ha értelmes ember írja, akkor egy viszonylag kis (akár funkcionális) magba ki van emelve és ez valóban jól tesztelhető is, ide lehet értelme a nagy lefedettségnek. Az alkalmazás többi (nagyobb) része kb. az IO kezelésről szól viszont, főleg DB tranzakciókról.

>Ne legy mar ilyen negativ :) Nyilvan nem oldja meg minden problemadat, de nagyon-nagyon sok manual regression test effortot levesz a valladrol egy jol osszerakott automata teszt csomag.

Én, negatív? :)
Fentebbi hsz-em nem olvastad? Ott leírom, miért jó dolog valóban a unit tesztelés. Én az öncélú coverage hajkurászás ellen érveltem.

Nyilván nagyobb code coverage jobb, csak tisztában érdemes azzal lenni, mire ad garanciát és mire nem (bugmentes szoftverre pl. egyáltalán nem), illetve milyen költségekkel jár. Ahol olyan a feladat, hogy megéri, ott lehet rá gyúrni, ahol nem, ott kidobott pénz.

Csak tudod nem szeretem, amikor jönnek a "dev guruk" a leegyszerűsített üzenetekkel (ami belefér pár perces prezibe, ugye ;) ) és a szakma fogyibb részét (na meg a managereket) elkápráztatja a zölden vakító '100% coverage' felirat, no meg hát a devguru is megaszondta, hogy a nagy coverage az kell, mert az a jó.

+1, code coverage egy ertekelhetetlen meroszam. Lehet businiess critical funkcio 1 sorban, es kvazi lenyegtelen kod 1000-ben.
en mindig is a funkcionalis fedesre torekedtem; az osszes usernek fontos eset legyen fedve ("happy flow"), azon tul meg az, amit mi annak itelunk, esetleg egy szivas utan hozzaadjuk. de tesztelni csak a tesztelesert magaert penzkidobas.

+1

Egyszer beestünk egy projektbe, ahol az első napon a whiteboard-on láttuk h a code coverage 90% feletti és a 100%-ra gyúrnak. Már akkor kezdett gyanús lenni dolog. A srácok úgy gondolták, hogy ha elérik a 100%-ot, akkor az alkalmazás működni fog.
Hát tévedtek. Az egyes függvények hiba nélkül lefutottak, csak egy rohadt munkafolyamatot sem lehetett végigvinni crash nélkül.

Elődeink lelépte után majd' 3 hónapnyi megfeszített refactorral sikerült az alkalmazás production-ready-re reszelni. A code coverage lényegesen kisebb lett a végére (nem mértük...), cserébe lettek olyan tesztjeink, amik nem csak a string.isNullOrEmpty működését tesztelték...

( sedder | 2019. 02. 22., p – 19:53 )

> Egyeb
* line coverage 80-90% Es lehetne jobb is.
* branch coverage 70-80% Es az is lehetne jobb
97% felett lenne idealis mindkettobol.
A man can dream...
---
Lambda calculus puts the fun into functional programming

FYI nem csak "olvastam par cikket, ami utan kritikai gondolkodas es jelentosebb tapasztalat nelkul felultem a hype vonatra"

Eloszor kiprobaltam, hogy mennyire mukodne. Es igen, kb egy ev gyakorlas utan bejott. Mar nagyjabol kepes vagyok komplexebb rendszereket is TDD-ben megirni. Elismerem, hogy nem csodaszer, de borzasztoan megkonnyiti a munkat, hogy nem kell azon aggodnom, milyen regressziot sikerult bevinnem a rendszerbe, es nem kell evente ujrairnom, mert nem tudom kiboviteni egy uj funkcioval.

Azert mondom a 97%-ot, mert ez az a mennyiseg, ami a Java-ban kieroszakolt (mockolas nelkul elerhetetlen) exception-oket elengedi.
---
Lambda calculus puts the fun into functional programming

( flimo | 2019. 02. 23., szo – 13:22 )

Egyéb: a kód üzletileg lényeges része legyen lefedve integrációs tesztekkel, amikre mutációs tesztek is futnak, hogy kibukjon, ha nincs lényeges rész lefedve. Ezen kívül project méretétől, bonyolultságától függően feature, smoke és acceptance tesztek, lehetőleg külön tesztelő(k) által írva, mert akkor a user story félreértése is hamarabb kibukik. Illetve sok microservicenél szerintem hatékonyabb egy dedikált tesztszervízt fenntartani, ahol külön lehet tesztelni verzióváltásnál a third party komponensek elvárt működését.

Unit teszt meg egy félreértett jószág, sokkal inkább van szerepe a fejlesztésben (TDD, refaktorálás) mint a bugok megfogásában, bár egyes kritikus modulokra lehet minőségbiztosításban is értelme. De a nagy része inkább csak lassítja a suite-ot, főleg ha mutation tesztinget is használnak. De sajnos valahol valaki lerajzolta a tesztpiramist, és azóta sokan szentírásnak tartják, mert máshol is láttak már ilyen piramisokat, és akkor biztos itt is igaz, pedig a szoftverfejlesztési módszerek nem egy egzakt tudomány.

( _Franko_ v | 2019. 02. 23., szo – 22:42 )

Nekem soha nem tetszettek a szintetikus metrikák és tekintélyelv alapú szamárvezetők mentén végzett kódminőség ellenőrzések. Erősen lassítják a termelékenységet és közben alig van hozzáadott értékük, viszont elég sok látszatmunkát ad azoknak, akik alapvetően nem szeretnek dolgozni, csak kritizálni, a csapat értékes ideje pedig arra megy el, hogy késhegyre menő vitákat folytatnak hetekig olyan marginális faszságokról, hogy kell-e szóköz a + jel elé vagy sem.

Ha megnézed piacvezető cégek termékeinek a forrását, akkor azt látod, hogy lófasz van ott, nem kódminőség. Ha pedig megnézed a kódminőségre nagy hangsúlyt fektető cégek eredményét, akkor azt látod, hogy lófasz van ott, nem bevétel.

A non-plus ultra pedig az, amikor a cég terméke mindenféle kódminőség metrikának végletekig megfelel, amit csak mérni lehet, csak az architektúra és az API egy rakás fos, mert azt nehéz mérni, pedig sokkal fontosabb egy rugalmas architektúra és használható API, mint a tisztaszobában fejlesztett kód.

--
https://iotguru.live

( enpassant v | 2019. 02. 25., h – 07:46 )

What went wrong with the IT-industry? - James Coplien

A unit tesztelésnek van előnye, hátránya. Előnye, hogy segítheti a tervezést, megkönnyíti a refaktorálást, hibajavítást.
Hátránya, hogy sok időt elvesz a fejlesztése, növeli a kódbázist, hamis biztonságérzetet ad.

A unit tesztekkel ellenőrizni tudjuk valamelyest, hogy mennyire jó a kódunk; ha rossz adatokat kap a unitunk, akkor azt megfelelően kezeli-e.
Van ennél sokkal jobb módszer is, ha eleve nem is lehet rossz adatokat átadni a unitunknak, illetve az sem tud hibás adatot visszaadni.
Erről írtam itt, megköpködni, meg itt lehet.

( GerzSonka | 2019. 02. 25., h – 08:36 )

0% - Csak integration tesztjeink vannak, nagyon kene az a unit teszt.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

( svo | 2019. 02. 25., h – 09:34 )

99-100%? És az hogy? 80% fölé juttatni is alig tudjuk némelyik rendszert.