Immagina di aver appena finito di scrivere una funzione che sembra perfetta. La provi una volta, due, funziona. Il giorno dopo modifichi un’altra parte del codice e… boom, quella funzione smette di funzionare senza che nessuno te lo dica.

È successo a tutti.😅

I test automatici sono esattamente l’antidoto: piccoli pezzi di codice che controllano per te, ogni volta che cambi qualcosa, se il tuo programma continua a comportarsi come deve.

Non è più questione di “sperare che vada bene”.

È questione di sapere, in pochi secondi, se hai rotto qualcosa o no.

Cosa sono i test automatici

I test automatici sono porzioni di codice che verificano il comportamento corretto di altre parti del tuo programma.

Invece di controllare a mano ogni funzione, scrivi uno script che la invoca con input noti e confronta l’output con quello atteso.

Un test automatico tipico fa tre cose:

• Prepara dei dati di input
• Esegue una funzione del tuo codice
• Confronta il risultato con un valore atteso e segnala successo o fallimento

Perché sono fondamentali

I due strumenti principali in Python

unittest (libreria standard)

Incluso in Python, ispirato a JUnit. Richiede classi e nomi di metodi specifici.

pytest (terze parti, il più usato nella community)

Più semplice e potente. Si installa con pip install pytest e permette di scrivere test come normali funzioni.

In questa guida vedremo entrambi, con esempi che puoi copiare e incollare subito su Google Colab.

Esempio pratico: la funzione da testare

Creiamo una funzione semplice ma realistica che calcola l’area di un rettangolo e gestisce gli errori:

# my_math.py
def area_rettangolo(base, altezza):
    if base < 0 or altezza < 0:
        raise ValueError("Le dimensioni non possono essere negative")
    return base * altezza

1. Test con unittest

import unittest
from my_math import area_rettangolo

class TestAreaRettangolo(unittest.TestCase):
    def test_area_positiva(self):
        self.assertEqual(area_rettangolo(5, 3), 15)

    def test_area_con_zero(self):
        self.assertEqual(area_rettangolo(0, 10), 0)

    def test_valori_negativi(self):
        with self.assertRaises(ValueError):
            area_rettangolo(-1, 5)

if __name__ == '__main__':
    unittest.main()

Come eseguirlo su Google Colab (copia-incolla queste due celle):

%%writefile my_math.py
def area_rettangolo(base, altezza):
    if base < 0 or altezza < 0:
        raise ValueError("Le dimensioni non possono essere negative")
    return base * altezza

import unittest
from my_math import area_rettangolo

class TestAreaRettangolo(unittest.TestCase):
    def test_area_positiva(self):
        self.assertEqual(area_rettangolo(5, 3), 15)

    def test_area_con_zero(self):
        self.assertEqual(area_rettangolo(0, 10), 0)

    def test_valori_negativi(self):
        with self.assertRaises(ValueError):
            area_rettangolo(-1, 5)

# Esecuzione nella cella
suite = unittest.TestLoader().loadTestsFromTestCase(TestAreaRettangolo)
unittest.TextTestRunner(verbosity=2).run(suite)

Output atteso:

test_area_con_zero ... ok
test_area_positiva ... ok
test_valori_negativi ... ok
----------------------------------------------------------------------
Ran 3 tests in 0.005s
OK

Guida rapida ai comandi principali di unittest

Da terminale

• python -m unittest → lancia tutti i test
• python -m unittest -v → modalità verbose
• python -m unittest discover -s tests → scopre automaticamente i test in una cartella

Asserzioni più utili

• self.assertEqual(a, b) – uguaglianza
• self.assertRaises(ValueError) – controlla eccezioni
• self.assertAlmostEqual – per i float
• self.assertIn / assertNotIn – appartenenza

Decoratori utili

• @unittest.skip("motivo")
• @unittest.skipIf(condizione, "motivo")
• @unittest.expectedFailure (per bug noti)
• subTest (per testare tanti casi senza scrivere 10 metodi):

def test_vari_casi(self):
    casi = [(5, 3, 15), (0, 10, 0), (10, 0, 0)]
    for base, altezza, atteso in casi:
        with self.subTest(base=base, altezza=altezza):
            self.assertEqual(area_rettangolo(base, altezza), atteso)

2. Test con pytest (il modo più moderno)

Prima installa (su Colab o nel tuo ambiente):

