Forhåndsproduksjonsskjema for testing av regnskaps-API

En 201 Created-respons fra et regnskaps-API forteller deg nesten ingenting. Den bekrefter at serveren svarte. Den bekrefter ikke at det eksisterer nøyaktig én faktura, at debet er lik kredit, at dokumentnummeret ble tildelt én gang, eller at et nytt forsøk etter en tapt tilkobling ikke vil bokføre en kopi til. De fleste dupliseringer i produksjonsregnskap oppstår i akkurat det rommet: en endring som ble utført på serveren mens klienten satt igjen med et ukjent utfall og i det stille prøvde på nytt med en ny nøkkel.

Denne planen er for team som evaluerer et regnskaps-API før de kobler det til ekte regnskap. Den retter søkelyset mot feilatferd, ikke solskinnshistorier. Hvert av områdene nedenfor beskriver hva du skal teste, hva du skal sjekke, og hva som skal til for å bestå. Implementeringskonteksten her er Nordlet, hvis API bruker begrensede bærernøkler (scoped bearer keys), desimalstreng-beløp, idempotensnøkler og signerte webhooks. For nøyaktig endepunktsyntaks og responskontrakter bør du lese sidene API-konvensjoner og Kom i gang i stedet for å stole på antakelser.

Hva «å bestå» faktisk betyr

En test beviser bare at en regnskapsintegrasjon er trygg når den verifiserer semantikk, ikke statuskoder. For hvert scenario bør testsuiten bekrefte:

• Forretningsmessig sideeffekt: nøyaktig én kunde, faktura, journalføring, nummertildeling eller betalingsovergang eksisterer.
• Regnskapsintegritet: debet er lik kredit, og monetær presisjon overlever serialisering.
• Avspillingsatferd: et nytt forsøk returnerer det opprinnelige resultatet i stedet for en ny post.
• Varighet: revisjonsposter og webhook-hendelser eksisterer når operasjonen er gjennomført.
• Feil uten sideeffekter: avviste forespørsler forbruker ingen dokumentnumre og skriver ingen delvise hovedboklinjer.
• Gjenoppretting: en midlertidig feil kan kjøres på nytt uten duplisering eller permanent tap.

Googles API-veiledning trekker opp grensen tydelig: bare operasjoner der gjentatt kjøring etterlater den samme endelige tilstanden er trygge å kjøre på nytt, og et API bør identifisere hvilke operasjoner som er idempotente i stedet for å prøve på nytt ved enhver feil blindt.

Sett opp et engangs- og observerbart miljø

Bruk et testfirma (sandbox-firma), ikke produksjonsregnskapet. Et Nordlet-testfirma bruker de samme modulene og API-virkemåten som et ekte selskap, og er merket som testdata, noe som gjør det trygt for duplikat- og feiltester i stort volum. Flagget kan ikke endres etter opprettelse, slik at ekte regnskap ikke ved et uhell kan omklassifiseres som testdata senere. Merk at bruk av testmiljøet måles og faktureres på akkurat samme måte som bruk i et ekte selskap, så tilpass volumtestene dine til prisnivået du befinner deg på.

Før du skriver en eneste test, bør du klargjøre:

• Et dedikert testfirma med isSandbox: true.
• En test-API-nøkkel som kun har tilgang til modulene som testes.
• Et webhook-endepunkt eller en lokal tunnel som bevarer den rå forespørselsteksten (raw request body).
• Forhåndsutfylte kunder, leverandører og en kjent kontoplan.
• Minst to regnskapsperioder: én åpen og én låst.
• En testklokke eller datovelger hvis implementeringen støtter det.
• Et lokalt lagringsområde som registrerer hvert enkelt forespørselsforsøk, idempotensnøkkel, responshash, webhook-levering og avstemmingsresultat.

Ikke kjør duplikat-tester mot delt testdata. En bortvkommen kunde eller faktura fra en tidligere kjøring gjør senere sjekker tvetydige.

Testoppsettet for hver endring bør fange opp metode, endepunkt, fullstendig innhold, idempotensnøkkel, nøkkeltilgang, en klientkorrelasjons-ID, start- og sluttidspunkter, responsstatus, hoder, innhold, forespørsels-ID, og hvorvidt tilkoblingen brøt sammen før responsen kom. Bruk faste desimalstrenger som "75.0000" for beløp. Nordlet representerer pengeverdier som desimalstrenger med opptil fire desimaler, og eksempelfakturaen bruker det formatet.

