Com mesurar la cobertura de codi, entendre les mètriques i millorar els tests

Mesurar la cobertura de codi és una d'aquelles pràctiques que tots els equips de desenvolupament comenten, però pocs aprofiten al màxim. No es tracta només d'arribar a un número bonic en un informe; es tracta d'entendre quines parts de la teva aplicació estan realment validades per proves automatitzades i quines corren el risc d'amagar defectes. A Q2BSTUDIO, com a empresa especialitzada en desenvolupament d'aplicacions a mida, sabem que una estratègia sòlida de cobertura impacta directament en la confiança del desplegament, la qualitat del programari i, en última instància, en la satisfacció del client.

La cobertura de codi, en la seva definició més bàsica, mesura el percentatge de línies, branques o condicions del codi font que s'executen durant l'execució d'una suite de proves. Per exemple, si el teu projecte té 10.000 línies executables i les teves proves recorren 8.000, tens un 80% de cobertura de línia. Però aquest número, per si sol, no explica tota la història. Una prova que executa cada línia però no verifica cap resultat pot donar una falsa sensació de seguretat. Per això, en aquest article explorarem les mètriques clau —cobertura de línia, branca, condició i ruta—, com mesurar-les amb eines modernes i com millorar la qualitat dels teus tests sense caure en el parany de perseguir percentatges buits.

La majoria d'equips comencen mesurant la cobertura de línia (line coverage), que indica si cada línia del codi s'ha executat almenys una vegada. És la mètrica més senzilla d'obtenir amb eines com JaCoCo, Istanbul/nyc, Coverage.py o Jest, i sol ser la que apareix als panells de control. Tanmateix, una alta cobertura de línia no garanteix que totes les decisions lògiques estiguin cobertes. Aquí entra la cobertura de branca (branch coverage), que verifica si cada bifurcació d'una estructura condicional —per exemple, els camins vertader i fals d'un if— ha estat executada. Un projecte pot tenir un 90% de cobertura de línia però només un 55% de cobertura de branca, deixant la lògica complexa sense provar.

La cobertura de condició (condition coverage) va un pas més enllà: per a expressions booleanes compostes com if (a && b || c), exigeix que cada subexpressió (a, b, c) s'avaluï tant a vertader com a fals en diferents casos de prova. Això és especialment rellevant en mòduls crítics com autenticació, processament de pagaments o regles de negoci complexes. Finalment, la cobertura de ruta (path coverage) persegueix provar totes les combinacions possibles de camins d'execució, però en aplicacions reals això és pràcticament impossible a causa de l'explosió combinatòria de bucles i niuaments. Només es recomana per a algorismes crítics o sistemes certificats sota estàndards com DO-178C o ISO 26262.

El procés per obtenir mètriques fiables consta de quatre passos: instrumentar el codi (inserir ganxos que registrin l'execució), executar les proves automatitzades (unitàries, d'integració o extrem a extrem), recollir les dades de cobertura i generar informes en formats com HTML, XML o LCOV. A Q2BSTUDIO integrem aquest flux en pipelines de CI/CD personalitzats que s'adapten a tecnologies cloud com AWS i Azure, permetent als nostres clients detectar regressions de cobertura en cada pull request. A més, combinem la cobertura amb anàlisi estàtic per assenyalar zones d'alta complexitat ciclomàtica que necessiten proves addicionals.

