Codex Agentic Test Automation Kit

Tijdens een eerdere professionele rol bij een Belgische dienstverlenende organisatie werd een lokaal installeerbare multi-agent toolkit voor testautomatisering ontwikkeld. Binnen 5A Technologies bouwen we voort op de opgebouwde expertise in agentic orchestratie en testautomatisering. Gebruikers konden testinformatie aanleveren via CSV, Excel, user stories of vrije tekst. De kit analyseerde de vraag, selecteerde een passende workflow en bouwde vervolgens een testoplossing binnen de bestaande repository.

• Context: testautomatisering binnen bestaande repositories
• Project: lokaal installeerbare private multi-agent toolkit uit een eerdere professionele rol
• Status: afgerond intern hulpmiddel
• Rol van 5A Technologies: voortbouwen op expertise in agentic architectuur, workfloworchestratie, testautomatisering, begrensde kwaliteitslussen en lokale developer tooling
• Kernprincipes: één gedeeld automation contract, afgebakende agentverantwoordelijkheden, lokale uitvoering en uitvoeringsbewijs

Belangrijk ontwerpprincipe
Een gegenereerd bestand gold niet automatisch als afgeronde automatisering. De flow maakte expliciet onderscheid tussen gegenereerd, uitvoerbaar, geslaagd en geblokkeerd werk en liet quality gates bepalen of de uitvoering verder mocht.

De oplossing ondersteunde verschillende soorten automatisering:

• UI-tests;
• API-tests;
• unit tests;
• combinaties van meerdere testlagen;
• uitbreiding of herstel van bestaande testsuites;
• analysis-only wanneer implementatie nog niet verantwoord was.

Vier gespecialiseerde agents werkten daarbij samen: een Analysis Agent, Architecture Agent, Implementation Agent en Quality Agent. Een afzonderlijke Codex-sessie coördineerde de run, bewaakte de grenzen en ontving de finale handover.

Testautomatisering start vaak met ongestructureerde of inconsistente input: testcases in bestanden, user stories met acceptance criteria, losse functionele beschrijvingen, ontbrekende technische context en repositories met verschillende frameworks.

Een engineer moet die input normaal eerst interpreteren, de bestaande architectuur onderzoeken, een aanpak kiezen, code schrijven, tests uitvoeren en fouten gericht herstellen. Wanneer UI-, API- en unittests samenkomen, wordt ook de overdracht tussen analyse, architectuur, implementatie en kwaliteitscontrole snel moeilijk traceerbaar.

De Agent Kit bracht deze stappen samen in één herhaalbare, lokale workflow. Daarbij bleef iedere verantwoordelijkheid zichtbaar: de coördinator bewaakte de run, gespecialiseerde agents leverden afgebakende output en quality gates bepaalden of de flow verder mocht.

De toolkit werd als een private npm-package lokaal geïnstalleerd. Na initialisatie inspecteerde ze het doelproject, laadde ze de toegestane configuratie en normaliseerde ze de beschikbare input naar één gedeeld automation contract.

Een workflowrouter selecteerde vervolgens een voorgedefinieerde flow voor:

• een nieuwe of bestaande UI-testsuite;
• API-testautomatisering;
• unit-testgeneratie;
• gecombineerde feature-automatisering;
• herstel van falende of onvolledige tests;
• analyse zonder implementatie.

De geselecteerde workflow bepaalde welke agents nodig waren, in welke volgorde ze werkten, welke compatibele adapters werden hergebruikt en welke kwaliteitsvoorwaarden moesten worden gehaald.

1. De gebruiker leverde testinformatie aan via CSV, Excel, user stories of vrije tekst.
2. De coördinerende Codex-sessie bakende de run af en laadde de toegestane projectconfiguratie.
3. De invoer werd genormaliseerd naar één gedeeld automation contract.
4. De workflowrouter selecteerde de passende flow, agents en compatibele adapters.
5. De Analysis Agent valideerde scenario's, acceptance criteria, repositorycontext en ontbrekende informatie.
6. De Architecture Agent vertaalde die analyse naar een uitvoerbaar test- en implementatieplan.
7. De Implementation Agent maakte of herstelde tests en voerde ze lokaal uit via de repositorytools.
8. De Quality Agent controleerde het uitvoeringsbewijs en stuurde problemen gericht terug naar Analysis, Architecture of Implementation.
9. Na vrijgave of een gecontroleerde stop ontving de gebruiker de finale handover met resultaten, bewijs, blokkades en resterende acties.

CSV, Excel, user stories en vrije tekst werden eerst naar een gemeenschappelijke structuur vertaald. Die structuur beschreef onder meer de bron, gevraagde testlagen, scenario's, voorwaarden, stappen, verwachte resultaten en toegestane wijzigingen.

