Siamo nell’era dei microservizi e questo significa che nelle attività di sviluppo la fase di API testing è diventata essenziale.
Oggi un’applicazione, infatti, quasi certamente per operare dialoga con altre attraverso qualche forma di interfacce applicative, che siano sviluppate internamente o che facciano capo a servizi commerciali – non a caso si parla anche di API economy – di terze parti.
A complicare la fase di API testing c’è il fatto che quasi sempre una delle due parti del dialogo via API è al di fuori del nostro controllo.
Se siamo noi a offrire un servizio via API, non sappiamo come ne usufruiranno le applicazioni esterne. Se invece stiamo sfruttando un servizio online via API, non ne conosceremo il codice e ci apparirà come una scatola (quasi) nera.
Per tutto questo, è bene considerare sin da subito che la fase di API testing deve essere automatizzata e continua.
Il controllo manuale va bene ma arriva solo a garantire che l’interfaccia specifica funzioni come previsto, non certo che livello di performance garantisca quando viene messa sotto pressione. Ed è anche questo un aspetto fondamentale nelle architetture distribuite.
Il sistema di API testing va quindi studiato e messo in piedi prima dello sviluppo, come componente trasversale.
E va utilizzato con regolarità, in modo da controllare che le API siano sempre correttamente operative e performanti. Non è un compito né divertente né banale, però porta i suoi frutti a lungo termine.
A cosa fare attenzione
La logica dei microservizi e delle API si basa su un elemento concettuale fondante: tutto avviene attraverso lo scambio di parametri a cui vengono assegnati valori specifici.
Questo tra l’altro significa che le procedure di API testing non possono funzionare bene se non sono allineate alla struttura dei parametri che viene usata dalle interfacce applicative. È normale che un’API cambi nelle sue fasi di sviluppo e anche dopo, i sistemi di test devono essere sempre coerenti con il suo modello dei parametri.
Parallelamente, un API testing efficace deve “coprire” tutte le possibili combinazioni dei valori assegnati ai parametri in transito. I controlli devono riguardare sia quelli in ingresso all’interfaccia sia quelli che essa rimanda.
Il primo ambito è più semplice, anche se sempre non banale: bisogna controllare che l’API si comporti in maniera formalmente corretta anche quando i parametri che le vengono dati in pasto non lo sono.
È utile anche eseguire test preventivi “sul campo” collegando le versioni quasi definitive dell’API a qualche applicazione interna non critica.
Il controllo e la validazione dei valori assegnati ai parametri in uscita dall’API è una parte di API testing molto più impegnativa perché le possibili combinazioni e soprattutto i potenziali errori da controllare sono moltissimi.
Oltretutto questo è un elemento importante dei test continuativi perché permette di rilevare la “buona salute” dell’API durante il suo funzionamento. È una fase di test che può essere portata avanti efficacemente solo da procedure automatizzate e costanti.
Infine, c’è il punto chiave dell’ordine delle chiamate alle interfacce applicative. In molti casi un servizio basato su API funziona correttamente solo se le chiamate all’API stessa avvengono in un ordine ben preciso o comunque rispettando certe precedenze.
Non ha senso, ad esempio, richiamare la scheda di un prodotto di un ecommerce se prima non è stato creato. Anche nelle fasi di API testing bisogna tenere conto di questo aspetto ed eseguire test con le chiamate nel giusto ordine, oppure esplicitamente in un ordine diverso per verificare il comportamento del sistema.