pip install pytest

I test diventano funzioni normali, niente classi:

# test_my_math.py
import pytest
from my_math import area_rettangolo

def test_area_positiva():
    assert area_rettangolo(5, 3) == 15

def test_area_con_zero():
    assert area_rettangolo(0, 10) == 0

def test_valori_negativi():
    with pytest.raises(ValueError):
        area_rettangolo(-1, 5)

Versione parametrizzata (equivalente del subTest, ma più pulita):

@pytest.mark.parametrize("base, altezza, atteso", [
    (5, 3, 15),
    (0, 10, 0),
    (10, 0, 0),
    (2.5, 4, 10)
])
def test_area_vari_casi(base, altezza, atteso):
    assert area_rettangolo(base, altezza) == atteso

Esecuzione

• Terminale: pytest -v
• Colab: !pytest --verbose

pytest è più veloce da scrivere, produce output più leggibile e ha centinaia di plugin utili (coverage, parametrizzazione avanzata, test paralleli…).

pip install pytest

# test_primo_test.py
def test_somma_2_piu_2():
    assert 2 + 2 == 4

pytest

======================== test session starts ========================
platform ... collected 1 item
tests/test_primo_test.py .                                           [100%]
========================= 1 passed in 0.01s =========================

pytest -v -k "rettangolo"

def test_area_rettangolo_normale():
    assert area_rettangolo(5, 3) == 15          # deve essere esattamente 15

def test_area_con_zero():
    assert area_rettangolo(0, 10) == 0

def test_non_accetta_negativi():
    with pytest.raises(ValueError):              # controlla che venga sollevato un errore
        area_rettangolo(-1, 5)

import pytest
from my_math import area_rettangolo

@pytest.mark.parametrize("base, altezza, risultato_atteso", [
    (5, 3, 15),      # caso normale
    (0, 10, 0),      # zero
    (10, 0, 0),      # zero invertito
    (2.5, 4, 10.0),  # numeri decimali
])
def test_area_rettangolo(base, altezza, risultato_atteso):
    assert area_rettangolo(base, altezza) == risultato_atteso

@pytest.fixture
def dati_rettangolo():
    """Questa funzione viene eseguita automaticamente prima di ogni test che la richiede"""
    return {"base": 10, "altezza": 5}

def test_area_con_fixture(dati_rettangolo):
    area = area_rettangolo(dati_rettangolo["base"], dati_rettangolo["altezza"])
    assert area == 50

import pytest
import sys

@pytest.mark.skip(reason="Da implementare la prossima settimana")
def test_funzione_futura():
    ...

@pytest.mark.skipif(sys.version_info < (3, 11), reason="Serve Python 3.11 o superiore")
def test_feature_nuova():
    ...

@pytest.mark.xfail(reason="Bug conosciuto #45")   # come "expectedFailure" di unittest
def test_che_sappiamo_che_fallisce():
    ...

il_mio_progetto/
├── my_math.py                 ← il codice da testare
├── tests/
│   ├── __init__.py            ← file vuoto, serve solo per Python
│   ├── test_my_math.py        ← tutti i test della funzione area
│   └── test_altre_cose.py
└── conftest.py                ← (opzionale) fixture condivise tra tutti i test

Confronto veloce unittest vs pytest

def test_valori_negativi():
    with pytest.raises(ValueError):
        area_rettangolo(-1, 5)

Dal tutorial alla produzione: perché i test ti salvano la carriera

Calcolare l’area di un rettangolo sembra una cosa banale, ma è un esempio perfetto proprio perché contiene tutto quello che serve nella pratica:

• Casi normali (valori positivi)
• Casi limite (zero)
• Casi di errore (valori negativi)

Nella vita reale è esattamente quello che fai con funzioni critiche: validi i dati in ingresso, gestisci gli edge case e impedisci che un valore sbagliato mandi in crash l’applicazione (pensa a un sistema di preventivi, a un software di progettazione o a un e-commerce che calcola dimensioni di imballaggi).

Inoltre l’esercizio ti insegna due abitudini d’oro:

1. I test non servono solo a “verificare che funzioni”, ma anche a documentare il comportamento atteso. Chi legge i test capisce subito che le dimensioni negative sono proibite.
2. Usare subTest o @pytest.mark.parametrize è la strada per non scrivere 10 metodi identici quando devi testare tante combinazioni.