Den andre halvdelen av oppsettet er feilinjeksjon. Testmiljøet ditt bør kunne forsinke en respons, avbryte en TCP-tilkobling etter at serveren har mottatt forespørselen, returnere syntetiske 429/500/502/503/504-responser, returnere en annen feil enn 2xx fra webhook-mottakeren, levere den samme webhooken to ganger, endre rekkefølgen på hendelser, korrumpere én byte i et webhook-innhold, endre innholdet knyttet til en idempotensnøkkel mens selve nøkkelen beholdes, kjøre to identiske forespørsler samtidig, og låse en periode mellom oppsett og bokføring. Disse scenarioene er verdt mer enn hundre solskinnseksempler.

Lås kontrakten før du skriver omkjøringslogikk

Generer eller hent OpenAPI-skjemaet og sammenlign det med klienten din. Nordlet publiserer sin OpenAPI-spesifikasjon i API-referansen og genererer sine typede SDK-er fra den samme spesifikasjonen, slik at skjemabaserte tester slår hjemmelagde gjetninger.

Verifiser obligatoriske felt og typer, desimalstrengfelt, dato- og tidsstempelformater, tillatte handlinger og tilganger, feilmeldingens struktur, skjemaer for webhook-hendelser, hvilke endringer som godtar en idempotensnøkkel, og hvilke responsfelt som identifiserer det opprettede objektet.

Kriterier for å bestå. Klienten avviser ugyldige innhold lokalt der skjemaet tillater det. Serverens responser samsvarer med det dokumenterte skjemaet. Ugyldige desimaler, dårlige datoer og manglende obligatoriske felt gir strukturerte valideringsfeil. Det forsøkes ikke å kjøre forespørselen på nytt ved en deterministisk valideringsfeil.

Feiltypene du må fange opp. En klient parser "121.0000" til et flyttall (binary float) og serialiserer et litt annerledes beløp senere. Heltall går igjennom; MVA-linjer og brøkall feiler. Test penger som strenger fra ende til annen.

Autorisasjon og leietakerisolering (tenant isolation)

Bruk separate nøkler for lesing og skriving. Test deretter hele matrisen: manglende nøkkel, ugyldig nøkkel, gyldig nøkkel med utilstrekkelig modultilgang, gyldig nøkkel med riktig tilgang, en nøkkel som tilhører et annet selskap, og et forsøk på å lese et objekt fra et annet selskap.

Kontroller at:

• Manglende eller ugyldig påloggingsinformasjon returnerer 401.
• En gyldig nøkkel uten nødvendig tillatelse returnerer 403.
• Ingen regnskapsmessig sideeffekt opprettes ved noen av feilene.
• En vellykket forespørsel kan ikke lese eller endre et annet selskaps poster.
• Sikkerhetsfeil blir aldri forsøkt kjørt på nytt automatisk.

Kriterium for å bestå. Du kan bevise både riktig autorisasjon og leietakerisolering med leseforespørsler etter testen, ikke bare ved hjelp av statuskoder.

Bevis én ren transaksjon

Kjør en liten, deterministisk flyt: opprett eller finn en testkunde, opprett en faktura med desimalstrengbeløp, utsted den, les fakturaen og dens regnskapsmessige virkning, les revisjonsposten, og motta webhooken. Nordlets «Kom i gang»-eksempel viser at utstedelse av faktura tildeler et hullfritt nummer, sjekker at perioden er åpen, og bokfører et balansert bilag i den samme transaksjonen.

Bekreft at fakturaen når forventet tilstand, at dokumentnummeret tildeles nøyaktig én gang, at debet er lik kredit, at MVA og linjesummer samsvarer med forventet avrunding, at revisjonsposten navngir hvem som utførte handlingen samt endringen, at webhooken til slutt blir levert, og at API-responsen og en oppfølgende leseforespørsel er enige om faktura-ID og tilstand.

Én ting som er verdt å merke seg: at en webhook ankommer er ikke bevis på at endringen ble gjennomført. API-responsen pluss en ny leseforespørsel er dine primære transaksjonsbekreftelser. Webhooken beviser varsling lenger nede i kjeden, og den testes separat.

