Articoli Tecnici

Archivio per categoria Articoli Tecnici

Test automatici per interfacce web

I test sull’interfaccia grafica sono il sistema più semplice e diffuso di testare un applicativo. Anche nei processi di sviluppo rudimentali dove non si fa testing in maniera esplicita, qualcuno prima o poi aprirà l’interfaccia grafica (magari un sito web…) e farà delle prove. Se prendiamo in considerazione processi di sviluppo realizzati con tutti i  livelli del “Test automation Pyramid” troviamo sempre in cima i test sull’interfaccia. La bella notizia è che una buona parte di questi test possono essere automatizzati. Non voglio parlare qui di cosa ha senso automatizzare e cosa no. A tutti i livelli della piramide, ogni test automatico che aggiungiamo introduciamo un costo (per la realizzazione e la manutenzione). Occorre investire il giusto tempo nei test che garantiscono il funzionamento delle parti critiche e quelli che è conveniente fare, ma questo è un tema a parte. Voglio elencare le principali alternative per l’automazione di test su interfaccia grafica. Non parlo di test end-to-end ma di una vera e propria automazione delle operazioni su browser. Quasi tutti avranno sentito parlare di Selenium: ecco, di questo stiamo parlando. Il principio è molto semplice: si registra un test effettuando un percorso di navigazione con browser, si salva in una batteria di test e si esegue, possibilmente su tutti i browser, prima di ogni pubblicazione o ad ogni compilazione se il nostro sistema di CI lo supporta. Vediamo alcune alternative open source o free. =&0=& http://www.seleniumhq.org/ Registra la navigazione tramite tool visuale, e salva il progetto in modo da poterlo editare in seguito. La test suite è esportabile e trasformabile in unit test (junit, xunit,…). A me ha funzionato solo con junit. =&1=&
  1. permette di registrare un test da registrazione browser
  2. permette di lanciare un test su tutti i browser
  3. emulando le azioni sul browser dovrebbe essere “robusto” a fronte di applicativi angular (ma non l’ho provato…)
  4. può essere integrato nel processo di build \ release come unit test
=&2=&
  1. servono n tool
  2. possiamo personalizzare gli unit test ma esportandoli di nuovo si sovrascrivono (soluzione adottata)
  3. test di validazione non basilari
  4. emulando il browser i tempi sono più lunghi rispetto alle soluzioni end-to-end
=&3=& Framework per test angular end-to-end http://www.protractortest.org/#/ =&4=&
  1. specializzato su angular
  2. veloce
=&5=&
  1. i test vanno scritti a mano
  2. limitato ad applicativi angular
=&6=& https://www.katalon.com/ IDE eclipse based per test di carico e funzionali. La parte di registrazione è molto più evoluta rispetto a selenium. Il progetto può essere lanciato da console per integrarlo nel processo di build =&7=&
  1. molto potente per la registrazione e gestione delle test suite
=&2=&
  1. il run a livello di integrazione non viene fatto a livello di unit test, quindi l’interpretazione dei risultati è limitata (es. al massimo posso avere un report via email)

Le performance dei database NoSQL

Confrontiamo le performance

Quando si parla di comparazioni è importante dire quali benchmark verranno utilizzati e in che condizioni. Questo per garantire la replicabilità dei test e l’obiettività dei risultati. In questo caso ho utilizzato lo stesso PC per entrambi gli ambienti, garantendo così la stessa potenza di calcolo. Per evitare di influire con il tuning, le comparazioni si riferiscono ai sistemi installati senza apportare modifiche alla configurazione. I due prodotti utilizzati sono MongoDB  and SQLServer Express . I test effettuati sono relativi all’intero stack, non al solo database, perché mi interessa comparare le differenze di prestazioni a livello applicativo. Sempre per evitare di influenzare i risultati, ho usato la stessa tecnologia (.Net framework 4.5, C#) e NHibernate come ORM. read more

Perché addottare un database NoSQL

In ambito tecnologio le rivoluzioni sono inevitabili. E’ impensabile credere di poter continuare a lavorare per sempre come abbiamo fatto fino ad adesso. Il cambiamento è parte del mestiere dell’informatico e va accolto a braccia aperte, senza preconcetti. Tuttavia bisogna sempre essere attenti a investire nella tecnologia giusta; perché il cambiamento deve essere in meglio. read more

Cosa sono i database NoSQL

In the last years we follow the rising of NoSQL technology and its employ in a even more extended set of application. This article aim to make an objective comparison from SQL and NO-SQL technology and try to clarify some unclear aspect to help people to choose it’s backend knowledgeably. read more

I test per lo sviluppo software

Nel paragrafo precedente è stato spiegato il meccanismo di passaggio tra gli ambienti e si è detto che la promozione del software è vincolata al superamento di test. Tali test sono suddivisi in più tipologie, per caratteristiche e scopo. Non c’è alcuna regola scritta per indicare quali test effettuare per ogni passaggio, come sempre dipende molto dal tipo di progetto, dalla sua criticità e dalla gestione dello stesso. In molti casi i test non sono formalizzati, ma ci si basa sul responso di qualcuno, quindi si rientra nel caso “User acceptance test”. Di seguito l’elenco della maggior parte di test attuabili, mentre nei paragrafi successivi saranno esaminati quelli più diffusi: read more

Il pattern “Unit of Work”

Hibernate implementa in maniera nascosta all’utilizzatore il pattern “Unit of Work”. Tale funzionalità è implicita all’interno del meccanismo di sessione e transazione che espone. In pratica è l’esposizione dell’oggetto Session di Hibernate a garantire all’utilizzatore la possibilità di aggiungere un’operazione all’interno dell’UnitOfWork e quindi a premettere la realizzazione di operazioni transazionali. L’adozione di una classe centralizzata che si interfaccia con il database non garantisce di per se l’indipendenza dal framework Hibernate, volendo gestire in transazione una serie di operazioni, in quanto dovendo esporre gli oggetti Session e Transaction, che sono propri di Hibernate, si crea una dipendenza forte dalla libreria. Per realizzare una funzionalità veramente indipendente è necessario introdurre il concetto di UnitOfWork ad un livello più alto, in modo tale che anche l’utilizzatore adotti solo concetti propri . Così facendo sarà possibile cambiare framework per l’accesso ai dati in maniera trasparente per l’applicazione. Molti framework o prodotti commerciali soddisfano questo requisito incapsulando gli oggetti tipici dell’accesso ai dati in classi propri. Questo approccio è sicuramente efficace e di facile implementazione tuttavia vincola l’applicazione a ragionare sempre seguendo le modalità stabilite all’interno di Hibernate. Per assurdo, se fosse stato proprio uno di questi principi a portare al cambio di libreria, al termine dell’operazione  il problema rimarrebbe immutato. L’approccio di implementare esplicitamente il pattern UnitOfWork risulta leggermente più complesso ma: read more