Eines com Jest, pytest-cov o JaCoCo generen informes que es poden consumir directament des de l'IDE o integrar-se en la plataforma de qualitat. La clau està a no quedar-se amb la mètrica global: cal desglossar per mòduls, prioritzar els d'alt risc (com passarel·les de pagament, autenticació o lògica d'IA) i establir llindars diferenciats. Per exemple, un mòdul financer hauria d'aspirar al 85-90% de cobertura de branca, mentre que el codi generat o els getters/setters trivials es poden excloure sense problemes.

No existeix un número màgic, però l'experiència de la indústria —avalada per estudis com el de Google, que considera el 60% acceptable i el 90% exemplar— suggereix que el 80% és un objectiu raonable per a la lògica de negoci principal. Tanmateix, arribar al 100% de cobertura de línia no implica que el programari estigui lliure d'errors; només significa que totes les línies es van executar, no que es van validar comportaments. De fet, investigacions de Microsoft mostren una correlació insignificant entre la cobertura alta i la reducció de defectes a nivell de fitxer. Per això a Q2BSTUDIO recomanem utilitzar la cobertura com un indicador de tendència (setmana rere setmana) més que com una meta estàtica, i complementar-la amb revisions de codi, proves de ciberseguretat i monitoratge en producció.

1. Comença pels informes de cobertura: identifica les zones amb menor cobertura i major risc, com serveis de domini, processament de dades o integracions amb APIs externes. No intentis pujar el percentatge global de manera uniforme; prioritza.

2. Escriu proves unitàries enfocades: ataca primer les funcions pures i els components petits, que són més fàcils d'aïllar i donen un retorn ràpid en cobertura de línia i branca.

3. Cobreix branques i condicions ocultes: no et limitis a les línies. Dissenya casos de prova que exercitin camins d'error, reintents, timeouts i casos límit en lògica condicional. Això elevarà la cobertura de branca i condició, on solen amagar-se els bugs.

4. Refactoritza codi complex: les funcions amb alta complexitat ciclomàtica són difícils de provar. Dividir-les en unitats més petites millora tant la cobertura com la mantenibilitat.

5. Aïlla dependències difícils: utilitza injecció de dependències, mocks i dobles de prova per a codi legacy, integracions de tercers o mòduls amb molta E/S. Així podràs escriure proves sense necessitat d'entorns complets.

6. Integra la cobertura al teu CI/CD: estableix comprovacions automàtiques que rebutgin pull requests si la cobertura disminueix significativament. Això assegura que les millores es mantinguin al llarg del temps.

7. Defineix objectius per mòdul i no globals: no tot el codi mereix el mateix nivell de cobertura. Prioritza els mòduls crítics i deixa fora el codi generat o les configuracions.

La cobertura de codi no treballa sola. Quan l'aparelles amb anàlisi estàtic (que detecta codi mort, vulnerabilitats potencials o alta complexitat) obtens una visió molt més completa de la salut del programari. Per exemple, en projectes que incorporen intel·ligència artificial i agents IA, la cobertura ajuda a verificar que els models i les regles de decisió s'exerciten correctament, mentre que l'anàlisi estàtic assenyala possibles biaixos o ineficiències. A Q2BSTUDIO apliquem aquest enfocament multidisciplinari també en àmbits com la ciberseguretat, on les proves de penetració i la cobertura de codi es complementen per reduir la superfície d'atac, o en projectes de BI i Power BI, on la cobertura de les transformacions de dades garanteix que els informes reflecteixin la realitat del negoci.

A més, quan treballem al núvol (AWS, Azure), la cobertura és part fonamental de les estratègies de DevOps: cada desplegament automatitzat porta associat un llindar de cobertura que, si no es compleix, bloqueja l'alliberament. Això evita que codi no provat arribi a producció i redueix dràsticament els incidents nocturns.

El principal error és confondre cobertura amb qualitat de prova. Una suite amb 100% de cobertura de línia però sense assertions significatives no aporta valor. Un altre error freqüent és convertir el percentatge global en una mètrica de rendiment de l'equip, cosa que incentiva escriure proves superficials només per pujar el número. També se sol intentar cobrir codi que no necessita ser provat, com getters/setters, codi generat o configuració de frameworks. És millor excloure aquestes parts dels llindars i concentrar l'esforç on realment importa.

Finalment, recorda que la cobertura no mesura si es compleixen tots els requisits de negoci, ni els fluxos d'usuari, ni aspectes no funcionals com rendiment o seguretat. És una eina més dins de l'ecosistema de qualitat. A Q2BSTUDIO ajudem els nostres clients a dissenyar estratègies de testing integrals que combinen cobertura, anàlisi estàtic, proves d'integració, ciberseguretat i monitoratge continu. Si vols portar la qualitat del teu programari al següent nivell, podem acompanyar-te en el procés, ja sigui amb aplicacions a mida, migracions al núvol o implantació d'agents intel·ligents.