Idempotens: samme nøkkel, samme innhold

Generer én nøkkel per logiske forretningsoperasjon, ikke én nøkkel per nettverksforsøk. Send endringen med nøkkel K og innhold B, lagre den opprettede ID-en, og send deretter nøyaktig den samme forespørselen på nytt.

Bekreft at den andre responsen representerer den samme operasjonen, at objekt-ID-en er identisk, og at det finnes ett forretningsobjekt, én bokføring, ett dokumentnummer og én finansiell virkning. Den replikerte responsen skal inneholde det dokumenterte avspillingshodet (x-idempotent-replay: true i Nordlets tilfelle), og revisjonssporet skal ikke vise noen andre endring.

To lagringsregler endrer hva omkjøringsflyten (retry-loop) din bør forvente, så test dem direkte: en lagret 4xx-feil spilles av som en hvilken som helst annen respons, mens en 5xx-feil ikke lagres i det hele tatt, slik at et nytt forsøk etter en serverfeil utfører operasjonen på nytt i stedet for å spille av et tidligere resultat. Nøkler utløper også, i Nordlet etter 24 timer, noe som setter en grense for hvor lenge en avspilling er tilgjengelig.

Nordlets dokumentasjon lover at det å legge til et Idempotency-Key-hode forhindrer at en forespørsel som kjøres på nytt, oppretter en duplikat, og API-konvensjonene definerer det nøyaktige avspillingshodet og kravet om byte-for-byte-identisk respons. Prinsippet samsvarer med Stripes publiserte modell: en nøkkel identifiserer den logiske operasjonen, gjentakelser returnerer det lagrede resultatet, og en nøkkel som gjenbrukes med ulike parametere blir avvist i stedet for å bli endret i det stille.

Kriterium for å bestå. Nøyaktig én finansiell tilstandsendring eksisterer uansett hvor mange ganger klienten sender den samme forespørselen innenfor avspillingsvinduet.

Idempotens: samme nøkkel, endret innhold

Send den opprinnelige forespørselen med nøkkel K og innhold B1, deretter en andre forespørsel med nøkkel K og innhold B2 der minst ett beløp, en kunde, en dato eller en linje er forskjellig.

Forventet resultat: forespørselen avvises med den dokumenterte feilen for gjenbruk av nøkkel (Nordlet returnerer 422 idempotency_key_reuse), den opprinnelige posten forblir urørt, ingen ny post eller nummer eller revisjonsendring dukker opp, og klienten «fikser» det ikke ved å generere en ny nøkkel. Å akseptere B2 i det stille ville gjøre omkjørings-nøkler utrygge.

Samtidige, dupliserte forespørsler

Send to identiske forespørsler med samme nøkkel i nøyaktig samme øyeblikk. Avhengig av den dokumenterte oppførselen utføres den ene mens den andre mottar en konflikt som indikerer at arbeidet pågår (Nordlet returnerer 409 idempotency_in_progress), eller begge observerer etter hvert det samme resultatet.

Bekreft at begge kallene ikke kan skape uavhengige finansielle virkninger, at maksimalt én dokumentnummer tildeles, at en midlertidig konflikt prøves på nytt med den samme nøkkelen i stedet for en ny, at den endelige ressursen er komplett og lesbar, og at idempotensposten ikke forblir fastlåst for alltid.

Feiltype. Et omkjøringsbibliotek som lager en ny UUID for hvert forsøk, gjør om en logisk operasjon til flere uavhengige skrivehandlinger og ødelegger idempotensen fullstendig.

Det usikre utfallet etter en tapt tilkobling

Dette er den aller viktigste produksjonssimuleringen. Send en endring med nøkkel K, la serveren gjennomføre den, avbryt tilkoblingen før responsen kommer, registrer utfallet som ukjent, prøv deretter på nytt med den samme nøkkelen K og avstem ved å lese ressursen og revisjonsdataene.

Bekreft at det nye forsøket returnerer den opprinnelige eller dokumenterte avspillingsresponsen, at nøyaktig én finansiell sideeffekt eksisterer, at klienten markerer operasjonen som fullført først etter en vellykket avspilling eller en avstemmingslesing, og at ingen ny nøkkel genereres. En tidsavbrudd (timeout) betyr ikke at «ingenting skjedde». Stripe beskriver idempotens presist som beskyttelse mot tilkoblingsfeil der serveren kan ha behandlet en endring før klienten rakk å motta responsen.

