Come può il consumatore scrivere un test del provider senza alcuna conoscenza dell'implementazione?

Question

Come può il consumatore scrivere un test del provider senza alcuna conoscenza dell'implementazione?

#1 da (2 voti)
#2 da (-2 voti)

-2

Ho letto di test sui contratti guidati dai consumatori con framework come Pact. I concetti sono chiari quando si parla di test tra due servizi che la comunicazione tramite HTTP.

Abbiamo il servizio A (il nostro consumatore):

Scrivi un test che indica quando POST {'foo': 'bar'} al servizio B, il servizio B risponde con un 201.
Condividi il contratto con il servizio B.

Abbiamo anche il servizio B (il nostro fornitore):

Utilizzando il contratto fornito dal Servizio A, riesegui la richiesta contro il Servizio B. Se il Servizio B non risponde con un 201 (probabilmente a causa del Service B che implementa una modifica anomala), il test fallisce.

Ora immaginiamo di avere un'architettura in cui il servizio A invia lo stesso messaggio {'foo': 'bar'} su una coda di messaggi per essere elaborato dal servizio B. Come verifichiamo il contratto? Il servizio B non risponde al servizio A, quindi non possiamo testare una risposta. Certamente non vorremmo testare gli effetti collaterali del Servizio B, in quanto il Servizio A non è a conoscenza dell'implementazione del Servizio B (e quindi non può scrivere un contratto guidato dal consumatore).

Forse in questo scenario, le responsabilità sono invertite; Il servizio A è il fornitore e il servizio B è il consumatore. Anche in questo caso, come può il consumatore scrivere un test del provider senza alcuna conoscenza dell'implementazione? Non c'è nessuna risposta da confrontare con

api contract

posta jaggermoves 20.11.2017 - 02:57

fonte

2 risposte

Leggi altre domande sui tag api contract

Trova il sottoinsieme più grande in cui due elementi condividono una proprietà Carica file su S3 o salvalo localmente?

score 2 · Answer 1

Per verificare il contratto, devi prima sapere qual è il contratto. Da quanto hai descritto nella domanda, il contratto è "inviamo questo messaggio". Se non hai conoscenze o aspettative su ciò che B fa con questo, allora non c'è nulla da verificare. Se il servizio A alla fine si basa su qualche effetto che il messaggio aveva in B, allora puoi provare che quell'effetto abbia avuto luogo. In caso contrario, B è un sink silenzioso e A non può (e non dovrebbe) testare nulla al riguardo.

L'unica cosa che devi testare è che il messaggio che generi è effettivamente accettato da B. Per questo, hai bisogno di un modo per B di riportare errori, o scrivi un test in cui sostituisci B con qualcosa che tu sapere accetta gli stessi messaggi.

score -2 · Answer 2

Utilizza il modello di individuazione del servizio sul lato client:

Thenetworklocationofaserviceinstanceisregisteredwiththeserviceregistrywhenitstartsup.Itisremovedfromtheserviceregistrywhentheinstanceterminates.Theserviceinstance’sregistrationistypicallyrefreshedperiodicallyusingaheartbeatmechanism.
NetflixOSSprovidesagreatexampleoftheclient‑sidediscoverypattern.NetflixEurekaisaserviceregistry.ItprovidesaRESTAPIformanagingservice‑instanceregistrationandforqueryingavailableinstances.NetflixRibbonisanIPCclientthatworkswithEurekatoloadbalancerequestsacrosstheavailableserviceinstances.WewilldiscussEurekainmoredepthlaterinthisarticle.
Theclient‑sidediscoverypatternhasavarietyofbenefitsanddrawbacks.Thispatternisrelativelystraightforwardand,exceptfortheserviceregistry,therearenoothermovingparts.Also,sincetheclientknowsabouttheavailableservicesinstances,itcanmakeintelligent,application‑specificload‑balancingdecisionssuchasusinghashingconsistently.Onesignificantdrawbackofthispatternisthatitcouplestheclientwiththeserviceregistry.Youmustimplementclient‑sideservicediscoverylogicforeachprogramminglanguageandframeworkusedbyyourserviceclients.

Unavoltascopertoilservizio,puoiscoprirel'APIseutilizzaunostandardnotocomeGraphQL:

GraphQLisintrospective.ThismeansyoucanqueryaGraphQLschemafordetailsaboutitself.
Query__schematolistalltypesdefinedintheschemaandgetdetailsabouteach:

queryLearnAboutSchema{__schema{types{namekind}queryType{fields{namedescription}}}}

ounmetododiindividuazioneautomaticasuunURLcomeWordpress:

Toutilizetheauto-discoveryfunctionality,callWPAPI.discover()withaURLwithinaWordPressRESTAPI-enabledsite:
varapiPromise=WPAPI.discover('http://my-site.com' );

o metadati di scoperta come MediaWiki:

Since r75621, we have RSD discovery for the endpoint: look for the link rel="EditURI" in the HTML source of any page and extract the api.php URL; the actual link contains additional info.

Riferimenti