A cosa servono i test unitari

Un test unitario testa un'unità di codice in isolamento: nessun database, nessuna rete, nessun file system. Il test parte, esegue, termina in millisecondi. Non c'è nulla da preparare e nulla da smontare.

Questo li rende diversi dai test di integrazione per scopo, non solo per velocità. Servono a tre cose distinte.

---

1. Testare logica pura senza dipendenze

La business logic che non tocca infrastruttura (entity di dominio, value object, algoritmi, regole di validazione) si testa in isolamento. Non serve un database per verificare che un ordine confermato non possa essere annullato.

[TestFixture]
public class OrdineTests
{
    [Test]
    public void Ordine_confermato_non_puo_essere_annullato()
    {
        var ordine = new Ordine(clienteId: 1, importo: 100m);
        ordine.Conferma();

        var act = () => ordine.Annulla("ripensamento");

        act.Should().Throw<InvalidOperationException>()
            .WithMessage("*confermato*");
    }

    [Test]
    public void Importo_negativo_non_e_ammesso()
    {
        var act = () => new Ordine(clienteId: 1, importo: -1m);

        act.Should().Throw<ArgumentException>();
    }

    [Test]
    public void Sconto_non_puo_superare_il_totale()
    {
        var ordine = new Ordine(clienteId: 1, importo: 50m);

        var act = () => ordine.ApplicaSconto(60m);

        act.Should().Throw<InvalidOperationException>();
    }
}

Questi test sono anche la documentazione più precisa delle regole di dominio: chiunque legga i nomi dei metodi capisce cosa il sistema permette e cosa vieta, senza aprire un manuale.

---

2. Monitorare le librerie di terze parti

Una libreria esterna ha un ciclo di vita indipendente dal progetto. Quando viene aggiornata (intenzionalmente o perché un tool di aggiornamento automatico lo fa) il suo comportamento può cambiare in modo sottile: una edge case gestita diversamente, un default modificato, una funzione deprecata che ora si comporta in modo diverso.

I test che documentano il comportamento atteso di una libreria diventano il sensore che rileva questi cambiamenti.

[TestFixture]
public class FluentValidationBehaviorTests
{
    // Documenta: NotEmpty() tratta stringa vuota e null allo stesso modo
    [TestCase("")]
    [TestCase(null)]
    public void NotEmpty_rifiuta_stringa_vuota_e_null(string? valore)
    {
        var validator = new InlineValidator<string?>();
        validator.RuleFor(x => x).NotEmpty();

        validator.Validate(valore).IsValid.Should().BeFalse();
    }

    // Documenta: il messaggio di errore predefinito contiene il nome del campo
    [Test]
    public void NotEmpty_include_il_nome_del_campo_nel_messaggio()
    {
        var validator = new InlineValidator<CreaOrdineRequest>();
        validator.RuleFor(x => x.ClienteId).NotEmpty();

        var result = validator.Validate(new CreaOrdineRequest());

        result.Errors.Single().ErrorMessage.Should().Contain("Cliente Id");
    }

    // Documenta: When() non esegue la regola se la condizione è falsa
    [Test]
    public void When_salta_la_validazione_se_condizione_falsa()
    {
        var validator = new InlineValidator<CreaOrdineRequest>();
        validator.RuleFor(x => x.DataConsegna)
            .GreaterThan(DateTime.Today)
            .When(x => x.DataConsegna.HasValue);

        var request = new CreaOrdineRequest { DataConsegna = null };

        validator.Validate(request).IsValid.Should().BeTrue();
    }
}

Se dopo un aggiornamento di FluentValidation uno di questi test fallisce, il fallimento è intenzionale: segnala che il comportamento è cambiato e che va rivalutato prima di procedere con l'aggiornamento.

---

3. Coltellino svizzero per dubbi puntuali

Non tutto nasce da un requisito. A volte si vuole capire come funziona qualcosa di preciso: come DateTimeOffset gestisce le conversioni tra fusi orari, come string.Split tratta i separatori multipli, come EF serializza un tipo custom senza andare a leggere la documentazione per venti minuti.

Il test è il posto più rapido e preciso dove chiarirsi le idee. Una volta scritto, rimane come documentazione eseguibile per chiunque abbia lo stesso dubbio in futuro.

[TestFixture]
public class DateTimeOffsetBehaviorTests
{
    [Test]
    public void ToUniversalTime_converte_correttamente_da_fuso_europeo()
    {
        // UTC+2 in estate (ora legale italiana)
        var offset = new DateTimeOffset(2024, 6, 15, 10, 0, 0, TimeSpan.FromHours(2));

        offset.ToUniversalTime().Hour.Should().Be(8);
    }

    [Test]
    public void Due_DateTimeOffset_con_stesso_istante_e_fusi_diversi_sono_uguali()
    {
        var utc   = new DateTimeOffset(2024, 1, 1, 12, 0, 0, TimeSpan.Zero);
        var rome  = new DateTimeOffset(2024, 1, 1, 13, 0, 0, TimeSpan.FromHours(1));

        utc.Should().Be(rome); // stesso istante, fuso diverso
    }
}

[TestFixture]
public class StringSplitBehaviorTests
{
    [Test]
    public void Split_con_separatore_multiplo_non_produce_elementi_vuoti_con_RemoveEmptyEntries()
    {
        var risultato = "a,,b,,c".Split(',', StringSplitOptions.RemoveEmptyEntries);

        risultato.Should().BeEquivalentTo(["a", "b", "c"]);
    }

    [Test]
    public void Split_senza_opzioni_include_gli_elementi_vuoti()
    {
        var risultato = "a,,b".Split(',');

        risultato.Should().HaveCount(3);
        risultato[1].Should().BeEmpty();
    }
}

Questi test non nascono da un bug o da un requisito: nascono da una domanda. Risponderla con un test invece che con un breakpoint o una lettura veloce di Stack Overflow produce qualcosa di permanente e condivisibile.