En konservativ policy for nye forsøk

Beslutninger om å prøve på nytt avhenger både av feilen og av om operasjonen er idempotent, ikke bare av HTTP-metoden i seg selv.

Vanligvis mulig å prøve på nytt, samme nøkkel beholder: tilkobling tilbakestilt eller tidsavbrudd etter en idempotent endring, 408, 429 etter å ha fulgt retry-after, og 502/503/504. En dokumentert pågående idempotensrespons kan prøves på nytt etter en kort forsinkelse.

Ikke mulig å prøve på nytt uten avstemming: 400/422 valideringsfeil, 401/403 autentiseringsfeil, 404 for en manglende ressurs, forretningsmessige 409-konflikter som ikke er knyttet til en pågående nøkkel, et endret innhold på en eksisterende nøkkel, og avvisning på grunn av låst periode.

Bekreft bruk av begrenset eksponentiell bakoff-strategi (exponential backoff) med tilfeldig variasjon (jitter), eksplisitte maksimale forsøk og tidsbruk, at retry-after respekteres ved hastighetsbegrensninger (rate limits), at den samme nøkkelen beholdes på tvers av forsøk for én operasjon, en ny nøkkel for hver nye operasjon, og logger som skiller det opprinnelige forsøket fra nye forsøk.

Test hastighetsbegrensning separat. Kryss den dokumenterte grensen (Nordlet tillater som standard 300 forespørsler per minutt per API-nøkkel, og noen uautentiserte endepunkter har egne, lavere grenser per IP-adresse) og bekreft at serveren returnerer en hastighetsbegrensningsrespons, at klienten tolker retry-after som en pause i stedet for en feil, at den venter i stedet for å hamre løs, og at et forsøk på en begrenset endring gjenbruker den opprinnelige nøkkelen. Hodene x-ratelimit-* rapporterer gjenværende budsjett, noe som gir en god forhåndssjekk. Hold hastighetsbegrensingstester unna finansielle tester med mindre testmiljøet ditt kan skille et begrenset forsøk fra et gjennomført ett.

Verifisering av webhook-signaturer

Bygg en mottaker som tar vare på de rå bytene. For hver hendelse: fang opp det rå innholdet, les hodet x-nordlet-signature, beregn forventet HMAC-SHA256 med abonnementshemmeligheten (secret), sammenlign ved hjelp av en konstanttidssammenligning, parse JSON først etter verifisering, registrer leveringen, og returner en rask 2xx-respons etter at dataene er varig lagret. Nordlet signerer en HMAC over det rå innholdet, sender den som sha256=<hex>, og prøver leveranser på nytt med eksponentiell bakoff. Stripes veiledning for webhooks understreker viktigheten av å verifisere det uendrede rå innholdet med en konstanttidssammenligning.

Kjør negative tester: korrekt innhold og hemmelighet, korrekt innhold med feil hemmelighet, en endring på én byte i innholdet, omserialisert JSON med endret mellomrom, manglende hode, en feilaktig utformet signatur, avspilling av en gammel levering hvis opplegget inkluderer et tidsstempel, og en gyldig signatur levert til feil abonnement.

Kriterier for å bestå. Bare det riktige rå innholdet og den rette hemmeligheten aksepteres. Ugyldige signaturer gir en annen feilkode enn 2xx. Ugyldige innhold kommer aldri inn i regnskapskøen. Hemmeligheter holdes unna vanlige logger. Handleren bekrefter mottak først etter at hendelsen er varig lagret.

Dupliserte webhooks og webhooks ute av rekkefølge

Leveringspålitelighet er et eget problem i forhold til API-idempotens, og mottakeren må også være idempotent. Lever den samme hendelsen to ganger, lever en sale_invoice.paid-hendelse før en sale_invoice.issued-hendelse, returner en 500-feil etter lagring, men før responsen sendes, og spill av en hendelse som forbrukeren allerede har behandlet.

