WEB05 – Code quality e test
automatizzati con JavaScript
Roberto Messora
roberto.messora@ugidotnet.org - @robymes
http://blogs.ugidotnet.org/robymes
#CDays15 – Milano 24, 25 e 26 Marzo 2015
Grazie a
Platinum
Sponsor
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
Agenda
• Qualità
• Struttura
• Strumenti
• Build
• Automazione
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
Code quality
• JavaScript 2015: abbiamo a disposizione molta potenza di fuoco per
sviluppare le nostre applicazioni, decine di framework e librerie
• Ma “La potenza è nulla senza controllo”: dobbiamo assicurarci che il
nostro codice sia di qualità
• Non presenti gli errori e le criticità più comuni insite nel linguaggio
• Si attenga a pratiche di buon design (patterns, patterns, patterns)
• Sia privo di difetti funzionali e non funzionali (unit & integration testing)
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
“Questa è struttura”
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
Struttura della soluzione JavaScript
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
Patterns
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
JavaScript design & idiom patterns
• Affidarsi sempre a pratiche di buon design anche per applicazioni di
piccola entità
• Sfruttare i pattern idiomatici più importanti di JavaScript
• Module pattern
• Scegliere e applicare un presentation pattern come base fondante
dello sviluppo della logica client
• MVC
• MVVM
• Functional Event Stream (React, Bacon, …)
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
Strumenti
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
Node.JS, Npm, Bower
• Node.JS NON è solo un ottimo web server
• Node.JS è ANCHE un ambiente di processo in cui far
girare moduli applicativi
• Npm è il package manager più diffuso in ambito sviluppo
JavaScript, permette di gestire il download e
l’installazione dei moduli applicativi Node.JS
• Bower è uno dei più utilizzati library & framework
manager, permette di gestire il download e l’installazione
delle librerie JavaScript di terze parti
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
demo
Installare gli strumenti e le librerie
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
“Cerbero, fiera crudele e diversa”
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
JSLint
• Quando si parla di JavaScript code quality JSLint è il Re dei Re
• Ideato e implementato da Duoglas Crockford forse la massima
autorità mondiale in fatto di linguaggio JavaScript
• Sostanzialmente è un sesquipedale rompiballe fondamentale
controllore della qualità del codice scritto
• Scova e segnala i più comuni errori
• Strutturazione del codice
• Verifica delle specificità del linguaggio (hoisting, …)
• Potenziali criticità legate alle Bad Parts di JavaScript
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
Jasmine BDD
• Jasmine è uno dei numerosi framework di unit testing per
JavaScript
• È fortemente orientato al BDD (Behavior Driven
Development)
• Offre un ottimo supporto al mocking e al test-double
• Permette di testare codice asincrono
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
Karma (adattamento del
termine sanscrito kārma (devanagari: कार्म),
aggettivo derivante dal sostantivo
neutro karman (devanagari: कर्मन्))
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
Karma
• Karma è un ambiente integrato di esecuzione di test
• È in grado di eseguire test dei più diffusi framework di unit testing
(Mocha, Jasmine, QUnit)
• Permette di testare il codice su tutti i browser più importanti
pilotandone l’esecuzione(compreso Phantom.JS)
• Il suo funzionamento è basato su file di configurazione json
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
demo
Unit testing
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
Build
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
Processo di build
• Il codice che scriviamo NON è lo stesso che va in produzione (vero?!?)
• Anche solo la minificazione del codice modifica il sorgente che verrà
interpretato ed eseguito dal browser rispetto alla versione scritta
dallo sviluppatore
• È necessario testare il codice di produzione esattamente come quello
di sviluppo
• Si prospetta quindi un vero e proprio processo di build che coinvolge
la minificazione e il test del codice minificato
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
Automazione
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
Automazione della build
• Il processo di build è operativamente oneroso e a bassissimo valore
aggiunto per lo sviluppatore
• È necessario trovare il modo di automatizzare l’intero processo nel
modo più semplice e ripetibile possibile
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
Gulp! Devo automatizzare :-S
• Gulp è un ambiente di esecuzione di task di processo
• È basato sul concetto di plug-in ognuno dei quali permette di
eseguire una particolare operazione (minificazione, test, rename,
copy, … ci sono letteralmente migliaia di plug-in)
• Ogni task si basa su uno stream di file (lista di file sorgente) su cui
vengono applicate le singole operazioni sequenzialmente
• Il suo funzionamento è basato su file di configurazione json
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
demo
Automatizzare il processo di build
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
Ci sarebbe anche la Page Automation…
• Se volessimo (ma proprio se volessimo) completare il processo di
verifica della qualità del codice sarebbe necessario anche testare
l’applicazione web finale
• Esistono alcuni tool che permettono di pilotare tramite scripting
replicabile le azioni da eseguire sulla pagina web e verificarne il
risultato
• Phantom.JS
• Selenium
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
Un po’ di autopromozione ;-)
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
Q&A
Tutto il materiale di questa sessione su
http://www.communitydays.it/
Lascia subito il feedback su questa sessione,
potrai essere estratto per i nostri premi!
Seguici su
Twitter @CommunityDaysIT
Facebook http://facebook.com/cdaysit
#CDays15

