{"id":382,"date":"2013-06-05T15:58:36","date_gmt":"2013-06-05T13:58:36","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/scrivere-javascript-testabile\/"},"modified":"2013-06-05T15:58:36","modified_gmt":"2013-06-05T13:58:36","slug":"scrivere-javascript-testabile","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/scrivere-javascript-testabile\/","title":{"rendered":"Scrivere JavaScript testabile"},"content":{"rendered":"
\n

Ci siamo passati tutti: quel pezzo di codice JavaScript che era cominciato come una manciata di righe cresce fino ad una dozzina, poi a due dozzine e cos\u00ec via. Durante l’avanzamento, una funzione assume qualche altro argomento, ad un conditional vengono aggiunte altre condizioni. E poi un giorno, arriva il bug report: qualcosa non funziona e tocca a noi sbrogliare la matassa.<\/p>\n

Chiedendo al nostro codice client side di assumersi sempre maggiori responsabilit\u00e0 – seriamente, al giorno d’oggi intere applicazioni vivono per lo pi\u00f9 nel browser – due cose appaiono chiare: una, non possiamo solo cliccare per tutta l’applicazione per testare che le cose funzionino come ci aspettiamo, i test automatici sono cruciali per avere fiducia nel nostro codice; due, probabilmente dovremo cambiare il modo in cui scriviamo il nostro codice per rendere possibile la stesura di test.<\/p>\n

Abbiamo davvero bisogno di cambiare il modo in cui programmiamo? S\u00ec, perch\u00e9 anche se sappiamo che i test automatici sono una buona cosa, la maggior parte di noi probabilmente \u00e8 solo in grado di scrivere degli “integration test”. Questi ultimi sono preziosi perch\u00e9 si focalizzano sul modo in cui i pezzi di un’applicazione funzionano insieme, ma quello che non fanno \u00e8 dirci se una singola unit\u00e0 di funzionalit\u00e0<\/em> si sta comportando come dovrebbe.<\/p>\n

Qui \u00e8 dove entrano in gioco gli “unit test” e faremo davvero fatica a scrivere degli unit test<\/em> finch\u00e9 non cominceremo a scrivere JavaScript testabile<\/em>.<\/p>\n<\/div>\n

\n

Unit vs. integration: qual \u00e8 la differenza?<\/h2>\n

Scrivere degli integration test solitamente \u00e8 piuttosto facile: scriviamo semplicemente del codice che descrive il modo in cui un utente interagisce con la nostra app e cosa dovrebbe aspettarsi di vedere l’utente durante tale interazione. Selenium<\/a> \u00e8 un tool popolare per automatizzare i browser. Capybara<\/a> per Ruby rende semplice parlare a Selenium e ci sono molti altri tool anche per altri linguaggi.<\/p>\n

Ecco un integration test per una porzione di una app di ricerca:<\/p>\n

def test_search\n  fill_in('q', :with => 'cat')\n  find('.btn').click\n  assert( find('#results li').has_content?('cat'), 'Search results are shown' )\n  assert( page.has_no_selector?('#results li.no-results'), 'No results is not shown' )\nend<\/code><\/pre>\n
Laddove un integration test \u00e8 interessato all’interazione dell’utente con una app, uno unit test \u00e8 strettamente interessato a una piccola porzione del codice:<\/p>\n
\n
Quando richiamo una funzione con un certo input, ricevo l’output atteso?<\/p>\n<\/blockquote>\n
Le app scritte nel tradizionale stile procedurale possono essere molto difficili da testare con lo unit test – e anche difficili da mantenere, debuggare ed estendere. Ma se scriviamo il codice con in mente le necessit\u00e0 del nostro futuro unit test, non solo troveremo che scrivere i test diventa pi\u00f9 semplice di quello che ci aspetteremmo, ma anche che chiaramente scriveremo del codice migliore<\/em>.<\/p>\n
Per capire di cosa sto parlando, diamo un’occhiata a una semplice app di ricerca:<\/p>\n
\"Srchr\"<\/div>\n
Quando un utente inserisce un termine di ricerca, la app manda una XHR al server per i dati corrispondenti. Quando il server risponde con i dati, formattati come JSON, l’app prende quei dati e li mostra sulla pagina, usando un templating client side. Un utente pu\u00f2 cliccare su un risultato di ricerca per indicare che gli piace (un “like”): quando questo avviene, il nome della persona a cui ha dato il “like” viene aggiunta alla lista dei “Liked” sulla destra.<\/p>\n
Un’implementazione JavaScript “tradizionale” di questa app potrebbe essere la seguente:<\/p>\n
var tmplCache = {};\n\nfunction loadTemplate (name) {\n  if (!tmplCache[name]) {\n    tmplCache[name] = $.get('\/templates\/' + name);\n  }\n  return tmplCache[name];\n}\n\n$(function () {\n\n  var resultsList = $('#results');\n  var liked = $('#liked');\n  var pending = false;\n\n  $('#searchForm').on('submit', function (e) {\n    e.preventDefault();\n\n    if (pending) { return; }\n\n    var form = $(this);\n    var query = $.trim( form.find('input[name=\"q\"]').val() );\n\n    if (!query) { return; }\n\n    pending = true;\n\n    $.ajax('\/data\/search.json', {\n      data : { q: query },\n      dataType : 'json',\n      success : function (data) {\n        loadTemplate('people-detailed.tmpl').then(function (t) {\n          var tmpl = _.template(t);\n          resultsList.html( tmpl({ people : data.results }) );\n          pending = false;\n        });\n      }\n    });\n\n    $('<li>', {\n      'class' : 'pending',\n      html : 'Searching &hellip;'\n    }).appendTo( resultsList.empty() );\n  });\n\n  resultsList.on('click', '.like', function (e) {\n    e.preventDefault();\n    var name = $(this).closest('li').find('h2').text();\n    liked.find('.no-results').remove();\n    $('<li>', { text: name }).appendTo(liked);\n  });\n\n});<\/code><\/pre>\n
Il mio amico Adam Sontag<\/a> la chiama codice Choose Your Own Adventure (“scegli la tua avventura”)<\/cite>: su ogni riga potremmo aver a che fare con la presentazione, con i dati, con l’interazione utente o con lo stato dell’applicazione. Chi pu\u00f2 dirlo? \u00c8 abbastanza facile scrivere dei test degli integration test per questo tipo di codice, ma \u00e8 difficile testare le singole unit\u00e0 di funzionalit\u00e0<\/em>.<\/p>\n
Cosa lo rende difficile? Quattro cose:<\/p>\n