Bekreft at dupliserte leveranser ikke dupliserer betalinger, tilstandsendringer eller bilagshandlinger, at dedupliseringsnøkkelen bruker leverandørens leverings- eller hendelses-ID når en slik finnes (eller en dokumentert sammensatt nøkkel, aldri et vilkårlig tidsstempel), at hendelser som kommer ut av rekkefølge aldri overskriver nyere tilstand med eldre, at forbrukeren kan hente gjeldende tilstand fra API-et når rekkefølgen ikke er tilstrekkelig, og at mislykkede forbrukerforsøk rutes gjennom en kø eller en dødved-kø (dead-letter queue). Stripe advarer eksplisitt om at leveringsrekkefølgen ikke er garantert, og anbefaler å lagre behandlede hendelses-ID-er.

Hold endepunktet enkelt: valider formen, verifiser signaturen, lagre eller legg i kø, bekreft mottak, returner 2xx. Avstemming og varsling hører hjemme i asynkron behandling. Test det ved å få nedstrømsarbeidet til å sove forbi leveringstidsavbruddet; en korrekt mottaker bekrefter fremdeles mottak etter varig kølagring.

Åpne og låste regnskapsperioder

Nordlet håndhever periodelåser på bokføringstidspunktet på tvers av manuelle bilag, dokumentflyter og import, så test kontrollen på flere enn ett sted. Opprett tilsvarende dokumenter datert i en åpen periode, i en låst periode, i tidsrommet like før låsen, på den første dagen i neste åpne periode, og med en gyldig dokumentdato, men ugyldig bokføringsdato hvis API-et skiller de to.

For tilfellet med låst periode må du bekrefte at forespørselen avvises med den dokumenterte periodelåsfeilen (en 409 conflict i Nordlet), og at ingen bilagslinjer skrives, ingen dokumentnumre forbrukes, ingen dokumenter går over til bokført tilstand, og ingen vellykket webhook utløses. Versjonen med åpen periode bør fullføres med de samme finansielle verdiene.

** Kappløpstest (race test).** Start en bokføring mot en åpen periode, lås perioden midt under forespørselen, og bekreft at lagringen ikke kan omgå låsen. Det kritiske kriteriet for å bestå: en fullført bokføring lander aldri i en periode som var låst før transaksjonen ble fullført.

Revisjonsvennlighet og avstemming

For hver vellykket endring må du bekrefte at forretningsobjektet eksisterer, at regnskapsposten eksisterer med debet lik kredit, at revisjonsposten eksisterer, at webhook-hendelsen eksisterer eller kan hentes, og at operasjonsloggen din peker på leverandørobjektets ID der nye forsøk henviser til den samme logiske operasjonen.

For hver avvist endring må du bekrefte at det ikke finnes noe delvis dokument, at ingen nummer ble forbrukt med mindre kontrakten tillater reservering, at ingen hovedbokpost eksisterer, at ingen vellykket webhook eksisterer, og at feilen bærer med seg en forespørsels-ID for feilsøking. Nordlets konvensjoner beskriver endringsrevisjon og balanserte bokføringer som plattformgarantier, der balansen håndheves av en utsatt databasetrigger på transaksjonstidspunktet i stedet for utelukkende av applikasjonskoden. Gjør disse garantiene om til avstemmingsspørringer etter testen i stedet for å stole på HTTP-responsen.

Kjerne-testmatrise

Område	Testhandling	Forventet sjekk	Kriterium for å bestå
Autentisering	Ingen nøkkel, ugyldig nøkkel, utilstrekkelig tilgang	Strukturert 401/403; ingen sideeffekt	Alle avviste forsøk lager ingen regnskapspost
Skjema og penger	Ugyldig desimal, dato, obligatorisk felt	Feltnivå-valideringsfeil	Ingen omkjøring eller delvis skriving skjer
Normal bokføring	Opprett og utsted en faktura i en åpen periode	Ett dokument, ett balansert bilag, én revisjonspost	Tilstand ved lesing og hovedbok er enige
Avspilling med samme nøkkel	Gjenta identisk endring, samme nøkkel og innhold	Opprinnelig resultat spilt av; ingen duplikat	Objekt-ID, nummer, bilagseffekt, revisjon forblir enkle
Endret innhold, samme nøkkel	Gjenbruk nøkkel med et annet beløp	Dokumentert avvisning ved gjenbruk av nøkkel	Opprinnelig post uendret; ingenting nytt skrevet
Tapt tilkobling	Fullfør, avbryt, prøv på nytt med samme nøkkel	Avspilt resultat	Nøyaktig én finansiell sideeffekt
Låst periode	Bokfør et dokument datert i en låst periode	Avvisning grunnet periodelås	Ingen bilag, intet nummer, ingen vellykket webhook
Webhook-signatur	Feil hemmelighet, endret innhold	Annen feilkode enn 2xx fra mottaker	Bare korrekt rå innhold og hemmelighet akseptert

