Frontend testing tips

Questo articolo ha come obiettivo conoscere ed approfondire con alcuni casi concreti riscontrati nello sviluppo quotidiano il testing funzionale di applicazioni Angular 2 eseguito tramite Protractor.

Il test funzionale detto anche E2E (end to end) consiste nel verificare la funzionalità completa di un’applicazione. Al contrario di quello unitario che si prefigge il test di funzionalità atomiche, il test E2E ha come obiettivo verificare che tutte funzionalità lavorino correttamente assieme.

Lo strumento principale utilizzato con Angular è Protractor, un framework di test E2E che viene integrato in applicazioni generate con Angular cli.

Continua a leggere

Testare angular

Le modifiche da applicare ad un progetto standard per avere più controllo sull’esecuzione dei test unitari tramite karma.

Per chi sviluppa frontend, le questioni relative al testing sono spesso “meno lineari” rispetto al classico approccio TDD dello sviluppo backend. Chi ha avuto occasione di lavorare in angular 2 avrà sicuramente potuto apprezzare angular CLI e gli strumenti che mette a disposizione, soprattutto per il testing.

Nello sviluppo quotidiano ho riscontrato che “ng test”, il comando che ci permette di eseguire test unitari tramite karma, non fornisce la possibilità di scegliere quali test eseguire, cosa che al crescere del numero dei test rallenta considerevolmente l’esecuzione, soprattutto in modalità “watch” rendendo così quasi impossibile un approccio TDD.

Infatti, ci capita spesso di lavorare su progetti frontend molto complessi per i nostri clienti e, nonostante questo tipo di problema, al contempo vogliamo mantenere alti i livelli qualitativi, anche con tecniche come appunto il TDD.

Per ovviare al problema ho perciò applicato le seguenti modifiche al mio progetto angular per avere la possibilità di lanciare e tenere in modalità watch solo i test che mi interessano durante lo sviluppo.

Continua a leggere

In questo articolo tratto un argomento che mi sta molto a cuore che è anche uno di quelli più contro intuitivi, soprattutto nell’ambito del digitale e nella gestione appunto di piattaforme e prodotti digitali.

Un concetto che infatti ripeto spesso è che la tecnologia è tutto sommato facile, se la raffrontiamo al vero problema che è invece quello delle persone.

Inteso come: gestire gli aspetti tecnologici di una piattaforma digitale è il problema minore rispetto a quello di gestire le persone che lo fanno funzionare.

A dispetto di quello che pensano molti non addetti ai lavori, un prodotto digitale non sta in piedi da solo ed è necessario farlo evolvere e correggerlo continuamente.

Continua a leggere

Hai mai la sensazione che gestire lo sviluppo e la manutenzione del tuo prodotto digitale svolte dal tuo team (interno o esterno) sia come cercare di spegnere un palazzo in fiamme?

Mi riferisco al fatto che definire le priorità degli sviluppi, delle attività di supporto, degli incidenti e di tutte le altre operazioni digitali è un vero e proprio inferno dove si risolve una cosa e se ne rompe un’altra, si litiga continuamente nel definire delle scadenze che molto frequentemente non vengono rispettate e lo spazio per migliorare la situazione si fa sempre più ristretto.

E questo avviene in modo paradossale: più si cerca di pianificare le attività in modo esatto, tentando di mettere a punto anche il più piccolo dei dettagli, facendosi dare stime più precise possibili dagli sviluppatori e dagli altri specialisti, allineandosi il più frequentemente possibile con il team, più la situazione si aggrava invece di migliorare.

Continua a leggere

Come tutti sappiamo PHP è stato concepito come linguaggio a tipizzazione dinamica: visto da una parte dello scenario come pro, dall’altra come contro.

Nonostante l’esistenza di diversi linguaggi con tale caratteristica quest’ultima è stata per diverso tempo motivo di critica. E’ chiaro che lo sviluppo con certi linguaggi aiuta a scrivere codice più pulito, ma di certo è difficile affermare che la tipizzazione dinamica sfoci in codice spazzatura.

Così come le critiche a PHP spesso sono incomplete o riferite a codice deprecato, così accade per la tipizzazione; per esempio PHP ha e ha avuto per diverso tempo diverse modalità per trattare con i tipi ed è possibile garantire che uno specifico tipo venga utilizzato in uno specifico punto del codice.

Anche il type hinting è stato utilizzato per molto tempo, anche se in modo incompleto.

Con PHP7 sarà possibile far sì che le funzioni e i metodi accettino parametri di determinati tipi.

Andiamo più nello specifico: i principali RFC del nuovo PHP7 sono fondamentalmente tre:

  1. Type hinting scalare;
  2. Dichiarazione di tipi di ritorno;
  3. Gestione delle eccezioni.

Continua a leggere