Chi capisce questo piccolo esempio ha già in mano la logica per testare funzioni molto più complesse.

Queste non sono storie inventate: sono cose che succedono ogni giorno in aziende vere. pytest non è solo “codice in più”: è la differenza tra “ops, ho rotto tutto” e “tutto sotto controllo”.

❗ Il bagno di realtà: Quando i test automatici NON bastano

Per quanto pytest sia un’arma potentissima, c’è una trappola in cui cadono molti sviluppatori alle prime armi: credere al mito che “test tutti verdi = software perfetto”.

I test automatici confermano solo che il codice fa esattamente quello che gli hai detto di fare. Ma cosa succede se gli hai detto di fare la cosa sbagliata? Ecco tre scenari in cui i test non possono salvarti:

• Non sostituiscono l’occhio umano e la UX (User Experience): Un test automatico può certificare che la funzione aggiungi_al_carrello() scatta in 0.01 secondi e aggiorna il database. Ma non ti dirà mai che sul sito web il bottone “Acquista” è illeggibile su mobile, coperto da un banner o frustrante da cliccare. I test verificano la logica, gli umani verificano l’esperienza.

• Non trovano i bug di “Design” o i requisiti fraintesi: Se il cliente ti ha chiesto un sistema per calcolare l’IVA al 22% e tu scrivi una logica perfetta che la calcola al 10%, i tuoi test passeranno tutti con orgoglio. Hai scritto un codice impeccabile per il problema sbagliato. I test validano che l’ingranaggio giri bene, ma non sanno dirti se fa parte del motore giusto.

• Non evitano i disastri se il test stesso contiene errori di logica: È il classico principio del garbage in, garbage out (spazzatura dentro, spazzatura fuori). Se chi scrive il test non ha capito le regole di business e imposta un’asserzione errata (es. assert calcola_spedizione(peso) == 0 quando invece si doveva pagare), il test diventerà “verde” solo quando il codice nasconderà un buco economico per l’azienda. Un test sbagliato è infinitamente peggio di nessun test, perché ti regala una letale e falsa sensazione di sicurezza.

La regola d’oro del vero Senior: Usa i test automatici per blindare la logica del codice, le formule e i casi limite, in modo da non doverci pensare mai più. Ma usa sempre il buon senso (e il testing manuale) per valutare l’usabilità e la direzione generale del prodotto.

Il livello successivo: i “Mock” (ovvero le controfigure del tuo codice)

Finora abbiamo testato una funzione matematica che vive in isolamento. Ma cosa succede se la tua funzione deve interagire con il mondo esterno, ad esempio scaricare dati da un’API, scrivere su un database o inviare un’email al cliente?

Non vuoi assolutamente che il tuo test invii davvero un’email ogni volta che premi invio. Inoltre, se manca la connessione a internet, il test fallirebbe anche se il tuo codice è perfetto.

Qui entra in gioco il Mocking.

Pensa al Mock come alla controfigura di un film d’azione: prende il posto dell’attore reale nelle scene pericolose o complicate. In Python (usando la libreria integrata unittest.mock o l’ottimo plugin pytest-mock), puoi dire al tuo test: “Ehi, quando arrivi alla riga in cui devi inviare l’email, fai finta di averla inviata con successo e vai avanti”.

Esempio pratico con pytest

Ecco come si presenta in pytest usando la fixture magica mocker:

# Il nostro codice originale
def invia_email_benvenuto(email):
    # Immagina del codice lento che contatta un server reale...
    pass

def registra_utente(email):
    # ... logica di registrazione ...
    invia_email_benvenuto(email)
    return True

# Il nostro test
def test_registra_utente_senza_inviare_spam(mocker):
    # Blocchiamo la funzione reale e ci mettiamo una "controfigura"
    mocker.patch("mio_progetto.invia_email_benvenuto")
    
    # Eseguiamo la funzione
    risultato = registra_utente("[email protected]")
    
    # Il test passa, ci mette un millisecondo e nessuno riceve spam!
    assert risultato == True

Il Mocking è uno scoglio su cui molti principianti sbattono la testa, ma capirne l’utilità fin dall’inizio ti risparmierà ore di frustrazione. Quando i tuoi test inizieranno a diventare lenti o a fallire per colpa della rete, saprai che è il momento di chiamare una controfigura.