Hva jeg ville gjort først

Hvis tiden er knapp, bør du kjøre testene i den rekkefølgen som fanger opp de dyreste feilene. Start med omkjøring ved tapt tilkobling, fordi det ene scenarioet skaper de fleste faktiske duplikatene. Deretter følger paret med idempotens for samme nøkkel og endret innhold. Deretter låste perioder, siden en bokføring i en stengt måned er et revisjonsproblem som dukker opp sent. Signaturverifisering og webhooks ute av rekkefølge kommer etter det, og hele skjema- og autorisasjonsmatrisen kan kjøres kontinuerlig i CI så snart klienten stabiliserer seg.

Alt annet i denne planen støtter disse fem. Få dem til å bestå (grønne) mot et testfirma, med avstemmingslesinger som bekrefter sideeffektene, og du vil vite at integrasjonen er trygg før den berører en eneste ekte hovedbok. Du kan opprette et testfirma og en begrenset testnøkkel på noen få minutter fra Kom i gang, og sjekke hvilke moduler du trenger opp mot funksjonslisten.

FAQ

Er en 2xx-respons nok til å bekrefte at en regnskapsskriving lyktes?

Nei. En statuskode bekrefter at serveren svarte, ikke at det eksisterer nøyaktig ett dokument, én nummertildeling og én balansert bilagsføring. Hver endringstest bør etterfølges av en leseforespørsel av objektet, dets regnskapsvirkning og revisjonsposten. Det farlige tilfellet er den motsatte retningen: en operasjon som ble gjennomført uten at klienten noensinne mottok responsen i det hele tatt.

Bør jeg generere en ny idempotensnøkkel når en forespørsel får tidsavbrudd?

Nei, og dette er feilen som forårsaker de fleste produksjonsduplikater. Nøkkelen identifiserer den logiske forretningsoperasjonen, ikke nettverksforsøket. Prøv den samme nøkkelen på nytt, og avstem deretter ved å lese ressursen. Et omkjøringsbibliotek som lager en ny UUID for hvert forsøk, gjør om én tiltenkt faktura til flere uavhengige skrivehandlinger.

Hva skjer hvis jeg gjenbruker en idempotensnøkkel med et annet innhold?

Et korrekt API avviser den i stedet for å bruke det nye innholdet i det stille. Nordlet returnerer 422 idempotency_key_reuse og lar den opprinnelige posten være urørt. Klienten din bør behandle dette som en programmeringsfeil som må rettes, ikke som en tilstand som skal omgås ved å generere en ny nøkkel.

Er webhooks en erstatning for å lese det opprettede objektet på nytt?

Nei. Webhook-levering beviser varsling lenger nede i kjeden, ikke at transaksjonen ble gjennomført slik du forventer, og leveringsrekkefølgen er ikke garantert. Verifiser signaturen over det rå innholdet, dedupliser på leverings- eller hendelses-ID, og hent gjeldende tilstand fra API-et når hendelsesrekkefølgen alene ikke er nok til å avgjøre hva som har endret seg.

Hvordan tester jeg bokføring i en låst regnskapsperiode?

Opprett tilsvarende dokumenter i en åpen periode og i en låst periode, og bekreft at det låste tilfellet avvises uten bilagslinjer, uten forbrukt dokumentnummer, uten tilstandsendring og uten vellykket webhook. Kjør deretter kappløpstesten: start en bokføring mot en åpen periode og lås perioden midt under forespørselen. En fullført bokføring må aldri lande i en periode som var låst før transaksjonen ble fullført.

Kan jeg kjøre duplikat-tester i stort volum i et testfirma?

Ja. Et testfirma oppfører seg som et ekte firma, merkes som testdata og slettes umiddelbart i stedet for etter oppbevaringsvinduet, så det er det rette stedet for destruktive tester og duplikat-tester. Bruk av testmiljøet belastes fortsatt på samme måte som virkelig bruk, så planlegg volumet i stedet for å kjøre i en uendelig løkke.