Hoe integraties testen

Je hebt FileMaker verbonden met je webshop, je boekhoudpakket of een AI-service, en alles werkt — tot de dag waarop het niet meer werkt. Een order faalt geruisloos bij het synchroniseren naar Exact Online, een API-sleutel verloopt en niemand merkt het drie weken lang op, of een script dat twee jaar lang foutloos heeft gedraaid, blijkt ineens vast te lopen op een naamveld met een emoji. Dit artikel laat zien hoe je integrations werkelijk test zodat deze fouten worden opvangen in een testomgeving, niet voor je klanten.

Waarom breken integrations vaker dan "normale" software?

Een zelfstandige FileMaker-oplossing hoeft zich alleen correct te gedragen binnen zijn eigen vier muren. Een integration hangt af van minstens één ander systeem dat stabiel blijft, bereikbaar is en consistent werkt — en dat systeem beheers jij niet.

Concreet voorbeeld: een Loggix-klant had een werkende connector tussen FileMaker en de API van een verzendmaatschappij. De verzendmaatschappij rolde een kleine API-update uit die een datumformat wijzigde van YYYY-MM-DD naar een ISO-timestamp met timezone-offset. Niets in FileMaker veranderde. Niets in het proces van de klant veranderde. Maar elke nieuwe aanvraag voor een verzendlabel begon van de ene op de andere dag te mislukken, omdat het script dat datumveld parseerde van het oude format uitging.

Dit is de kern van integrationtesting: je test niet alleen je eigen code, je test de voeg tussen twee systemen die beide onafhankelijk van elkaar kunnen veranderen. Die voeg is waar bijna elke integrationbug zich bevindt.

Wat moet werkelijk worden getest in een integration?

De meeste teams testen alleen het "happy path" — gaat de data van A naar B als alles normaal verloopt? Dat is nodig, maar volstrekt onvoldoende. Een goed testplan dekt het volgende:

1. Het happy path — een normale order, een normaal klantrecord, een normale AI-prompt, stroomt correct end-to-end.
2. Misvormde of onverwachte invoer — lege velden, speciale karakters, ongebruikelijk lange tekst, verkeerde gegevenstypes (een telefoonnummer ingetypt in een numeriek veld).
3. Gedeeltelijke mislukking — de verbinding wordt verbroken halverwege een batch van 500 records. Wat gebeurt er met record 251?
4. Authenticatie en token-verlopen — API-sleutels, OAuth-tokens of certificaten die verlopen of ingetrokken worden.
5. Snelheidslimieten en throttling — wat gebeurt er als je 2.000 verzoeken naar een service stuurt die er slechts 100 per minuut toestaat?
6. Dubbele en verkeerde volgorde — dezelfde webhook wordt twee keer afgevuurd, of een "created"-event arriveert na het "updated"-event voor hetzelfde record.
7. Downtime van het downstream systeem — het andere systeem is eenvoudig offline of retourneert een 500-fout.
8. Gegevenskaartedge cases — een Nederlands adresveld met een huisnummertoevoeging, een naam met een apostrof, een decimaalteken versus een decimalepunt.

Als je testplan alleen punt 1 dekt, heb je een demo, geen geteste integration.

Hoe richt je een veilige testomgeving in?

Je wilt nooit testen tegen je live boekhoudpakket, live webshop of productie-AI-account die per token wordt gefactureerd. Zorg voor goede scheiding:

