PR-granskningar drar ut på tiden av en tråkig anledning: ingen vill stanna upp och skriva tester för någon annans ändringar, och författaren är redan vidare till nästa uppgift.
Tekniska ledare märker det när kvaliteten sjunker, och högen med “vi lägger till tester senare” växer i tysthet. Frontendutvecklare fastnar i ständiga kontextbyten. Och byråteam som levererar kundarbete? De behöver GitHub Jest-automatisering som håller tempot utan att testtäckningen förfaller.
Det här workflowet lyssnar på uppdateringar i pull requests, genererar utkast till Jest-tester med fokus på det som ändrats, kör en andra AI-granskningsrunda och publicerar sedan de föreslagna testerna direkt tillbaka i PR:en som en kommentar. Du får se vad det löser, vad du behöver och hur du anpassar det.
Så fungerar automatiseringen
Se hur detta löser problemet:
n8n Workflow Template: GitHub + OpenAI: Jest-tester klara för PR
flowchart LR
subgraph sg0["Structured Output Pa Flow"]
direction LR
n1["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>GET .diff file"]
n2["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Splits text into array"]
n3["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>FIlter for components"]
n4["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Extrat API URL, owner and repo"]
n5["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Get File name"]
n6@{ icon: "mdi:cog", form: "rounded", label: "Get Files", pos: "b", h: 48 }
n7@{ icon: "mdi:robot", form: "rounded", label: "Structured Output Parser", pos: "b", h: 48 }
n8["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/merge.svg' width='40' height='40' /></div><br/>Merge info needed"]
n9@{ icon: "mdi:robot", form: "rounded", label: "Test Maker", pos: "b", h: 48 }
n10@{ icon: "mdi:cog", form: "rounded", label: "Get Repo", pos: "b", h: 48 }
n11@{ icon: "mdi:robot", form: "rounded", label: "Code Reviewer", pos: "b", h: 48 }
n12@{ icon: "mdi:brain", form: "rounded", label: "o3-mini", pos: "b", h: 48 }
n13@{ icon: "mdi:brain", form: "rounded", label: "gpt4.1-mini", pos: "b", h: 48 }
n14["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/merge.svg' width='40' height='40' /></div><br/>Merge"]
n15["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Prepare for POST"]
n16["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>POST Comments"]
n17["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/webhook.dark.svg' width='40' height='40' /></div><br/>Webhook"]
n19@{ icon: "mdi:robot", form: "rounded", label: "Structured Output Parser1", pos: "b", h: 48 }
n14 --> n15
n17 --> n4
n12 -.-> n9
n10 -.-> n9
n10 -.-> n11
n6 -.-> n9
n6 -.-> n11
n9 --> n11
n13 -.-> n11
n11 --> n14
n5 --> n9
n1 --> n2
n15 --> n16
n8 --> n5
n3 --> n8
n2 --> n3
n7 -.-> n9
n19 -.-> n11
n4 --> n1
n4 --> n8
n4 --> n14
end
subgraph sg1["Flow 2"]
direction LR
n0["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/github.dark.svg' width='40' height='40' /></div><br/>GH - Get PR"]
end
subgraph sg2["Flow 3"]
direction LR
n18["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>2nd Node for Testing"]
end
%% Styling
classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef disabled stroke-dasharray: 5 5,opacity: 0.5
class n7,n9,n11,n19 ai
class n12,n13 aiModel
class n1,n16,n17 api
class n2,n3,n4,n5,n15,n18 code
classDef customIcon fill:none,stroke:none
class n1,n2,n3,n4,n5,n8,n14,n15,n16,n17,n0,n18 customIcon
Utmaningen: PR-ändringar levereras snabbare än tester
Att skriva Jest-tester under en PR är rätt väg att gå, men det är också det enklaste att skjuta upp. Du läser en diff, tänker på edge cases, och så pingar någon dig i Slack och tråden är borta. En granskare kan be om tester, författaren lovar att lägga till dem, och sedan mergas PR:en ändå eftersom deadlinen är på riktigt. Senare blir aldrig. Under tiden slinker buggar in runt “små” ändringar i UI-logik i React/TypeScript-filer, precis den typen som känns för liten för att testa tills den går sönder.
Det byggs upp snabbt. Här är var det fallerar i det dagliga granskningsarbetet.
- Granskare hamnar i diskussioner om beteende i kommentarer i stället för att låsa det med ett test.
- Författare slösar cirka en timme på att ladda om kontext bara för att skriva tester efter feedback.
- Luckor i testtäckning dyker upp i produktion som “det tänkte vi inte på”-edge cases.
- Även när tester läggs till varierar namn och struktur kraftigt, så team slutar lita på dem.
Lösningen: AI-genererade Jest-tester publicerade direkt i PR:en
Den här automatiseringen drar igång så fort en pull request öppnas eller uppdateras i GitHub. Den hämtar PR-detaljerna, hämtar unified diff och delar sedan upp diffen i filstora delar så den kan fokusera på det som faktiskt ändrats. Därefter filtrerar den fram React/TypeScript-komponenter (endast .tsx) och hämtar hela filinnehållet från repot som kontext. Med diff-hunks och den riktiga filen som underlag genererar OpenAI utkast till Jest-enhetstester som bara riktar in sig på de ändrade beteendena, inte hela projektet. Sedan granskar en andra AI-runda testerna, skärper namngivning, lägger till edge cases och gör outputen till något som känns som att en kollega hade skrivit. Till sist publicerar workflowet det färdiga förslaget som en PR-kommentar, redo att kopieras in i din kodbas.
Workflowet startar med en GitHub PR-webhook och använder PR:ens diff_url för att hämta exakt ändringstext. AI skriver tester baserat på dessa hunks och den aktuella filen, och en granskningsrunda förbättrar dem innan n8n postar resultatet tillbaka i samma PR-tråd.
Vad som förändras: före vs. efter
| Detta elimineras | Effekten du ser |
|---|---|
|
|
Effekt i verkligheten
Säg att ditt team mergar 10 PR:er i veckan som rör UI-logik. Manuellt tar även “snabb” testskrivning kanske 30 minuter per PR när du räknar in att ladda kontext, köra tester och fixa namngivning, så du bränner cirka 5 timmar i veckan. Med det här workflowet triggar en PR-uppdatering generering automatiskt och du lägger oftast runt 5 minuter på att granska den föreslagna sviten innan du kopierar in den. Det är ungefär 4 timmar tillbaka de flesta veckor, och PR-diskussionen håller sig fokuserad.
Krav
- n8n-instans (prova n8n Cloud gratis)
- Alternativ för self-hosting om du föredrar det (Hostinger fungerar bra)
- GitHub för att ta emot PR-händelser och posta kommentarer.
- OpenAI för testgenerering och granskningsrundor.
- GitHub-token (skapa i GitHubs Developer settings)
Kunskapsnivå: Medel. Du kopplar GitHub-uppgifter, lägger in en OpenAI-nyckel och verifierar att webhook-händelser triggar för ditt repo.
Behöver du hjälp att implementera detta? Prata med en automationsexpert (gratis 15-minuters konsultation).
Workflowflödet
En pull request-händelse träffar din webhook. När en PR öppnas eller synkroniseras (uppdateras med nya commits) anropar GitHub din n8n-webhook-endpoint med PR-payloaden.
Workflowet hämtar PR-diffen och isolerar rätt filer. n8n hämtar PR-detaljer, använder den angivna diff_url och delar upp unified diff i sektioner per fil. Sedan filtrerar den ner till .tsx-ändringar så att du inte genererar tester för orelaterade filer.
OpenAI genererar tester och granskar dem sedan. För varje ändrad komponent hämtar workflowet fullständigt filinnehåll från GitHub och skickar både filen och diff-hunks till en AI-prompt för “Test Maker”. En andra AI-agent granskar outputen för läsbarhet, namngivningskonventioner och edge cases, vilket är där förslagen blir betydligt mer användbara.
Den föreslagna Jest-sviten publiceras som en PR-kommentar. n8n omsluter testerna i TypeScript-kodstaket, bygger GitHub-kommentarpayloaden och postar den tillbaka till PR-konversationen via GitHub API.
Du kan enkelt ändra .tsx-filtret så att det även inkluderar .ts-logikfiler, eller justera promptarna för att tvinga igenom teamets teststil. Se den fullständiga implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementation
Steg 1: Konfigurera webhook-triggern
Det här arbetsflödet startar när en webhook tas emot, så börja med att konfigurera ingångspunkten.
- Lägg till och öppna Incoming Webhook Trigger.
- Låt standardparametrarna vara som de är om ni inte behöver en anpassad webhook-sökväg för ert reposystem.
- Kopiera Test URL från Incoming Webhook Trigger för att använda under den inledande testningen.
Steg 2: Anslut GitHub och datakällor för repositoriet
Dessa noder hämtar PR-metadata, repositoriefiler och diff-innehåll som behövs för analys.
- Öppna Utility: Retrieve PR Details och anslut den till ert GitHub-konto om ni planerar att använda PR-metadata.
- Öppna Retrieve Diff File och konfigurera den för att anropa PR-diff-endpointen som används av ert reposystem.
- Öppna Retrieve Repository Files och Fetch Repository Data (AI-verktyg) och verifiera att de pekar mot rätt repositorykontext.
- Credential Required: Anslut era GitHub-inloggningsuppgifter för Utility: Retrieve PR Details, Retrieve Repository Files och Fetch Repository Data.
Steg 3: Konfigurera diff-tolkning och förberedelse av indata
Den här delen tolkar diffen till användbara komponenter och förbereder metadata för efterföljande AI-steg.
- Öppna Derive API Repo Info och säkerställ att den extraherar repositoryidentifierare som används i senare anrop.
- Konfigurera tolkningskedjan: Retrieve Diff File → Split Text List → Filter Component Parts → Combine Required Info → Extract File Name.
- Bekräfta att Derive API Repo Info skickar output parallellt till både Retrieve Diff File och Combine Required Info, och även parallellt till Merge Streams för senare sammanfogning.
- Granska de extra kodhjälparna (Split Text List, Filter Component Parts, Extract File Name, Prepare Post Payload, Utility: Secondary Test Node) för att säkerställa att de matchar ert förväntade diff-format.
Steg 4: Konfigurera AI-generering och granskning
Dessa noder genererar testfall och genomför kodgranskning med OpenAI-modeller och strukturerade parsers.
- Öppna Generate Test Cases och verifiera att den tar emot filnamns-output från Extract File Name.
- Öppna Review Code Changes och bekräfta att den tar emot output från Generate Test Cases.
- Säkerställ att OpenAI o3 Mini är ansluten som språkmodell för Generate Test Cases och att OpenAI GPT4.1 Mini är ansluten som språkmodell för Review Code Changes.
- Verifiera de strukturerade output-parsers: Structured Result Parser är kopplad till Generate Test Cases, och Structured Result Parser B är kopplad till Review Code Changes. Lägg till eventuella inloggningsuppgifter på de överordnade agentnoderna, inte på parser-undernoderna.
- Credential Required: Anslut era OpenAI-inloggningsuppgifter i OpenAI o3 Mini och OpenAI GPT4.1 Mini.
Steg 5: Förbered och skicka granskningskommentarer
Efter analysen sammanfogar arbetsflödet output och publicerar granskningskommentarer.
- Bekräfta att Review Code Changes matar in till Merge Streams och att Derive API Repo Info också skickar output till Merge Streams.
- Öppna Prepare Post Payload och säkerställ att den sammanställer det sammanfogade innehållet som behövs för gransknings-API:t.
- Öppna Submit Review Comments och ställ in den mot ert repositories endpoint för granskningskommentarer.
- Credential Required: Anslut eventuell API-autentisering i Submit Review Comments om ert repository-API kräver det.
Steg 6: Testa och aktivera ert arbetsflöde
Kör ett fullständigt test för att bekräfta att pipelinen producerar en strukturerad granskning och publicerar kommentarer utan problem.
- Klicka på Execute Workflow och skicka en exempel-payload för webhook till Incoming Webhook Trigger.
- Följ att körningen lyckas i de parallella grenarna från Derive API Repo Info till Retrieve Diff File, Combine Required Info och Merge Streams.
- Bekräfta att Prepare Post Payload tar emot sammanfogad data och att Submit Review Comments returnerar ett lyckat API-svar.
- När testningen är klar, växla arbetsflödet till Active för att aktivera webhook-hantering i produktion.
Se upp för
- GitHub-credentials kan löpa ut eller behöva specifika behörigheter. Om saker slutar fungera, kontrollera token-scopes i GitHubs Developer settings och bekräfta först att repot tillåter webhooks.
- Om du använder Wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om efterföljande noder fallerar på tomma svar.
- Standardpromptar i AI-noder är generiska. Lägg in er tonalitet tidigt, annars kommer du redigera output för alltid.
Vanliga frågor
Cirka 30 minuter om din GitHub-token och OpenAI-nyckel är klara.
Ja, men de behöver fortfarande någon som kan skapa en GitHub-token och verifiera webhook-händelser. Efter det handlar det mest om att koppla konton och klistra in nycklar.
Ja. n8n har ett gratis self-hosted-alternativ och en gratis provperiod på n8n Cloud. Cloud-planer startar på 20 USD/månad för högre volymer. Du behöver även räkna in OpenAI API-användning, vilket vanligtvis är några cent per PR-kommentar om inte dina diffs är enorma.
Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller self-hosting på en VPS. För self-hosting är Hostinger VPS prisvärd och hanterar n8n bra. Self-hosting ger obegränsat antal körningar men kräver grundläggande serverhantering.
Börja med att ändra filtret som bara behåller .tsx-filer om du även vill ha tester för .ts-utilities eller backendkod. Justera sedan agentprompten för “Generate Test Cases” så att den matchar din stack (React Testing Library vs Enzyme, Vitest vs Jest, era namngivningsregler). Många team justerar också comment builder så att den postar en samlad kommentar per PR i stället för per fil, vilket håller diskussionerna prydliga. Om ni har konventioner i ett dokument, klistra in ett kort utdrag i granskningsagentens prompt så att den automatiskt följer er stil.
Oftast beror det på en utgången token eller saknade scopes för att läsa PR:er och posta issue comments. Generera om GitHub-tokenen, uppdatera credential i n8n och bekräfta att webhooken triggar för pull_request-händelser. Om det fungerar för små PR:er men fallerar för stora kan du också slå i rate limits när du hämtar filinnehåll för många ändrade filer samtidigt.
På en typisk n8n Cloud-plan begränsas du främst av månatliga körningar, eftersom varje PR-uppdatering kan trigga flera körningar över ändrade filer. Om du self-hostar finns ingen körningsgräns, men väldigt stora diffs blir långsammare och kostar mer i OpenAI-användning. I praktiken kör de flesta team detta utan problem över dussintals PR:er per dag så länge de håller scope tajt (som .tsx-filtret) och undviker att dumpa hela repos i AI-kontexten.
Ofta, ja. Det här flödet kräver flerstegsparsing (diff-splitting, loopar per fil, sammanfogning av strömmar) och mer kontroll över payloads, vilket är där n8n är ett bättre val. Du får också ett self-hosting-alternativ för repos med hög volym, och du tvingas inte in i prissättning av typen “en task per mikrosteg”. Zapier eller Make kan vara enklare för lätta notifieringar, men blir klumpiga när du bearbetar diffs och bygger GitHub-kommentarsinnehåll. Om du vill få en snabb kontroll, prata med en automationsexpert så hjälper vi dig att välja.
Du får PR-kommentarer som driver testtäckningen framåt utan att kapa granskningen. Sätt upp det en gång, så slutar teamet betala “tester senare”-skatten.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.