Aanleiding
De stap die beslist of er een verversing nodig is, is uitgegroeid tot een lang blok shell in het workflowbestand. Een deel daarvan doet niets anders dan vaststellen of de opgehaalde gegevens bruikbaar zijn: klopt het formaat, is er werkelijk een bron geraadpleegd, is alles wat gevraagd is ook beantwoord.
Effect
Dat deel is alleen te toetsen via de zware route: het blok wordt uit het workflowbestand geknipt, er zijn nagebootste commandos nodig, en elk testgeval schrijft naar gedeelde bestanden. Daardoor is een testgeval schrijven duurder dan het zou moeten zijn, en blijven controles langer ongetoetst dan wenselijk.
Wenselijk gedrag
De vraag "zijn deze gegevens bruikbaar" is een losstaand stuk logica en hoort net zo getoetst te kunnen worden als de vraag "valt er iets te halen": gegevens erin, uitkomst eruit, zonder omgeving eromheen.
Acceptatiecriteria
Technische details
.github/workflows/check-upstream.yml, job apt-security-refresh, functie haal_policy: circa tachtig regels valideren de uitvoer van apt-cache policy (indexfouten, dekking van geïnstalleerde pakketten, dekking van pakketten met een bevinding, aanwezigheid van Candidate-regels, herkomst uit een archief, aanwezigheid van een security-index).
Voorgestelde vorm: .github/scripts/apt-policy-bruikbaar.sh <policy-uitvoer> <geinstalleerd-samen.json> <os-samen.json>, exitcode 0 = bruikbaar, 1 = geen meting — dezelfde vorm als apt-upgrade-beschikbaar.sh. De fixtures worden dan gewone stringvergelijkingen zoals in test-apt-upgrade-beschikbaar.sh, zonder yq, zonder containerstub en zonder gedeelde paden.
Aandachtspunt: geen enkel script onder .github/scripts/ schrijft nu ::warning::; de dekkingswaarschuwing zou de eerste zijn. Dat is een bewuste keuze om te maken.
Bijkomend, in hetzelfde blok: de drie plekken die een grep-exitcode wegen kunnen één helper worden, en de vijf plekken die een telling op cijfervorm controleren ook. Zie ook #143 (gedeelde paden) en #146 (controles zonder testgeval), die hier deels door opgelost worden.
Aanleiding
De stap die beslist of er een verversing nodig is, is uitgegroeid tot een lang blok shell in het workflowbestand. Een deel daarvan doet niets anders dan vaststellen of de opgehaalde gegevens bruikbaar zijn: klopt het formaat, is er werkelijk een bron geraadpleegd, is alles wat gevraagd is ook beantwoord.
Effect
Dat deel is alleen te toetsen via de zware route: het blok wordt uit het workflowbestand geknipt, er zijn nagebootste commandos nodig, en elk testgeval schrijft naar gedeelde bestanden. Daardoor is een testgeval schrijven duurder dan het zou moeten zijn, en blijven controles langer ongetoetst dan wenselijk.
Wenselijk gedrag
De vraag "zijn deze gegevens bruikbaar" is een losstaand stuk logica en hoort net zo getoetst te kunnen worden als de vraag "valt er iets te halen": gegevens erin, uitkomst eruit, zonder omgeving eromheen.
Acceptatiecriteria
Technische details
.github/workflows/check-upstream.yml, jobapt-security-refresh, functiehaal_policy: circa tachtig regels valideren de uitvoer vanapt-cache policy(indexfouten, dekking van geïnstalleerde pakketten, dekking van pakketten met een bevinding, aanwezigheid van Candidate-regels, herkomst uit een archief, aanwezigheid van een security-index).Voorgestelde vorm:
.github/scripts/apt-policy-bruikbaar.sh <policy-uitvoer> <geinstalleerd-samen.json> <os-samen.json>, exitcode 0 = bruikbaar, 1 = geen meting — dezelfde vorm alsapt-upgrade-beschikbaar.sh. De fixtures worden dan gewone stringvergelijkingen zoals intest-apt-upgrade-beschikbaar.sh, zonderyq, zonder containerstub en zonder gedeelde paden.Aandachtspunt: geen enkel script onder
.github/scripts/schrijft nu::warning::; de dekkingswaarschuwing zou de eerste zijn. Dat is een bewuste keuze om te maken.Bijkomend, in hetzelfde blok: de drie plekken die een
grep-exitcode wegen kunnen één helper worden, en de vijf plekken die een telling op cijfervorm controleren ook. Zie ook #143 (gedeelde paden) en #146 (controles zonder testgeval), die hier deels door opgelost worden.