• Sandbox- of testaccounts — de meeste serieuze platformen (Exact Online, e-Boekhouden, Shopify, Stripe, OpenAI-achtige AI-API's) bieden een sandbox- of testmodus. Gebruik die, zelfs als het een extra uur duurt om in te stellen.
• Een geklonde kopie van je FileMaker-bestand — met een aparte gegevensbron die naar de sandbox wijst, nooit naar het live API-endpoint. Dit zou routine-praktijk moeten zijn, en het is precies het soort omgevingsdiscipline dat wordt behandeld in de gids van Loggix over hoe je aangepaste bedrijfssoftware betrouwbaar en overdraagbaar maakt.
• Realistische maar nep-testgegevens — niet drie nette voorbeeldrecords, maar een dataset die de rommel van je echte gegevens weerspiegelt: lange namen, ontbrekende velden, oude records, speciale karakters.
• Een manier om de toestand opnieuw in te stellen — je moet dezelfde test twee keer kunnen uitvoeren. Als test 1 de sandboxaccount in een gewijzigde toestand achterlaat, is test 2 niet meer schoon.

Hoe ziet een stap-voor-stap integrationtest er werkelijk uit?

Dit is een workflow die goed werkt voor een FileMaker-naar-extern-systeem integration, of dat nu een ERP-connector, een webshopsync of een AI-tool als Klai is die tekst in FileMaker verwerkt:

1. Schrijf eerst het contract op. Voordat je iets test, documenteer precies welke velden erin gaan, welk format ze verwachten en wat terugkomt. Als niemand dit in één zin per veld kan aangeven, dat is je eerste bug.
2. Test authenticatie geïsoleerd. Kun je een geldig token/antwoord krijgen met een eenvoudig testoproep (Postman, curl, of een simpel FileMaker-script met Insert from URL) voordat enige bedrijfslogica draait?
3. Stuur handmatig één schoon record door en verifieer het end-to-end — niet alleen "het script is zonder fout uitgevoerd," maar open het doelsysteem en bevestig dat de gegevens correct zijn aangekomen, in het juiste veld, met de juiste opmaak.
4. Voer opzettelijk slechte gegevens in. Een order zonder e-mailadres. Een product met een prijs van 0. Een klantnaam die 300 tekens lang is. Kijk wat er gebeurt — faalt het duidelijk (goed) of geruisloos (slecht)?
5. Simuleer een verbroken verbinding. Schakel wifi halverwege de sync uit, of wijs de oproep naar een URL die een time-out heeft. Hangt het script voor altijd vast, of faalt het netjes en logt het de fout?
6. Voer een batch uit, niet alleen één record. Tien records is anders dan één. Duizend is anders dan tien. Batchtesting brengt snelheidslimieten, geheugenproblemen en prestatiesgrenzen aan het licht die single-record testing nooit zal doen.
7. Voer exact dezelfde batch een tweede keer uit. Dit is hoe je bugs bij dubbele aanmaak ontvangt — creëert het opnieuw verzenden van dezelfde order een tweede kopie downstream?
8. Controleer de logs, niet alleen het resultaat. Als drie weken later iets misgaat, kun je dan zeggen welk record is mislukt en waarom? Als de integration zijn eigen fouten niet logt, is dat een gat om voor go-live te dichten, niet erna.
9. Test het foutmeldingspad. Als een sync mislukt, vindt iemand het dan werkelijk uit? Een script dat geruisloos faalt om 2 uur 's nachts op een zondagmorgen is erger dan geen integration helemaal, omdat iedereen ervan uitgaat dat het werkt.

Hoe verschilt testen van een AI-integration?

AI-tools ingebouwd in FileMaker — bijvoorbeeld een service als Klai gebruiken om records samen te vatten, supporttickets in te delen of klantreacties op te stellen — introduceren een nieuwe categorie testcase: non-deterministische output. Dezelfde invoer kan elke keer een iets ander antwoord opleveren.

Voor AI-integrations, voeg deze tests toe aan de bovenstaande lijst:

• Voer dezelfde prompt 10 keer uit en controleer of de variatie in output acceptabel is voor je use case, of dat je strengere promptbeperkingen of outputvalidatie nodig hebt.
• Test met lege of bijna lege invoer. Wat doet de AI met een supportticket dat alleen "help" zegt?
• Test op verzonnen velden. Als de AI wordt gevraagd een klantnummer uit vrije tekst te extracten en die bestaat niet, verzint hij er een of retourneert het correct "niet gevonden"?
• Stel een timeout en fallback in en test die. AI-API-oproepen kunnen langzamer en minder voorspelbaar zijn dan een typische REST-oproep naar je ERP. Je script heeft een verstandig timeout en een gedefinieerd fallback-gedrag nodig, niet een oneindig wachten.
• Budget-test het. Voer een realistisch dagelijks volume door de sandbox en controleer de tokenkosten, zodat een runaway-loop geen verrassingsrekening oplevert.

Hoe past testen van een ingebedde vorm of UI-laag hierin?

Integrations zijn niet alleen server-naar-server. Een tool als FmBetterforms, gebruikt om moderne web-style formulieren in FileMaker weer te geven, is ook een integrationpunt — tussen je FileMaker-layoutlogica en een JavaScript/webrendering-laag. Dezelfde discipline geldt:

• Test het formulier met de developer tools van een browser open om stille JavaScript-fouten te vangen die FileMaker zelf niet rapporteert.
• Test op de daadwerkelijke apparaten en browsers die je gebruikers hebben (een formulier dat perfect in FileMaker Pro op een Mac wordt weergegeven, kan anders zich gedragen in WebDirect op een tablet).
• Test wat er gebeurt als een gebruiker het formulier snel twee keer verstuurt, of halverwege het versturen teruggaat.
• Test met een trage netwerkverbinding, niet alleen je snelle kantoor-wifi — dit is vaak waar deze UI-integrations stil mislukken in het veld.

Wat moet een integrationtestchecklist bevatten voordat go-live?

Gebruik dit als definitieve poort voordat enige integration live gaat:

• Happy path getest end-to-end met realistische gegevens
• Slechte/misvormde invoer getest en faalt veilig, met duidelijk foutbericht
• Batchvolume getest op realistisch en piekvolume
• Dubbele aflevering/herhaald testen
• Authenticatieverlopen getest (wat gebeurt er de dag dat het token sterft?)
• Downtime van downstream gesimuleerd
• Fouten worden ergens geregistreerd waar een mens ze echt ziet
• Iemand wordt automatisch op de hoogte gesteld als een sync mislukt
• Rollback- of afstemproces bestaat voor als dingen toch misgaan
• Documentatie bestaat zodat een ontwikkelaar die het niet heeft gebouwd, het kan debuggen

Veelgestelde vragen

Hoeveel tijd moeten we budgetteren voor integrationtesting? Als vuistregel: plan in dat testen even lang duurt als het bouwen van de integration. Integrations die snel voelen om te bouwen zijn meestal degene waar testen wordt overgeslagen, en ze zijn niet evenredig degene die in productie mislukken.

Kunnen we een sandboxomgeving overslaan als de API die niet biedt? Nee — als de leverancier geen sandbox heeft, bouw je eigen veilighetsnet: een duplicate-account, een beperkte testdataset, of een handmatige goedkeuringsstap voordat testgegevens echte klanten of echte facturen bereiken.

Wie zou integrationtesting moeten verantwoorden — de ontwikkelaar of de zakengebruiker? Beiden. De ontwikkelaar verifiëert dat het technische contract werkt; de zakengebruiker verifiëert dat het resultaat werkelijk in context zin heeft (de juiste klant, het juiste bedrag, de juiste status). Een test die alleen controleert "geen fout werd geworpen" mist businesslogicafouten.

Wat is de meest voorkomende integrationbug die je in de praktijk ziet? Geruisloze gedeeltelijke mislukking — de integration rapporteert succes, maar heeft slechts een deel van de batch verwerkt, of heeft het met iets verkeerde gegevens verwerkt. Luide, duidelijke mislukking wordt snel opgelost. Stille, half-juiste die doet maanden lang schade voordat iemand het merkt.

Een goed geteste integration is geen eenmalig projectmijlpaal — het is onderdeel van het behoud van een aangepast systeem dat betrouwbaar en onderhoudbaar is voor de jaren daarna, en daarom hoort testdiscipline in hetzelfde gesprek als documentatie en overdraagbaarheid. Als je een FileMaker-integration, ERP-connector, AI-workflow of aangepaste API-brug bouwt of auditeert en wilt een second opinion over het testplan voordat het live gaat, kan Loggix helpen de juiste aanpak uit te stippelen — van een gericht technisch review tot hands-on development van de connector zelf.