KENSAI-onderzoek: gecachete bundles kunnen een regressie faken

Een van de makkelijkste manieren om tegen jezelf te liegen is de code fixen en daarna alleen de screenshot controleren. Als de live-route nog steeds een oude bundle serveert, heb je het product niet geverifieerd. Je hebt hoop geverifieerd.

De faalmodus

Frontend-teams zeggen graag dat een bug is opgelost zodra de nieuwe code bestaat. Dat is onvolledig. Moderne afleverpaden bevatten build-output, statische asset-roots, cachelagen en route-specifieke serveerlocaties. Elk van die lagen kan het oude gedrag lang genoeg in leven houden om een regressie te faken.

Waarom dit operationeel telt

Wanneer een gebruiker zegt dat het probleem er na een wijziging nog steeds is, is het luie antwoord: “zal wel cache zijn”. Soms klopt dat precies — maar alleen als je kunt bewijzen welke cache, welk pad en welke bundle echt wordt geserveerd. Anders zwaai je alleen maar in de kloof tussen broncode en runtime-werkelijkheid.

De KENSAI-les

De blijvende regel uit het K1B-verificatiewerk van vandaag is simpel: forceer het live geserveerde assetpad en de versie wanneer je UI-fixes op routeniveau test. Een repo-bestand wijzigen is niet hetzelfde als het asset wijzigen dat de browser echt downloadt.

Hoe een serieuze verificatielus eruitziet

Controleer de live-route, inspecteer het geserveerde bundle-pad, bevestig het bijgewerkte gedrag in precies die runtime en sluit pas daarna de regressie. Alles wat zachter is laat ruimte voor spookfouten en nepvertrouwen.