Code quality e test automatizzati con JavaScript

  • 1.
    WEB05 – Codequality e test automatizzati con JavaScript Roberto Messora roberto.messora@ugidotnet.org - @robymes http://blogs.ugidotnet.org/robymes
  • 2.
    #CDays15 – Milano24, 25 e 26 Marzo 2015 Grazie a Platinum Sponsor
  • 3.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014 Agenda • Qualità • Struttura • Strumenti • Build • Automazione
  • 4.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014
  • 5.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014 Code quality • JavaScript 2015: abbiamo a disposizione molta potenza di fuoco per sviluppare le nostre applicazioni, decine di framework e librerie • Ma “La potenza è nulla senza controllo”: dobbiamo assicurarci che il nostro codice sia di qualità • Non presenti gli errori e le criticità più comuni insite nel linguaggio • Si attenga a pratiche di buon design (patterns, patterns, patterns) • Sia privo di difetti funzionali e non funzionali (unit & integration testing)
  • 6.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014 “Questa è struttura”
  • 7.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014 Struttura della soluzione JavaScript
  • 8.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014 Patterns
  • 9.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014 JavaScript design & idiom patterns • Affidarsi sempre a pratiche di buon design anche per applicazioni di piccola entità • Sfruttare i pattern idiomatici più importanti di JavaScript • Module pattern • Scegliere e applicare un presentation pattern come base fondante dello sviluppo della logica client • MVC • MVVM • Functional Event Stream (React, Bacon, …)
  • 10.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014 Strumenti
  • 11.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014 Node.JS, Npm, Bower • Node.JS NON è solo un ottimo web server • Node.JS è ANCHE un ambiente di processo in cui far girare moduli applicativi • Npm è il package manager più diffuso in ambito sviluppo JavaScript, permette di gestire il download e l’installazione dei moduli applicativi Node.JS • Bower è uno dei più utilizzati library & framework manager, permette di gestire il download e l’installazione delle librerie JavaScript di terze parti
  • 12.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014 demo Installare gli strumenti e le librerie
  • 13.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014 “Cerbero, fiera crudele e diversa”
  • 14.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014 JSLint • Quando si parla di JavaScript code quality JSLint è il Re dei Re • Ideato e implementato da Duoglas Crockford forse la massima autorità mondiale in fatto di linguaggio JavaScript • Sostanzialmente è un sesquipedale rompiballe fondamentale controllore della qualità del codice scritto • Scova e segnala i più comuni errori • Strutturazione del codice • Verifica delle specificità del linguaggio (hoisting, …) • Potenziali criticità legate alle Bad Parts di JavaScript
  • 15.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014
  • 16.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014 Jasmine BDD • Jasmine è uno dei numerosi framework di unit testing per JavaScript • È fortemente orientato al BDD (Behavior Driven Development) • Offre un ottimo supporto al mocking e al test-double • Permette di testare codice asincrono
  • 17.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014 Karma (adattamento del termine sanscrito kārma (devanagari: कार्म), aggettivo derivante dal sostantivo neutro karman (devanagari: कर्मन्))
  • 18.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014 Karma • Karma è un ambiente integrato di esecuzione di test • È in grado di eseguire test dei più diffusi framework di unit testing (Mocha, Jasmine, QUnit) • Permette di testare il codice su tutti i browser più importanti pilotandone l’esecuzione(compreso Phantom.JS) • Il suo funzionamento è basato su file di configurazione json
  • 19.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014 demo Unit testing
  • 20.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014 Build
  • 21.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014 Processo di build • Il codice che scriviamo NON è lo stesso che va in produzione (vero?!?) • Anche solo la minificazione del codice modifica il sorgente che verrà interpretato ed eseguito dal browser rispetto alla versione scritta dallo sviluppatore • È necessario testare il codice di produzione esattamente come quello di sviluppo • Si prospetta quindi un vero e proprio processo di build che coinvolge la minificazione e il test del codice minificato
  • 22.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014 Automazione
  • 23.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014 Automazione della build • Il processo di build è operativamente oneroso e a bassissimo valore aggiunto per lo sviluppatore • È necessario trovare il modo di automatizzare l’intero processo nel modo più semplice e ripetibile possibile
  • 24.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014
  • 25.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014 Gulp! Devo automatizzare :-S • Gulp è un ambiente di esecuzione di task di processo • È basato sul concetto di plug-in ognuno dei quali permette di eseguire una particolare operazione (minificazione, test, rename, copy, … ci sono letteralmente migliaia di plug-in) • Ogni task si basa su uno stream di file (lista di file sorgente) su cui vengono applicate le singole operazioni sequenzialmente • Il suo funzionamento è basato su file di configurazione json
  • 26.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014 demo Automatizzare il processo di build
  • 27.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014 Ci sarebbe anche la Page Automation… • Se volessimo (ma proprio se volessimo) completare il processo di verifica della qualità del codice sarebbe necessario anche testare l’applicazione web finale • Esistono alcuni tool che permettono di pilotare tramite scripting replicabile le azioni da eseguire sulla pagina web e verificarne il risultato • Phantom.JS • Selenium
  • 28.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014 Un po’ di autopromozione ;-)
  • 29.
    #CDays14 – Milano25, 26 e 27 Febbraio 2014 Q&A Tutto il materiale di questa sessione su http://www.communitydays.it/ Lascia subito il feedback su questa sessione, potrai essere estratto per i nostri premi! Seguici su Twitter @CommunityDaysIT Facebook http://facebook.com/cdaysit #CDays15

Editor's Notes

  • #3 Slide da mostrare prima di iniziare la sessione – non rimuovere!
  • #30 Ultima slide, obbligatoria