Daardoor hoefden de agents niet voor ieder invoerformaat een andere implementatielogica te volgen. Het contract vormde een traceerbare grens tussen de gebruikersvraag, de repositorycontext en de gekozen uitvoering.

De bronvorm zelf werd niet als bewijs van volledigheid behandeld. Ontbrekende informatie bleef expliciet zichtbaar en kon een gerichte vraag, analysis-only resultaat of menselijke blokkade veroorzaken.

De toolkit legde niet voor ieder project één testframework op. Ze inspecteerde eerst taal, repositorystructuur, bestaande tests en beschikbare commando's. Daarna koos ze een compatibele adapter of breidde ze bestaande patronen uit.

Afhankelijk van de repository konden bijvoorbeeld UI-, API- of unit-testadapters worden hergebruikt. Dat betekent niet dat ieder mogelijk framework standaard ingebouwd was. De voorkeur ging naar de aanwezige architectuur; een nieuwe dependency of testlaag werd alleen overwogen wanneer de configuratie dat toeliet.

Feature flags en toegangsgrenzen bepaalden onder meer welke workflows actief waren, of dependencywijzigingen waren toegestaan, of automatisch herstel mocht starten en wanneer de iteratielus moest stoppen.

Coördinerende Codex-sessie

De coördinerende Codex-sessie stond los van de vier gespecialiseerde agents. Ze startte en begrensde de orchestratie, bewaakte de geselecteerde workflow, hield runstatus en iteratie bij en ontving uiteindelijk het controleerbare eindrapport.

Analysis Agent

De Analysis Agent vertaalde de gebruikersvraag naar een uitvoerbare opdracht. De agent valideerde scenario's, koppelde acceptance criteria, onderzocht relevante repocontext, identificeerde ontbrekende informatie en bepaalde wat wel en niet automatiseerbaar was.

De output was een gestructureerd analysecontract voor de volgende handoff. Bij onvoldoende basis kon de flow bewust als analysis-only eindigen.

Architecture Agent

De Architecture Agent bepaalde hoe de tests in het bestaande project moesten passen. De agent koos compatibele adapters en ontwierp waar nodig suites, fixtures, page objects, clients, mocks, testdata, uitvoercommando's en concrete quality gates.

Die keuzes werden als een uitvoerbaar implementatieplan aan de Implementation Agent overgedragen.

Implementation Agent

De Implementation Agent maakte of herstelde tests en ondersteunende code. De agent kon bestaande tests uitbreiden, helpers en testdata toevoegen, configuratie begrensd aanpassen en iedere wijziging aan de relevante scenario's koppelen.

Na de implementatie volgde een eerste lokale uitvoering via de repositorytools.

Quality Agent

De Quality Agent accepteerde geen oplossing alleen omdat er code gegenereerd was. De agent controleerde onder meer build, types, lint, test discovery, daadwerkelijke uitvoering, skips, assertions, aansluiting op acceptance criteria, hergebruik, duplicatie, foutafhandeling en resterende risico's.

Het verdict maakte onderscheid tussen gegenereerd, uitvoerbaar, geslaagd en geblokkeerd werk.

Een afkeuring leidde niet automatisch tot een volledige herstart. De Quality Agent maakte een gestructureerd feedbackpakket en stuurde het naar de agent die het probleem het best kon herstellen:

• een verkeerd geïnterpreteerd scenario ging terug naar Analysis;
• een structureel of architecturaal probleem ging terug naar Architecture;
• een code- of configuratiefout ging terug naar Implementation;
• iedere nieuwe versie passeerde opnieuw Quality.

Zo bleef iedere handoff gericht en traceerbaar. De coördinerende sessie bewaakte welke versie actief was, waarom een herstellus startte en welke quality gate daarna opnieuw moest worden uitgevoerd.

Begrensde stopcondities

De lus stopte wanneer alle verplichte quality gates slaagden, wanneer het configureerbare iteratiemaximum was bereikt of wanneer een externe blokkade menselijke input, toegang of een productbeslissing vereiste.

Bij een blokkade bleef het gedeeltelijke resultaat behouden. De handover vermeldde welke stap niet verantwoord kon doorgaan en welke actie nodig was om verder te werken.

Agents werkten via begrensde filesystem-, process-, framework- en test-runneradapters. Die tools konden de repository onderzoeken, toegestane bestanden aanpassen en bestaande build-, type-, lint- en testcommando's uitvoeren.

De resultaten werden als uitvoeringsbewijs teruggegeven aan Quality. Een gegenereerd bestand zonder geslaagde controles gold dus niet automatisch als een afgeronde automatisering.

