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 \u00e8 forse questo lo scopo della maggior parte delle app?<\/p>\n
Anche se tutti abbiamo ormai imparato a interagire con le API usando librerie come AFNetworking, o pi\u00f9 semplicemente tramite alcune NSURLRequest,\u00a0il networking resta una parte molto fragile dell’architettura, se non altro perch\u00e9 coinvolge due parti separate: la nostra app e il backend che fornisce i dati. Pu\u00f2 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 \u00e8 raggiungibile o le API non sono ancora state sviluppate.<\/p>\n
Provando a ragionare sul primo punto, l’argomento \u00e8 piuttosto spinoso e le battaglie in rete sono pi\u00f9 aspre delle battaglie di religione in medio oriente. L’unico punto che vede tutti d’accordo \u00e8 *mai* interagire con la rete durante i test. La ragione \u00e8 semplice: abbiamo definito un contratto con il backend sulla struttura del json , http status codes etc e quello che vogliamo testare \u00e8 che la nostra app si comporti correttamente quando il contratto \u00e8 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 \u00e8 chiamato “integration test<\/strong>” ed \u00e8 ben diverso dai test che scriviamo all’interno della nostra app, quindi il concetto \u00e8 chiaro:<\/p>\n mai utilizzare la rete durante i test<\/strong> \ud83d\ude42<\/p>\n Effettuare i test, senza l’utilizzo della rete \u00e8 possibile e le tecniche posso essere le pi\u00f9 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 \u00e8 altro che un insieme di chiamate a NSUrlRequest \/ AFNetworking e nulla pi\u00f9, e pu\u00f2 essere tranquillamente sostituita durante i test con una classe che recupera i json dal filesystem piuttosto che dalla rete.<\/p>\n Questo approccio ha per me un grande vantaggio, infatti poich\u00e9 in azienda viene dato molto peso ai test manuali, abbiamo un particolare target che utilizza questa mock class, e tramite settings il tester pu\u00f2 in autonomia modificare alcuni parametri e\u00a0verificare il comportamento dell’app in caso di assenza di rete, limitata connettivit\u00e0 o generici errori di rete (http 500) tutto questo prima ancora che il backend sia effettivamente pronto.<\/p>\n 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<\/strong> (https:\/\/github.com\/luisobo\/Nocilla<\/a>) oppure WebMock<\/strong> (https:\/\/github.com\/bblimke\/webmock<\/a>) o ancora OHHTTPStubs<\/strong> (https:\/\/github.com\/AliSoftware\/OHHTTPStubs<\/a>).<\/p>\n Il vantaggio dell’utilizzare una libreria come quelle proposte \u00e8 che la libreria opera ad un livello molto basso, per cui una volta correttamente “abilitata”, tutto il resto dell’applicazione pu\u00f2 restare immutato. Le chiamate http verranno semplicemente intercettate e le specifiche “finte” risposte verranno portate al livello superiore.<\/p>\n 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<\/strong>. Qualcuno potrebbe dire: “ma se abbiamo usato un OHHTTPStubs abbiamo gi\u00e0 le nostre mock api” e in effetti \u00e8 parzialmente vero.. ma \u00e8 anche vero che il vostro compagno di banco sta sviluppando la versione android, e magari volete avere anche un po’ di dati in pi\u00f9 per provare sul campo l’applicazione.. quindi vediamo quali sono le possibilit\u00e0 per creare una API finta.<\/p>\n La decisione principale \u00e8 se voler realizzare qualcosa con le nostre manine oppure usare un tool gi\u00e0 pronto all’uso. Inutile dire che il primo approccio \u00e8 anche il pi\u00f9 soddisfacente e il pi\u00f9 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. \u00c8 sorprendente notare come possa essere semplice generare un mock server con ruby e una libreria come Sinatra o Grape.<\/p>\n Giusto per fare un esempio\u00a0 questo \u00e8 tutto il codice necessario per restituire un json quando interrogate:<\/p>\n Registratevi su Heroku se non l’avete mai fatto,\u00a0prendete un template di applicazione Sinatra (per esempio questo https:\/\/github.com\/sinatra\/heroku-sinatra-app<\/a>) e in 10 minuti avrete le vostre mock api.<\/p>\n Benefits<\/strong>: il piacere di aver fatto tutto da soli e la possibilit\u00e0 di avere anche quel pizzico di logica in pi\u00f9 all’interno delle API che non guasta mai. Per esempio alcune API restituiscono sempre la data corrente, cosa impossibile con altri servizi di mock.<\/p>\n Contro:<\/strong> Se dite in giro che avete deployato un’applicazione per fare da mock server vi prenderanno per pazzo perch\u00e9 sembra un lavoro enorme e complicato, mentre invece richiede 10 minuti \ud83d\ude42<\/p>\n Cosa usare invece se non volete sporcarvi le mani? In questo caso mi sento di suggerire due prodotti diversi, il primo \u00e8 mockbin<\/strong> (http:\/\/mockbin.org\/<\/a>) realizzato dagli stessi ragazzi italiani di mashape, free e open source, ha diverse funzionalit\u00e0 avanzate e se state cercando una soluzione facile e veloce per mockare una API \u00e8 assolutamente perfetto. Cosa volete di pi\u00f9? \ud83d\ude42<\/p>\nMock api<\/h3>\n
example.com\/v1\/countries<\/pre>\n
get '\/v1\/countries' do\r\n content_type :json\r\n {data: [country_1(), country_2()]}.to_json\r\nend\r\n<\/pre>\n