Sådan tester du din zip-fil, før du udgiver den

Problemet: du tester noget andet end det, brugerne får

I vores eget projekt udgav vi to versioner af en browser-udvidelse, hvor zip-filen manglede de nyeste fejlrettelser — mens alle tests var grønne. Årsagen: testene læste kernekildekoden, zippen indeholdt en glemt manuel kopi. Hele historien står i casen om release integrity.

Mønsteret er udbredt, fordi det føles sikkert: buildet virker, tests er grønne, så zips bygges sidst og hurtigt. Netop dét sidste trin er det eneste, brugerne egentlig rører ved.

Tjeklisten: syv tjek af din zip

Pakket fra ren arbejdskopi? Byg aldrig fra en mappe med ucommitte ændringer eller uvedhæftede filer. Tjek status først.
Indeholder den præcis de forventede filer? Ingen ekstra filer (logs, cache, .DS_Store), ingen manglende.
Matcher indholdet kilden? Kør en parity-test: sammenlign hver fil i zippen med dens kilde byte-for-byte.
Er versionsnummeret korrekt alle steder? Manifest, package.json, om-fane — samme nummer, og det er højere end den forrige udgivelse.
Kan artefaktet starte? Udpak i en ren mappe og lad den reelle runtime (browser, Node, Python) indlæse dérfra — ikke fra din kilde-mappe.
Er filnavnet unikt? Navngiv med versionsnummer (produkt-v1.3.7.zip). En fil uden version i navnet bliver før eller siden forvekslet med en gammel.
Virket det, som brugeren oplever det? Efter udgivelse: download selve den offentlige fil og gentag tjek 3–5 mod den. Deploy kan fejle stille.

Tre kommandoer du kan kopiere

1) Se præcis hvad zippen indeholder (fanger skrald og manglende filer):

unzip -l produkt.zip | sort -k4

2) Parity-tjek: matcher filen i zippen kilden? Udpak i en temp-mappe og sammenlign:

rm -rf /tmp/ziptest && mkdir /tmp/ziptest
unzip -q produkt.zip -d /tmp/ziptest
diff /tmp/ziptest/kernen.js src/kernen.js \
  && echo "PARITY OK" || echo "PARITY FEJLEDE"

3) Versions-sweep: find gammelt versionsnummer i artefaktet:

grep -rn "1\.3\.6" /tmp/ziptest \
  && echo "GAMMEL VERSION I PAKKEN" || echo "version OK"

Læg de tre trin i et script, og kald det fra dit bygge-script som det absolut sidste trin. Fejler ét tjek, fejler buildet — og der udgives ingenting.

Den ene regel, der dækker det hele

Test det, brugerne modtager. Alt andet — grønne tests, pæne builds, gode intentionslister — er om vejen, ikke målet. Én parity-test mod selve artefaktet havde fanget vores fejl, før nogen bruger så den.

Det samme princip gælder uden for software: det dokumentet kunden downloader, den fil der lægges op til markedspladsen, det billede siden viser — åbn det, se på det, verificér det efter udgivelsen. Det tager minutter og sparer tillid.

Prøv Clean Copy gratis → Casen bag tjeklisten

Ofte stillede spørgsmål

Hvorfor skal jeg teste zip-filen, når mine tests allerede er grønne?

Fordi dine tests kører mod kildekoden — ikke mod artefaktet. Zip-filen er bygget af et separat trin, som kan pakke ældre filer, glemme nye eller medtage skrald. En test kan kun garantere det, den faktisk indlæser.

Hvad er en parity-test?

En test der sammenligner filen i zippen med dens kilde byte-for-byte. Hvis de adskiller sig, fejler buildet. Det fanger den klassiske fejl hvor samme kode vedligeholdes to steder, og kopien bliver glemt ved en udgivelse.

Kan jeg automatisere tjeklisten?

Ja — det er hele pointen. Læg kommandoerne i et script, og lad det køre som det sidste trin i dit bygge-script, før zips navngives og uploades. Hvis et tjek fejler, fejler buildet, og der kommer ingen udgivelse.

Hvad gør jeg, hvis jeg finder en gammel fil i zippen?

Stop udgivelsen. Find ud af hvorfor filen afveg (manuel kopi? glemt build-trin?), ret årsagen — ikke kun symptomet — bump versionsnummeret, byg igen og kør hele tjeklisten én gang til på det nye artefakt.

Prøv Clean Copy gratis →