Tanquem el capítol de testing amb una idea més avançada: el contract testing (proves de contracte) entre mòduls. Quan construeixes infraestructura component mòduls que es connecten entre si (recorda el Capítol 18), necessites assegurar-te que aquestes connexions segueixen encaixant encara que els mòduls evolucionin. El contract testing protegeix aquests «punts d’unió». És un concepte més subtil, però entendre’l et farà dissenyar millors mòduls.

Al Capítol 18 vam veure que els mòduls tenen un contracte: unes entrades (variables) i unes sortides (outputs). I vam veure que es composen connectant la sortida d’un mòdul amb l’entrada d’un altre (subcapítol 18.2):

Aquesta connexió és un contracte entre els dos mòduls: el mòdul de servidors confia que el mòdul de xarxa li donarà un id_subxarxa vàlid. Mentre aquest contracte es respecti, tot encaixa.

Aquí hi ha el risc. Imagina que algú modifica el mòdul de xarxa i, sense adonar-se de l’impacte, canvia el nom o el format de la seva sortida id_subxarxa (per exemple, el reanomena a subnet_id, o canvia el que retorna). El mòdul de xarxa, per si sol, segueix «funcionant»... però el mòdul de servidors que depenia d’aquesta sortida es trenca, perquè ja no troba el que esperava.

Aquest tipus d’error és traïdor: el mòdul modificat sembla correcte en aïllament, però ha trencat altres mòduls que depenien d’ell. I en una organització gran, pot haver-hi molts mòduls depenent d’un de sol (recorda els mòduls compartits del subcapítol 18.4).

El contract testing (prova de contracte) verifica que la interfície entre dos mòduls —el «contracte» d’entrades i sortides— es manté estable i compatible. En lloc de provar tota la infraestructura, se centra en els punts de connexió: comprova que un mòdul segueix oferint les sortides que altres esperen, amb el nom i el format correctes.

Analogia: un contracte entre mòduls és com l’endoll i la clavilla. L’endoll (la sortida d’un mòdul) té una forma estàndard, i la clavilla (l’entrada d’un altre) encaixa en ella. El contract testing comprova que ningú ha canviat la forma de l’endoll: si algú el modifica, els aparells que depenien d’ell ja no encaixarien. Verifiques l’«endoll», no tot l’aparell.

El contract testing entre mòduls no és una eina única amb un botó màgic; és més aviat un enfocament que combina diverses pràctiques que ja coneixes:

Escrius proves (per exemple, amb Terratest del subcapítol 21.3) que verifiquen específicament que els outputs d’un mòdul existeixen i tenen el format esperat. No proves tota la infraestructura, només el «contracte».

Aquí brilla el versionat del subcapítol 18.4. Si canvies la interfície d’un mòdul (les seves entrades o sortides) de manera incompatible, això és un canvi major (puja la versió MAJOR, ex. de v1.x a v2.0). Així, els mòduls que depenien d’ell no s’actualitzen automàticament i segueixen usant la versió compatible fins que s’hi adaptin conscientment.

Al CI (subcapítol 21.1), quan algú canvia un mòdul compartit, es poden executar tests que combinen aquest mòdul amb els que l’usen, per confirmar que segueixen encaixant abans de fusionar el canvi.

En un projecte petit amb pocs mòduls, els contractes es trenquen poc i és fàcil detectar-ho. Però en una organització gran (que veurem a la Part VII, amb plataformes internes i mòduls compartits per molts equips), un sol mòdul base pot ser usat per desenes de projectes. Trencar el seu contracte sense avisar causaria errors en cascada per tota l’empresa.

Exemple del món real: l’equip de plataforma manté un mòdul xarxa-corporativa que usen 30 equips. Una desenvolupadora vol millorar-lo i, de passada, reanomena una sortida perquè sigui «més clara». Sense contract testing, aquest canvi trencaria els 30 projectes. Amb contract testing i versionat estricte, el CI detecta que està canviant la interfície de manera incompatible i l’obliga a publicar-ho com a versió major (v2.0). Els 30 equips segueixen a v1.x tranquils, i migren a v2.0 quan puguin, adaptant el seu codi. El canvi millora el mòdul sense trencar ningú.

El missatge clau d’aquest subcapítol, més enllà de les eines, és una mentalitat: quan dissenyes mòduls reutilitzables, les seves interfícies (entrades i sortides) són un contracte sagrat. Altres hi confien. Canviar-les a la lleugera trenca aquells que depenen de tu. El contract testing i el versionat són les eines que protegeixen aquests contractes, permetent que els mòduls evolucionin sense causar caos.

• Els mòduls es connecten per les seves interfícies (sortides d’un → entrades d’un altre); aquesta connexió és un contracte en què uns mòduls confien.
• Si algú canvia la interfície d’un mòdul (reanomena o altera una sortida), pot trencar altres mòduls que depenien d’ella, encara que el mòdul modificat «funcioni» en aïllament. És un error traïdor, sobretot a gran escala.
• El contract testing verifica que la interfície entre mòduls es manté estable i compatible, centrant-se en els punts de connexió (com comprovar que «l’endoll no ha canviat de forma»).
• S’aconsegueix combinant: tests centrats en les interfícies (Terratest), versionat estricte (un canvi incompatible és versió MAJOR, subcap. 18.4) i tests d’integració entre mòduls en CI.
• Importa especialment a gran escala, on un mòdul base l’usen molts equips. La mentalitat clau: les interfícies dels teus mòduls són un contracte que has de cuidar.

Has acabat el Capítol 21! Ja saps assegurar la qualitat i seguretat de la teva infraestructura a tots els nivells. Al Capítol 22 unirem tot això en un flux automàtic complet: Terraform en CI/CD, des del lint fins al desplegament automatitzat.