Articles in category: Software Testing
The goal of this article is to define basic concepts related to testing, trying not to take anything for granted.
Why do we test??
Why is it important to write automated tests? I asked myself and I did some research because the answer to this question was not obvious to me. I knew it was important but I didn’t know why. So, I decided to try to explain it starting from a point of view as impartial as possible.
In the latest months I wrote multiple times, in different projects, code migrating PHPUnit toward major version 6. This upgrade is harder than the previous one, since in this version it was introduced a big breaking change: all classes got (finally!) namespaced.
This means that any usage of those classes in your project needs to be updated. It may seem a simple find & replace job, but since you need to introduce at least one use PHPUnit\Framework\TestCase line at the top of each one of your test classes, it’s a boring and a little more than trivial task; also, upgrading it in a single big jump may not be feasible or prudent, especially in the case of open source or distributed libraries, where backward compatibility and support for old PHP versions must be ensured.
A few days ago I stumbled on a strange tweet that was highlighting a controversy about scalar type hints.
After asking references about this, someone alluded to this very short video: “PHP Bits: Visual Debt” (it’s only 3 minutes, please watch it before continue reading). After that, the author of the video was dragged into the conversation, and it blew up into a big tweetstorm in the following few hours.
Questo articolo è la sintesi di un talk presentato al SymfonyDay 2015; potete trovare le slide qui.
I test e la loro durata
Sviluppare applicazioni scrivendo test e facendo Test Driven Development è un’ottima pratica, e dà parecchie soddisfazioni. Con l’andare del tempo, si fa crescere la suite di test del proprio progetto, cercando di aumentarne la copertura e l’efficacia e si scrivono nuovi test corrispondenti alle nuove funzionalità che vengono man mano sviluppate.
In un precedente articolo abbiamo visto le impostazioni di base in Xcode per la scrittura dei test unitari: abbiamo evidenziato inoltre l’importanza e l’utilità intrinseca dei test, attraverso un semplice esempio riguardante un caso d’uso tipico. Nel presente articolo vedremo alcune tecniche un po’ più avanzate:
- implementeremo uno Stub Object in Swift;
- analizzeremo un altro caso di test asincrono;
Lo Stub Object
Uno Stub Object (per il resto dell’articolo, stub) rappresenta un’istanza di una certa classe, la quale mima una vera classe presente nella nostra code base: l’istanza si comporta esattamente come una equivalente istanza della classe mimata, tranne alcune differenze, ad esempio alcuni metodi possono essere sovrascritti per poter fornire un determinato output utile per i test. Nell’implementare uno stub non è generalmente consentito modificare dettagli di logica interni relativi alla classe che stiamo mimando, ma è possibile sovrascrivere metodi pubblici, in modo che essi ritornino i valori che vogliamo, oppure che svolgano una particolare procedura necessaria per i test. Tanto per fare un esempio pratico potremmo stubbare una classe che ci fornisce la data precisa in un certo istante, in modo da ottenere una data diversa da usare nei test, oppure un client che chiede a un server delle informazioni su un utente, in modo da far ritonare al client stub delle informazioni arbitrarie.
