Unit Test: Un tipo di test del software in cui vengono testate singole di un software. Lo scopo è convalidare che ogni unità del codice software funzioni come previsto. Lo Unit Testing viene eseguito durante lo sviluppo (fase di codifica) di un'applicazione da parte degli sviluppatori. Essi isolano una sezione di codice e ne verificano la correttezza.
Unità: può essere una singola funzione, metodo, procedura, modulo o oggetto. La definizione di unità è decisa team by team
Quando si scrivono i test, la corretta gestione delle dipendenze (Dependency Injection) è uno degli aspetti più rilevanti e molte volte le best practices per l’utilizzo di un Dependency injector ed una libreria di Mocking sono le stesse.
In questa presentazione si cerca di capire quando un Dependency injector rappresenta un Anti-pattern e quando invece diventa un valido strumento professionale per risparmiare tempo, ridurre gli errori, scrivere meno codice e rendere l’applicazione molto flessibile.
Tutto questo però senza sacrificare il design dei nostri oggetti e legarci in modo indissolubile ad un framework.
Unit Test: Un tipo di test del software in cui vengono testate singole di un software. Lo scopo è convalidare che ogni unità del codice software funzioni come previsto. Lo Unit Testing viene eseguito durante lo sviluppo (fase di codifica) di un'applicazione da parte degli sviluppatori. Essi isolano una sezione di codice e ne verificano la correttezza.
Unità: può essere una singola funzione, metodo, procedura, modulo o oggetto. La definizione di unità è decisa team by team
Quando si scrivono i test, la corretta gestione delle dipendenze (Dependency Injection) è uno degli aspetti più rilevanti e molte volte le best practices per l’utilizzo di un Dependency injector ed una libreria di Mocking sono le stesse.
In questa presentazione si cerca di capire quando un Dependency injector rappresenta un Anti-pattern e quando invece diventa un valido strumento professionale per risparmiare tempo, ridurre gli errori, scrivere meno codice e rendere l’applicazione molto flessibile.
Tutto questo però senza sacrificare il design dei nostri oggetti e legarci in modo indissolubile ad un framework.
Il testing delle applicazioni MVC Zend Framework è spesso visto come una sorta di stregoneria, ma tutto sommato non lo è. In questo seminario web vedremo cosa e come testare, i pattern più comuni per il testing e le possibili difficoltà che si possono incontrare. Verranno trattati inoltre alcuni elementi di base su PHPUnit in modo da fornire concetti fondamentali per l’operatività anche a chi non è esperto di testing.
Le operazioni di testing possono richiedere molto tempo e possono implicare ingenti costi per le imprese. Per questo motivo è di fondamentale importanza individuare sul mercato le migliori soluzioni disponibili, al fine di ridurre al minimo gli effort impiegati per testare le proprie applicazioni.
TestComplete di SmartBear centra appieno questi obiettivi: TestComplete, infatti, offre una piattaforma di test per creare, eseguire e mantenere in modo semplice test automatici per applicazioni software di tipo desktop, Web, mobile, e client-server, favorendo un’elevata riduzione dei tempi e dei costi dedicati alle operazioni di testing.
In questo webinar uno dei Testing Guru di Emerasoft mostra come sfruttare al meglio le potenzialità offerte dal testing automatico grazie all’utilizzo di TestComplete.
Guarda il webinar on demand: https://www.youtube.com/watch?v=N7aTTfSoREI
Sviluppo guidato dai tests in ambiente WordPress. La prima parte della frase fa aggrottare la fronte in condizioni normali: in ambiente WordPress assume un che di mistico ed irraggiungibile. Non è così.
Lo Unit Test è importante per testare gli aspetti di base di un qualsiasi applicativo PHP.
Con il framework PHPUnit noi possiamo effettuare test di unità senza problemi e senza notevoli sforzi.
I test unitari sono sempre più utilizzati per verificare la correttezza del codice che scriviamo.
Ci si trova però a volte di fronte a codice scritto in maniera poco "disaccoppiata". Questo può impedirci di sostituire a runtime dei Dependent-on Object con dei Mock Object o degli Stub. Nel talk descriverò un plugin scritto per symfony (ma utilizzabile anche in altri ambiti) che permette di sostituire delle classi a runtime ridefinendole e configurandole all'interno dei test, creando un ambiente che isola il codice da verificare.
Il talk prevederà degli esempi pratici di utilizzo dello strumento descritto.
Delphi & Dintorni Webinar - Diventa un mago del TestingMarco Breveglieri
Il Testing è una pratica sempre più preziosa e fondamentale nell'ambito dello sviluppo del software: si tratta di un passaggio fondamentale per ridurre il numero dei bug nel software e abilitare automatismi come la Continuous Integration e la Continuous Delivery. Se utilizzati in modo errato però, i test possono causare più problemi di quanti ne prevengano: è importante quindi conoscere le differenze tra le varie tipologie di test, quali sono le loro caratteristiche ideali e padroneggiarli al meglio. In questo webinar faremo luce sul Testing, chiariremo bene i concetti di Unit e Integration Test, vedremo come scriverli nel modo corretto e quali tool ci vengono in aiuto... alla fine il Testing non avrà più segreti!
Il testing delle applicazioni MVC Zend Framework è spesso visto come una sorta di stregoneria, ma tutto sommato non lo è. In questo seminario web vedremo cosa e come testare, i pattern più comuni per il testing e le possibili difficoltà che si possono incontrare. Verranno trattati inoltre alcuni elementi di base su PHPUnit in modo da fornire concetti fondamentali per l’operatività anche a chi non è esperto di testing.
Le operazioni di testing possono richiedere molto tempo e possono implicare ingenti costi per le imprese. Per questo motivo è di fondamentale importanza individuare sul mercato le migliori soluzioni disponibili, al fine di ridurre al minimo gli effort impiegati per testare le proprie applicazioni.
TestComplete di SmartBear centra appieno questi obiettivi: TestComplete, infatti, offre una piattaforma di test per creare, eseguire e mantenere in modo semplice test automatici per applicazioni software di tipo desktop, Web, mobile, e client-server, favorendo un’elevata riduzione dei tempi e dei costi dedicati alle operazioni di testing.
In questo webinar uno dei Testing Guru di Emerasoft mostra come sfruttare al meglio le potenzialità offerte dal testing automatico grazie all’utilizzo di TestComplete.
Guarda il webinar on demand: https://www.youtube.com/watch?v=N7aTTfSoREI
Sviluppo guidato dai tests in ambiente WordPress. La prima parte della frase fa aggrottare la fronte in condizioni normali: in ambiente WordPress assume un che di mistico ed irraggiungibile. Non è così.
Lo Unit Test è importante per testare gli aspetti di base di un qualsiasi applicativo PHP.
Con il framework PHPUnit noi possiamo effettuare test di unità senza problemi e senza notevoli sforzi.
I test unitari sono sempre più utilizzati per verificare la correttezza del codice che scriviamo.
Ci si trova però a volte di fronte a codice scritto in maniera poco "disaccoppiata". Questo può impedirci di sostituire a runtime dei Dependent-on Object con dei Mock Object o degli Stub. Nel talk descriverò un plugin scritto per symfony (ma utilizzabile anche in altri ambiti) che permette di sostituire delle classi a runtime ridefinendole e configurandole all'interno dei test, creando un ambiente che isola il codice da verificare.
Il talk prevederà degli esempi pratici di utilizzo dello strumento descritto.
Delphi & Dintorni Webinar - Diventa un mago del TestingMarco Breveglieri
Il Testing è una pratica sempre più preziosa e fondamentale nell'ambito dello sviluppo del software: si tratta di un passaggio fondamentale per ridurre il numero dei bug nel software e abilitare automatismi come la Continuous Integration e la Continuous Delivery. Se utilizzati in modo errato però, i test possono causare più problemi di quanti ne prevengano: è importante quindi conoscere le differenze tra le varie tipologie di test, quali sono le loro caratteristiche ideali e padroneggiarli al meglio. In questo webinar faremo luce sul Testing, chiariremo bene i concetti di Unit e Integration Test, vedremo come scriverli nel modo corretto e quali tool ci vengono in aiuto... alla fine il Testing non avrà più segreti!
Si parla tanto di DevOps e alle conferenze gli argomenti più gettonati sono build pipeline, continuous integration/delivery/deploy, deploy automation e monitoring.
Ci stiamo dimenticando qualcosa... i test! dove sono i test? perché non si parla quasi mai di test? in questo fantastico mondo DevOps come si inseriscono i test?
I test sono solo un passo della pipeline di build? se la pensassi così il titolo del mio intervento sarebbe stato "Continuous Testing in DevOps", non credete?
Test, Tools and Tips per tester e non.
Consigli su come affrontare il testing e come comportarsi con applicazioni di tipo web, con scenari e possibili soluzioni con vari tools a disposizione
DevOpsHeroes 2016 - Realizzare Continouous Integration con SQL Server e Visua...Alessandro Alpi
In questa serie di slide vedremo come creare i build step su Visual Studio Team Services sfruttando gli add-on forniti da Red Gate, come DLM Automation 2: Build.
DotNetCampus - Continuous Integration con Sql ServerAlessandro Alpi
Continuous Integration con SQL Server. Come automatizzare i processi di build e di test su database SQL Server. Come includere SQL Server nei processi di Application Lifecycle Management (Database Lifecycle Management).
La continuous integration, ovvero un insieme di pratiche di sviluppo atte a rilasciare frequentemente le modifiche al nostro codice, può essere applicata anche a SQL Server. In questa sessione andremo a descrivere come mettere sotto controllo del codice sorgente i nostri database in un'ottica di teamwork e, successivamente, a capire come automatizzare il processo di test unitario al fine di prevenire regressioni e correggere quanto prima bug.
Quando, come e perché utilizzare PowerMock. Vengono analizzati i legami tra design delle applicazioni e strumenti di test. Sono presenti esempi di codice semplice ma verosimile con i rispettivi test.
Il buon programmatore - consigli pratici per una vita feliceAndrea Dottor
Lavorando come consulente mi sono trovato spesso di fronte a problematiche (a volte banali), ma che erano la causa di gravi problemi di performance dell'appliccazione realizzata, oppure più banali, ma che rendevano il codice meno manutenibile e gestibile, specialmente lavorando in team. Vedere che nel tempo, persone/realtà diverse, commettono gli stessi errori mi ha fatto pensare a questa sessione...dove intendo elencare i problemi più comuni, che per causa di tempo o scarsa conoscenza, vengono commessi, e proporre delle soluzioni semplici da poter applicare fin da subito. (ASP.NET, ma non solo)
Presentazione della Tesi di Laurea Specialistica : STRUMENTI PER LA GENERAZIO...Boymix81
Breve presentazione del lavoro svolto per la tesi : STRUMENTI PER LA GENERAZIONE AUTOMATICA DI TEST STRUTTURALI E FUNZIONALI, scaricabile dal sito web http://boymix81.mynickname.info
The benefits of Clean Code are obvious: stable programs, better maintainability, finding bugs faster and easier upgrading of software. A lot of advices have been already written about Java clean code (first of all in Robert C. Martin book), what about Android? Are the same advices valid? Or the way we write code must be different because it's a mobile platform? Are there any best practices about resources and the other Android stuff? In this talk we'll see some practical examples of how take advantage of Java and Android framework to write clean code and keep a project manageable.
Una primissima introduzione al TDD per chi è a digiuno di test in generale e di TDD in particolare. Usa Java/Junit, ma è facimente adattabile ad altri linguaggi. 40-60 minuti.
PASS Virtual Chapter - SQL Server Continuous IntegrationAlessandro Alpi
Build automatizzate, esecuzione di unit test, creazione di un pacchetto nuget, ecco cosa serve per essere pronti con SQL Server e la continuous integration
Tech Webinar: Test e2e per AngularJS e non soloCodemotion
Luca Ferretti illustra Protractor: il framework JavaScript indispensabile alla realizzazione di completi test e2e per web app AngularJS (e non solo).
Iscriviti qui per partecipare ad altri Tech Webinar gratuiti: http://goo.gl/iW81VD
Scrivici a: training@codemotion.it
Tw: http://twitter.com/CodemotionTR
Configurare ambienti di sviluppo facilmente replicabili e distribuirli a tutto il team di sviluppo è un gioco da ragazzi, grazie a Vagrant e Puppet. Lo sa bene Daniel Londero, che in questo talk mostrerà come sfruttare al meglio Vagrant e Puppet come sistema di provisioning per ottenere in pochi minuti un ambiente di sviluppo pronto a ospitare un’installazione di Magento CE.
The document discusses building a REST API with Symfony2 by using common bundles like FOSRestBundle, JMSSerializerBundle, and NelmioApiDocBundle. It provides examples of implementing CRUD operations for a Product entity, including request and response formats. It also covers testing the API with functional tests that make HTTP requests and assert responses.
The document discusses caching data in memory (Io cache) and storing data in a database. It mentions that databases can become slow and discusses scaling and using the proper tools. It also notes tracking online users, codes, lists, and rankings. The document is presented as a slide deck for a talk.
This document discusses how Calciomercato.com scaled their Symfony application to handle millions of users and page views per month. It describes how they moved to Symfony 1.4 in 2010 and deployed revisions to scale the site. It also details techniques used to scale Symfony applications horizontally and vertically, such as caching, load balancing, master-slave databases, and monitoring tools.
14. Unit testing In computer programming, unit testing is a method by which individual units of source code are tested to determine if they are fit for use. A unit is the smallest testable part of an application. Ideally, each test case is independent from the others: substitutes like method stubs, mock objects, fakes and test harnesses can be used to assist testing a module in isolation.
15. Unit testing In computer programming, unit testing is a method by which individual units of source code are tested to determine if they are fit for use. A unit is the smallest testable part of an application. Ideally, each test case is independent from the others: substitutes like method stubs, mock objects, fakes and test harnesses can be used to assist testing a module in isolation.
16. Unit testing In computer programming, unit testing is a method by which individual units of source code are tested to determine if they are fit for use. A unit is the smallest testable part of an application. Ideally, each test case is independent from the others: substitutes like method stubs, mock objects, fakes and test harnesses can be used to assist testing a module in isolation.
17. Unit testing In computer programming, unit testing is a method by which individual units of source code are tested to determine if they are fit for use. A unit is the smallest testable part of an application. Ideally, each test case is independent from the others: substitutes like method stubs, mock objects, fakes and test harnesses can be used to assist testing a module in isolation .
18. Scusa #1 “Non ho tempo per scrivere i test” oppure “Potrei lavorare ad altre feature nel frattempo”
21. Funziona Durante le operazioni di debug il codice testato viene eliminato velocemente. Non sarà necessario perdere tempo “ per farlo funzionare ” dato che i test garantiscono il suo funzionamento sin dall'inizio.
35. Può essere ma... Invece che scriverli tutti alla fine basta fare in modo di scriverli prima di implementare la funzionalità (TDD). Il passaggio da scrittura del test a scrittura della feature renderà tutto più divertente.
57. All'interno dei metodi di test, i metodi di asserzione come assertEquals() vengono utilizzati per verificare che un certo valore corrisponda al valore atteso.
58. Assertions – Le più comuni AssertTrue/AssertFalse Check the input to verify it equals true/false AssertEquals Check the result against another input for a match AssertGreaterThan Check the result to see if it’s larger than a value AssertContains Check that the input contains a certain value AssertType Check that a variable is of a certain type AssertNull Check that a variable is null AssertFileExists Verify that a file exists AssertRegExp Check the input against a regular expression
59. Fixtures Una delle cose più dispendiose nella scrittura dei test è la parte relativa al codice per impostare l'ambiente e partire da uno stato conosciuto e per poi tornarci alla fine del test. Lo stato conosciuto è chiamato fixture .
60. setUp() Il metodo setUp() viene invocato prima dell'esecuzione del test. Permette impostare lo stato conosciuto necessario al test.
61. tearDown() Al termine dell'esecuzione del test viene invocato il metodo tearDown() . Si occupa delle pulizie.
62. Doubles “ Sometimes it is just plain hard to test the system under test (SUT) because it depends on other components that cannot be used in the test environment. This could be because they aren't available, they will not return the results needed for the test or because executing them would have undesirable side effects. In other cases, our test strategy requires us to have more control or visibility of the internal behavior of the SUT. When we are writing a test in which we cannot (or chose not to) use a real depended-on component (DOC), we can replace it with a Test Double. The Test Double doesn't have to behave exactly like the real DOC; it merely has to provide the same API as the real one so that the SUT thinks it is the real one!” --Gerard Meszaros
63. Stub Oggetto appositamente configurato per restituire valori predefiniti. Rimpiazza un oggetto reale dal quale dipende is SUT. Permette di avere il controllo sugli input indiretti del SUT.
64. Stub - esempio <?php class SomeClass { public function doSomething() { // Do something. } } ?>
65. Stub - esempio <?php require_once 'SomeClass.php'; class StubTest extends PHPUnit_Framework_TestCase { public function testStub() { // Create a stub for the SomeClass class. $stub = $this->getMock('SomeClass'); // Configure the stub. $stub->expects($this->any()) ->method('doSomething') ->will($this->returnValue('foo')); // Calling $stub->doSomething() will now return // 'foo'. $this->assertEquals('foo', $stub->doSomething()); } } ?>
66. Mock Oggetto appositamente configurato per verificare delle aspettative, come per esempio la chiamata di un metodo specifico. Punto di osservazione utilizzato per verificare gli output indiretti del SUT mentre è in esecuzione.
67. Mock - esempio <?php class Subject { protected $observers = array(); public function attach(Observer $observer) { $this->observers[] = $observer; } public function doSomething() { // Do something. // ... // Notify observers that we did something. $this->notify('something'); } protected function notify($argument) { foreach ($this->observers as $observer) { $observer->update($argument); } } // Other methods. }
68. Mock - esempio class Observer { public function update($argument) { // Do something. } public function reportError($errorCode, $errorMessage, Subject $subject) { // Do something } // Other methods. } ?>
69. Mock - esempio <?php class SubjectTest extends PHPUnit_Framework_TestCase { public function testObserversAreUpdated() { // Create a mock for the Observer class, // only mock the update() method. $observer = $this->getMock('Observer', array('update')); // Set up the expectation for the update() method // to be called only once and with the string 'something' // as its parameter. $observer->expects($this->once()) ->method('update') ->with($this->equalTo('something')); // Create a Subject object and attach the mocked // Observer object to it. $subject = new Subject; $subject->attach($observer); // Call the doSomething() method on the $subject object // which we expect to call the mocked Observer object's // update() method with the string 'something'. $subject->doSomething(); } } ?>
Una pratica che permette di verificare che singole unità di codice facciano effettivamente ciò per cui sono state scritte. Un'unità è la più piccola parte delle'applicazione. Nel caso ideale ogni test è indipendente dagli altri: per ottenere quest'isolamento possiamo ricorrere all'utilizzo di stubs, mocks, fakes...
Le chiavi della definizione sono le seguenti: parliamo di singole unità di codice
...dove l'unità di codice è la più piccola parte testabile dell'applicazione: - PROCEDURALE: intero programma, funzioni - OO: metodi
Il vincolo è quello di poter testare la singola unità di codice in ISOLAMENTO dal resto dell'applicazione.
Legittima se non si conoscono i test... La regola dell'80/20...
Perchè? Perchè non hai test. Rompi il codice e tu non lo sai. Un altro dev rompe il tuo codice e tu non lo sai. Tu rompi il codice dell'altro dev e lui non lo sa.
Ecco quindi che il “non ho tempo” significa “non ho tempo di imparare a testare il codice e voglio solo scrivere codice reale ORA”. Pigrizia Poca lungimiranza
La locuzione latina Beati monoculi in terra caecorum (pronuncia: beàti monòculi in tèrra cecòrum)
Lanciare la suite di test frequentemente permette di individuare i bug. E' inevitabile. Individuare i bug subito permette di risolverli più facilmente dato che il codice è ancora “fresco” in testa. Inoltre si possono aggiungere nuovi test per bug extra prima di fixarli per essere sicuri di cosa si sta modificando.
Individuare e risolvere i bug poco tempo dopo la loro introduzione è molto più veloce che trovare, analizzare e risolvere un bug tra 1 o 6 mesi. Inoltre si evita di rompere altre parti dell'applicazione con l'inserimento di nuove feature.
Automatizzare l'esecuzione della suite di test è il valore in più. Possono essere lanciati velocemente da console o da un refresh del browser. Verificano tutto. Il costo di scrittura è una-tantum, vengono eseguiti migliaia di volte. GRATIS.
Modificare un metodo mantenendo inalterati i dati che restituisce. Inserire nuove funzionalità senza rompere le altre. Senza test non è possibile fare REFACTORING.
Scrivere i test spinge a pensare maggiormente come mantenere le cose semplici: disaccoppiate e flessibili. Si traduce in facilità di test. Se è difficile da testare non è ben progettato. Se è troppo corposo potrebbe essere necessario separare le cose in classi diverse...
Il test descrive un caso d'uso o un esempio. Un esempio spesso vale più di mille parole. &quot;testdox&quot; strumento che elenca (sfruttando i nomi dei metodi) ciò che l'esempio asserisce. Essenzialmente rappresenta una specifica delle classi più leggibile per i non sviluppatori (DBA).
Un errore comune è quello di buttarsi a capofitto nello scrivere codice senza una strategia ben definita. Come essere in una stanza buia, ci si muove a tentativi tornando indietro per poi ripartire perdendo un sacco di tempo per trovare l'uscita. Dovendo scrivere i test si è obbligati a pensare al problema in modo diverso per trovare soluzioni semplici, eleganti e pratiche. E' più facile andare avanti, tornare indietro è raro.
Poter verificare il codice, individuare bug più facilmente, apportare modifiche senza correre rischi permette di spendere più tempo sviluppando nuove feature invece che risolvendo problemi. Si guarda sempre avanti.
Se si sono scritti test per coprire tutte le feature richieste e tutti passano è ragionevole pensare che il codice sia finito. Questo si mischia bene con le pratiche XP/Agile dove i test servono anche per verificare i requisiti funzionali.
Avere fiducia nel proprio codice, poter cambiare facilmente le cose, risolvere i problemi con criterio ed in modo elegante, poter fare refactoring sono tutte cose che fanno apprezzare il processo.
Nella documentazione trovate tutte le assertion disponibili, vi assicuro che ce ne sono davvero molte...
setUp() and tearDown() are nicely symmetrical in theory but not in practice. In practice, you only need to implement tearDown() if you have allocated external resources like files or sockets in setUp(). If your setUp() just creates plain PHP objects, you can generally ignore tearDown(). However, if you create many objects in your setUp(), you might want to unset() the variables pointing to those objects in your tearDown() so they can be garbage collected. The garbage collection of test case objects is not predictable.
Nella definizione di unit testing abbiamo visto che eseguire i testi in isolamento è importante. A volte non possiamo utilizzare i componenti reali da cui dipende ciò che stiamo testando ecco quindi che entrano in campo i Double. Un Double rimpiazza un DOC. Un Double non dev'essere per forza uguale al DOC che rimpiazza, deve avere la stessa API per far credere al sistema che si tratta del componente vero!