A unit test is a runnable piece of code that verifies that another piece of code (called production code) does what it is supposed to do.
A unit test has many characteristics and one of the most important is that a single unit test must verify one and only one thing.
If a unit test specifies more than one behavior things became harder to mantain. One a tests fail it has to be easy to understand what is going wrong and which section of our production code is behaving badly.
As a best practice we make each test independent to all the others: any given behaviour should be specified in one and only one test. Otherwise if you later change that behaviour, you’ll have to change multiple tests.
Sono ripresi oggi gli appuntamenti all’ITI F.Viola / Marchesini di Rovigo di Agile@School dopo le vacanze: siamo al sesto episodio su dieci. Come ripromesso negli episodi precedenti abbiamo ripreso in mano dei principi Agile/DevOps che negli ultimi incontri erano stati parcheggiati in favore di approfondimenti tecnologici su Xamarin Forms.
Continue reading Agile@School – sesta lezione
I’m sure we all hear about unit testing, test driven development and so on. These practices are useful and provide a long list of benefit like writing low-coupled and mantainable code to name a few.
We want to write unit test for our UWP Prism application and we’d like, for example, to put our ViewModels under tests to make sure the logic they implement is correct. Unit testing is possible only if we can get rid of all the dependencies in our class under test because we want to run our test every time we want (for exemple when the service library our teammate is writing is not yet finished) and as fast as we can.
Continue reading UWP Prism Unit Test
Testing “hard” things is tough because you have to build them to test them,
which discourages speculative building just to see what will happen. But the
building process in software is ridiculously cheap. We’ve developed an entire
ecosystem of tools that make it easy to do just that: unit testing, mock objects,
test harnesses, and lots of other stuff. Other engineers would love to be able
to build something and test it under realistic conditions. As software developers,
we should embrace testing as the primary (but not the only) verification
mechanism for software. Rather than waiting for some sort of calculus for
software, we already have the tools at our disposal to ensure good engineering
practices. Viewed in this light, we now have ammunition against managers
who tell us “we don’t have time to test.” A bridge builder would never hear
from his boss, “Don’t bother doing structural analysis on that building—we
have a tight deadline.” The recognition that testing is indeed the path to reproducibility
and quality in software allows us as developers to push back on
arguments against it as professionally irresponsible.
Testing takes time, just like structural analysis takes time. Both activities ensure
the quality of the end product. It’s time for software developers to take up the
mantle of responsibility for what they produce. Testing alone isn’t sufficient,
but it is necessary. Testing is the engineering rigor of software development.
da “97 things every programmer should know” – O’Reilly
Avevo la necessità di scrivere un test per il metodo Acquisisci() di una classe per la l’importazione di alcuni file di testo. Questo metodo al suo interno esegue, in pseudocodice:
Importa(file); //Legge il file e salva il suo contenuto nel db.
Archivia(file); //Sposta il file in una cartella di archivio.
Il mio scopo nello scrivere il test era quello di evitare l’istruzione Archivia(file) per poter lanciare ripetutamente i test senza dover rimettere i file nella posizione originale ogni volta.
Così ho ereditato dalla classe di Acquisizione come segue
e poi il test è diventato qualcosa del tipo:
In questo modo sono riuscito a scrivere un test ripetibile senza dover modificare la classe sotto test.