Archivio mensile 30 July 2018

Come simulare una coda SQS Amazon per esigenze di test

Questo articolo appare per la prima volta su Medium qui

Amazon Simple Queue Service (SQS) è un servizio di accodamento dei messaggi completamente gestito da Amazon.

Se vuoi integrarlo, potresti anche verificare se funziona. SQS ha probabilmente una sandbox per testarlo, ma se non vuoi rimanere bloccato a cercarlo o non vuoi impazzire con le procedure di accesso, puoi utilizzare un servizio fittizio che funge da coda SQS* .

Perché ne abbiamo bisogno? Perché non possiamo usare un semplice Wiremock che risponda sempre “200, OK”?

Non puoi farlo perché la risposta di SQS è una risposta dinamica dipendente dalla richiesta e si basa su alcuni calcoli MD5.

 

Quello che abbiamo fatto è un’estensione di Wiremock che risponde sempre qualcosa come “200, OK”, con tutti i campi calcolati correttamente per SQS. È stato sia facile che non così facile, perché ogni compito facile non è mai un “È solo …”.

In questo caso, era più un “non è sufficiente per…” — semplicemente far ruotare un contenitore docker o aggiungere una classe al classpath semplicemente non funzionava.

Come fare, guida passo passo

Prima di tutto dobbiamo definire una classe che estenda la classe ResponseDefinitionTransformer con due metodi facili da implementare:

applyGoballyche restituisce true, significa che “tutte le richieste riceveranno questa risposta”.

getName è un metodo di cui Wiremock ha bisogno. Quindi devi implementare il vero metodo che risponde correttamente, il metodo è transform

calculateResponse fa il lavoro sporco, ed è un metodo sporco (so che potrebbe essere refactored…)

Questo metodo ottiene il corpo della richiesta, lo divide perché è un corpo simile a un URL e quindi calcola l’MD5 di tutti gli attributi, i tipi e i valori in base alla documentazione SQS.

updateLengthAndBytes è un metodo per aggiornare il calcolo MD5.

Ad essere onesti, abbiamo anche creato una classe aggiuntiva SimplifiedMessageAttribute:

Dopo questo passaggio, puoi creare un documento XML (l’implementazione di questo non è in questo post perché è ingombrante) e includere i campi calcolati (md5OfMessageBody e md5OfMessageAttributes). Per gli altri campi, requestId e messageId, abbiamo utilizzato valori hardcoded. Il risultato finale dovrebbe essere qualcosa del genere:

Successivamente, puoi costruire il tuo progetto e ottenere un jar.

Come posso integrarlo su Wiremock?

Non è così facile. Quello che ho scoperto è che devi spostare il jar nello stesso percorso del jar Wiremock e avviare il Wiremock con:

Wiremock non ha meccanismi di plugin, quindi quello che stai facendo con questo comando è:

con -cp “*” stai dicendo a Java “prendi tutti i jar in questa cartella”

… la tua classe principale è qui: com.github.tomakehurst.wiremock.standalone.WireMockServerRunner

… e utilizza questa estensione: your.package.name.SQSMock

Da questo punto in poi, puoi usarlo direttamente, creare un contenitore docker o quello che vuoi.

L’IT non è un compito facile e, dal mio punto di vista, ogni strato aggiunto per semplificare le cose è un nuovo argomento da imparare e capire.

Durante questo viaggio abbiamo imparato a conoscere SQS, wiremock, mvn, unit test e ovviamente Java. Voglio ringraziare:

• Giuseppe Gaeta (Tech Lead)
• Matteo Moci (Software Dev Engineer II)
• Camillo Quatrini (QA Evangelist)
• Tiziana Battiston (Travel Agencies Manager, proofreader)

Ref:

• SqS documentation: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-message-attributes.html
• Wiremock Extension: http://wiremock.org/docs/extending-wiremock/

* Ci sono alcune restrizioni: tale servizio non funziona per attributi non stringa.