Teststrategi for WSBs overtagelse/sameksistens af WSRM
De nye webservicebeskeder vil over tid gradvist erstatte de gamle WSRM i takt med hver enkelt aftager bliver i stand til at modtage de nye beskeder.
Teststrategien skal sikre, at hver ny WSB udvikles med præcis samme kvalitet, og det forretningsmæssige signal til modtager gennem WSB/WSRM er ækvivalent.
A. Vi sikrer gennem design, at TRIGGER udløser fuldstændig parallelt til WSB/WSRM.
A1. Den forretningsmæssige hændelse udløser altid 2 Events, som henholdsvis trigger WSRM og WSB, med samme signal af forretningshændelsen.
B. Vi sikrer Semantik i meddelelse ved at teste forventet indhold i WSB for:
B1. Entitytype som angiver besked type, (eks . 100001 = Nuph) .
B2. Create /Update/Delete værdi.
B3. NULL_ABLE på felter.
B4. Forretnings IDs / GUID, at WSB svarer til WSRM.
B5. Ophav (ClientSystemTypeidentifier) sættes ud fra den registrerende aktør (med visse undtagelser, hvor DFDG sættes som ophav, når DFDG som afledt handling forestår en registrering (fx NUPH på aktiviteter).
C. Vi sikrer, at alle WSB bliver TRIGGET dagligt, ved at sende Trigger-Event til fast modtager, som er sat op med abonnement på både WSB og WSRM.
C.1 Det overvåges, at der hver dag kan hentes alle WSB på den (de) faste modtager-e og sikrer at EventBroker, opsætning og udveksling er intakt.
C2. Hvis man sætter abonnement på både WSRM og WSB, kan man hente WSRM og man vil kunne se i databasen at WSB er dannet. (sendt / modtaget).
D. Vi ønsker at kunne checke C på Prod og Preprod med et eksternt Endpoint, for at verificere at en WSB bliver leveret til slutbruger fra vores drift.
D.1 Denne test af Prod og Preprod bør som min. bruges til at verificere dannelsen af WSB ved release.
D.2 Anvendelse af test i Prod kræver ekstra sikkerhedsforanstaltninger.
D.3 Måske ønskeligt at man kan konfigurere til at verificere tilslutninger af nye modtagere. Verificere hele deres opsætning var komplet, og de modtog en WSB af hver type.
Der tænkes i første omgang udført følgende tests:
For hver WSB type (EntityType) testes med IntTest i det aktuelle forretningsdomæne, at der genereres et korrekt event, til at trigge WSB'en. Testen at den enkelte WSB indsættes i testen, der hvor der i forvejen testes for WSRM-beskeder. Dette er allerede lavet for de WSB'er, vi har implementeret.
I forretningsdomænet EksternKommunikation laves en IntTest, som simulerer afsendelse af alle typer af WSB'er (EntityType's), og det checkes, at WSB'en kalder korrekt til et valgt endpoint. Hvis WSB'en har flere mulige modtagere (f.eks. Jobcenter og A-kasse), så testes for alle modtagere. Dette er endnu ikke lavet.
Som en stikprøve laves en tværgående test, som tester hele scenariet end-to-end for en enkelt WSB. WSB'en AfholdtSamtale kan med fordel anvendes her. Denne sender i nogle tilfælde kun til Jobcentret og i andre tilfælde både til Jobcenteret og til A-kassen. Begge scenarier testes. Dette er endnu ikke lavet.
Forklaring af begreber:
Forretningsdomæne
Et forretningsdomæne er en komponent, som indeholder en række services. Eksempler på forretningsdomæner er f.eks.: EksternKommunikation, Borgerkommunikation, Kontaktforloeb og VisiteringOgStatus. Internt i DFDG kommunikerer forretningsdomæner med hinanden via events, som går igennem eventbrokeren RabbitMQ.
IntTest
Dette er en automatiseret test, som tester udelukkende indenfor et enkelt forretningsdomæne. Dvs. at der er ingen kommunikation via events (RabbitMQ) rundt i systemet, men det er muligt at teste for om forretningsdomænet genererer et event, og det er mulig at simulere at forretningsdomænet modtager et event og behandler det korrekt. Man kan kun kalde de services, som hører til det forretningsdomæne, som testen kører i.
Tværgående test
Dette er en automatiseret test, hvor alle forretningsdomæner og RabbitMQ kører samtidigt i hver sin container. Man kan således teste, at events kommunikeres korrekt (og behandles korrekt) mellem forretningsdomænerne via RabbitMQ. Man har også adgang til alle servicekald i DFDG.