De workflow bleef lokaal uitvoerbaar en sloot aan op de repository waarin de gebruiker al werkte. Er was geen publieke renderingservice of autonoom publicatiepad nodig.

Een MCP-memorylaag met SQLite bewaarde duurzame projectcontext en semantisch herbruikbare informatie, zoals eerder onderzochte repositorystructuur, architectuurbeslissingen, genormaliseerde requirements, scenario-identifiers, quality findings en gekende commando's.

Agents konden relevante context opnieuw ophalen zonder iedere iteratie volledig vanaf nul te beginnen. Wanneer bronbestanden of repository-inhoud wijzigden, werd verouderde context ongeldig gemaakt. De cache bleef daardoor ondersteunend en werd niet blind als actuele waarheid behandeld.

Een lokaal React- en Vite-board kon live events via Server-Sent Events ontvangen. Het maakte onder meer de geselecteerde workflow, huidige agent, iteratie, handoffs, commando's, testresultaten, gewijzigde bestanden, quality findings, blokkades en finale status zichtbaar.

Het board nam zelf geen beslissingen. Het was een observabilitylaag die gebruikers liet volgen waarom de flow doorging, terugkeerde naar een agent of gecontroleerd stopte.

Package, configuratie en invoer

• TypeScript, Node.js en npm voor lokale installatie en uitvoering;
• parsers en JSON Schema voor normalisatie van verschillende bronnen;
• YAML- of JSON-configuratie en feature flags om gedrag per repository te begrenzen.

Orchestratie en repositoryadapters

• typed state-machine workflows voor selectie, handoffs, retries en stopcondities;
• Codex met afzonderlijke agentverantwoordelijkheden voor analyse, architectuur, implementatie en quality;
• filesystem-, process-, framework- en test-runneradapters voor lokale uitvoering.

Memory, events en visualisatie

• een MCP-memoryserver met SQLite voor context en semantische caching;
• React, Vite en Server-Sent Events voor het lokale Agent Board;
• build-, lint-, test- en traceabilitychecks als technische en functionele quality gates.

Na vrijgave of een gecontroleerde stop keerde de controle terug naar de coördinerende Codex-sessie. De gebruiker ontving een eindrapport met:

• volledig, gedeeltelijk en niet-geautomatiseerd werk;
• het onderscheid tussen gegenereerd, uitvoerbaar, geslaagd en geblokkeerd;
• aangemaakte of aangepaste bestanden;
• uitgevoerde tests en kwaliteitscontroles;
• commando's om de suite opnieuw te draaien;
• externe blokkades, risico's en resterende acties.

Er werd geen succes gemeld enkel omdat er code was geschreven.

Binnen 5A Technologies bouwen we voort op ervaring met:

• de end-to-end agentic architectuur;
• de voorgedefinieerde workflows en routering;
• het gedeelde automation contract;
• de verantwoordelijkheden en handoff-contracten van de vier agents;
• de implementatie- en herstelcycli;
• de quality gates en begrensde feedbackloop;
• de lokale package- en featureconfiguratie;
• de MCP-memory- en cachingstrategie;
• het live visualisatieboard;
• de rapportering en technische handover.

De Agent Kit bracht uiteenlopende testinput samen in één controleerbaar automatiseringsproces. De orchestrator selecteerde de passende workflow, gespecialiseerde agents leverden afgebakende tussenresultaten en de Quality Agent stuurde problemen gericht terug naar analyse, architectuur of implementatie.

Dit project laat zien hoe een agentic testtoolkit:

• multi-agent orchestration opdeelt in afzonderlijke verantwoordelijkheden voor analyse, architectuur, implementatie en quality;
• automation contracts en gerichte handoffs gebruikt om iedere overgang traceerbaar te houden;
• herstellussen begrenst met quality gates, stopcondities en menselijke blokkades;
• testarchitectuur en lokale developer tooling laat aansluiten op een bestaande repository;
• MCP-geheugen en observability inzet als ondersteuning zonder er autonome beslissingslagen van te maken;
• codegeneratie pas als geslaagd behandelt wanneer uitvoeringsbewijs en kwaliteitscontroles dat onderbouwen.

De publieke projectbeschrijving bewaakt de volgende grenzen:

• de organisatienaam blijft geanonimiseerd;
• interne repository-, package- en configuratienamen worden niet genoemd;
• prompts, credentials, testdata, applicatienamen en bedrijfsscreenshots blijven buiten de publieke inhoud;
• er worden geen aantallen, besparingen, adoptie of slagingspercentages geclaimd;
• ondersteuning van ieder mogelijk framework wordt niet geclaimd;
• technologieën en werking worden alleen op architectuurniveau beschreven;
• interne implementatiedetails worden niet gepubliceerd.