La maggior parte delle applicazioni mobile hanno in qualche modo a che fare con delle API esterne. In alcuni casi proprio le API costituiscono il cuore dell’applicazione: recuperare dei dati in json, visualizzarli e processarli in qualche modo… non è forse questo lo scopo della maggior parte delle app?

Anche se tutti abbiamo ormai imparato a interagire con le API usando librerie come AFNetworking, o più semplicemente tramite alcune NSURLRequest, il networking resta una parte molto fragile dell’architettura, se non altro perché coinvolge due parti separate: la nostra app e il backend che fornisce i dati. Può essere quindi interessante cercare di capire come riuscire a testare efficacemente questa parte del programma e come riuscire a lavorare serenamente anche quando il server non è raggiungibile o le API non sono ancora state sviluppate.

Unit test e http calls

Provando a ragionare sul primo punto, l’argomento è piuttosto spinoso e le battaglie in rete sono più aspre delle battaglie di religione in medio oriente. L’unico punto che vede tutti d’accordo è *mai* interagire con la rete durante i test. La ragione è semplice: abbiamo definito un contratto con il backend sulla struttura del json , http status codes etc e quello che vogliamo testare è che la nostra app si comporti correttamente quando il contratto è rispettato. Interagire direttamente con la rete significa testare contemporaneamente due parti del sistema, testare la nostra app e testare che il backend stia rispettando il contratto. Testare due componenti del sistema è chiamato “integration test” ed è ben diverso dai test che scriviamo all’interno della nostra app, quindi il concetto è chiaro:

mai utilizzare la rete durante i test 🙂

Effettuare i test, senza l’utilizzo della rete è possibile e le tecniche posso essere le più diverse, io per esempio preferisco lasciare pochissima (praticamente nessuna) logica all’interno della classe che si occupa del networking spostando tutto in classi esterne, in questo modo la classe che effettua le chiamate http non è altro che un insieme di chiamate a NSUrlRequest / AFNetworking e nulla più, e può essere tranquillamente sostituita durante i test con una classe che recupera i json dal filesystem piuttosto che dalla rete.

Questo approccio ha per me un grande vantaggio, infatti poiché in azienda viene dato molto peso ai test manuali, abbiamo un particolare target che utilizza questa mock class, e tramite settings il tester può in autonomia modificare alcuni parametri e verificare il comportamento dell’app in caso di assenza di rete, limitata connettività o generici errori di rete (http 500) tutto questo prima ancora che il backend sia effettivamente pronto.

Se invece non avete voglia di sbattervi nel creare classi separate solo per i test, potete utilizzare una libreria che permetta di mock-are (sorry per il termine) le richieste http, come per esempio Nocilla (https://github.com/luisobo/Nocilla) oppure WebMock (https://github.com/bblimke/webmock) o ancora OHHTTPStubs (https://github.com/AliSoftware/OHHTTPStubs).

Il vantaggio dell’utilizzare una libreria come quelle proposte è che la libreria opera ad un livello molto basso, per cui una volta correttamente “abilitata”, tutto il resto dell’applicazione può restare immutato. Le chiamate http verranno semplicemente intercettate e le specifiche “finte” risposte verranno portate al livello superiore.

Mock api

Quando lo sviluppo dell’applicazione iOS inizia contemporaneamente (se non prima) dello sviluppo del backend bisogna in qualche modo invenarsi un sistema per simulare le API. Qualcuno potrebbe dire: “ma se abbiamo usato un OHHTTPStubs abbiamo già le nostre mock api” e in effetti è parzialmente vero.. ma è anche vero che il vostro compagno di banco sta sviluppando la versione android, e magari volete avere anche un po’ di dati in più per provare sul campo l’applicazione.. quindi vediamo quali sono le possibilità per creare una API finta.

La decisione principale è se voler realizzare qualcosa con le nostre manine oppure usare un tool già pronto all’uso. Inutile dire che il primo approccio è anche il più soddisfacente e il più versatile, quindi soprattutto se vi piace sporcarvi le mani.. go ahead! Il mio personale approccio in genere passa attraverso una semplice applicazione ruby deployata su heroku. È sorprendente notare come possa essere semplice generare un mock server con ruby e una libreria come Sinatra o Grape.

Giusto per fare un esempio  questo è tutto il codice necessario per restituire un json quando interrogate:

example.com/v1/countries

get '/v1/countries' do
  content_type :json
  {data: [country_1(), country_2()]}.to_json
end

Registratevi su Heroku se non l’avete mai fatto, prendete un template di applicazione Sinatra (per esempio questo https://github.com/sinatra/heroku-sinatra-app) e in 10 minuti avrete le vostre mock api.

Benefits: il piacere di aver fatto tutto da soli e la possibilità di avere anche quel pizzico di logica in più all’interno delle API che non guasta mai. Per esempio alcune API restituiscono sempre la data corrente, cosa impossibile con altri servizi di mock.

Contro: Se dite in giro che avete deployato un’applicazione per fare da mock server vi prenderanno per pazzo perché sembra un lavoro enorme e complicato, mentre invece richiede 10 minuti 🙂

Cosa usare invece se non volete sporcarvi le mani? In questo caso mi sento di suggerire due prodotti diversi, il primo è mockbin (http://mockbin.org/) realizzato dagli stessi ragazzi italiani di mashape, free e open source, ha diverse funzionalità avanzate e se state cercando una soluzione facile e veloce per mockare una API è assolutamente perfetto. Cosa volete di più? 🙂

Il secondo tool è invece parzialmente a pagamento e si chiama apiary (http://apiary.io). Questo tool ha uno scopo molto più ampio, ed è anche difficile da descrivere 😛 In pratica basta scrivere la documentazione in un formato simil-markdown, aggiungendo anche esempi di risposta, e apiary si preoccupa di generare la documentazione, le mock api, generare snippet di codice per interagire con quella API e decine di altre cose 🙂

Non vi resta che provare e lasciare i vostri commenti sotto l’articolo!

Alla prossima!