Att exekvera automatiska tester vid byggning är inget ovanligt (typiskt enhets- och integrationtester). Det hjälper oss att upptäcka regression, och genom att exekvera testerna vid byggning så blir det också en del av vår CI-pipeline. Medan det verkar vara de facto standard att automatiskt försöka upptäcka regression vid CI (och avbryta integrationen om det inträffar), så finns inte samma tradition av att försöka upprätthålla kodtäcknigen i syfte att se till att det finns tester som faktiskt verifierar om regression inträffar eller inte.

Jag brukar förespråka att 100% av raderna i applikationen måste exekveras av testerna för att bygget ska godkännas (dvs 100%" line converage"). Anledningen är att kodtäckning är det enda verktyg som jag känner till för att automatiskt avgöra om risken för regression har ökat. Det blir viktigt eftersom automatiskt tvingande regelverk inte går att slingra sig ur och är mer objektiva än utvecklare. Det är inte den perfekta lösningen, men det är inte heller en dålig lösning.

Jag blir tvingad att skriva test för kod som inte behöver testas! Finns det kod som inte behöver testas så ska den så klart exkluderas från testtäckningen. Det kan t ex röra sig om genererad kod.

Jag kan skriva tester som inte testar någonting, bara för att uppfylla kodtäckningen!

Ja, på samma sätt som du kan skriva affärslogik som inte gör någon faktisk nytta. Det är en av anledningarna till att vi har kodgranskning, och testkod är inte annorlunda från annan kod - den bör granskas.

Enhetstestning är dåligt!

Kodtäckning är inte bara applicerbart för enhetstestning, utan du kan t ex ha en testsvit med integrationstester av mer BDD-karaktär. Det som spelar roll i slutändan är om kodraderna har exekverats av testsviten, oavsett av hur den är sammansatt.

Det är ett jävla besvär att jag inte kan få ut saker i testmiljön innan jag har skrivit tester!

Om så är fallet så kan kanske det beror på andra problem, t ex: 1) arkitektur/design/annat gör att det är omständigt att skriva tester, eller 2) arkitektur/design/annat gör att det är för krångligt att testa lokalt. Steget från en test miljö- till produktionsmiljö är inte lång, så vad är det som garanterar att du skriver dom uteblivna testfallen innan produktionssättning?

100% radtäckning är överdrivet!

Jag tycker inte det är överdrivet att varje kodrad ska ha exekverats åtminstone en gång av testsviten. Det är fortfarande inte vattentätt på något sätt, men att upptäcka regression är i alla fall möjligt om koden exekveras.