Nei giorni scorsi è stata rilasciata la versione 11 di Angular che porta con sé una ventata di novità! Che novità ci sono in questa release? Una delle “pecche” più grandi del team Angular, era il fatto di non avere una roadmap pubblica e che, per molto tempo, le PR aperte su GitHub non venivano gestite e/o “considerate” dal team ufficiale. Operation Byelog Che cos’è l’Operation Byelog? Quando il team Angular ha deciso di condividere…
Come rilasciare un’applicazione Angular su AWS utilizzando un’architettura serverless
Come creare un’applicazione Angular Universal con supporto multilingua i18n
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.
Oggi, le applicazioni web che utilizziamo quotidianamente sono state sviluppate utilizzando framework e tecnologie che permettono agli sviluppatori di essere efficienti e veloci.
Al contrario, sviluppare applicazioni desktop rimane piuttosto complicato e macchinoso.
Per sviluppare applicazioni desktop, infatti, non c’è un unico stack tecnologico a cui fare riferimento: sono diffusi decine di linguaggi di programmazione (Java, C++, Python, …) e decine di framework e librerie per la costruzione di interfacce grafiche (Qt, Gtk, Swing, JavaFX, …).
Spesso queste librerie, poi, possono essere anche molto complesse da utilizzare (come faccio un layout fluido?), hanno scarsa documentazione e pochi esempi di codice…. Senza considerare che alcune non sono nemmeno cross-platform!
Perchè sviluppare applicazioni desktop deve essere così complicato? Come sarebbe se potessimo, in qualche modo, utilizzare le tecnologie web per creare app desktop con la stessa facilità?
Amazon Web Services offre un ottimo e conosciutissimo servizio per lo storage di file chiamato S3 (Simple Storage Service) che in Innoteam apprezziamo particolarmente per la sua semplicità, robustezza e per il suo pricing particolarmente conveniente.
In questo articolo vedremo come interfacciare una Web App con il servizio S3 di Amazon per effettuare upload e download di file in maniera sicura ed efficiente.
Il punto di forza dell’approccio descritto è che upload e download vengono effettuati direttamente verso il bucket S3 senza necessità di dover appoggiare i file su server intermediari.
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.
Una prassi comune lavorando nel mondo server-side è definire diversi ambienti di esecuzione e di deploy per le proprie applicazioni. Solitamente troviamo almeno un ambiente dedicato allo sviluppo ed un altro che rappresenta l’ambiente di produzione. I vari ambienti si differenziano utilizzando diversi valori per parametri comuni quali le credenziali di accesso al database, l’attivazione degli strumenti di log, il modello di autenticazione, ecc.
Uno dei primi ostacoli che si incontrano lavorando con un framework client-side come AngularJS è quello di trovare un meccanismo per poter differenziare l’ambiente di esecuzione della propria applicazione senza poter contare sugli strumenti abituali disponibili lato server.
In questo articolo mostreremo una possibile soluzione realizzata collaborando assieme a PhotoSì e Fabio Masini basata sulla riscrittura dei nostri file sorgenti tramite task Grunt che valorizza determinate variabili JavaScript a seconda che si voglia eseguire la nostra applicazione in un ambiente di sviluppo o in un ambiente test.
In particolare vedremo come utilizzare diversi endpoint REST a seconda dell’ambiente di esecuzione che vogliamo utilizzare.
