Test automatizzati: TDD e BDD nella pratica

Il testing è il fondamento di un software affidabile. Se applicati bene, riducono i bug, aumentano la velocità di consegna e danno sicurezza al refactoring. Due paradigmi popolari sono il Test-Driven Development (TDD) e il Behavior-Driven Development (BDD). Sebbene complementari, hanno focus diversi.

Quando utilizzare TDD rispetto a BDD

TDD: focus sulle unità di codice (funzioni, classi). Scrivi il test prima dell'implementazione, assicurandoti che l'API pubblica si comporti come previsto.
BDD: focus sul comportamento di alto livello (flussi utente, requisiti). Utilizza un linguaggio quasi naturale (Gherkin) per descrivere gli scenari.

Regola pratica: utilizzare TDD per la logica aziendale e le librerie interne; utilizzare BDD per flussi e integrazioni dell'interfaccia utente.

Strumenti consigliati

Strato	Strumento	Perché usare
Unitario (JS/TS)	Scherzo	Test rapidi e istantanei, copertura integrata
Unitario (nodo)	Moka + Chai	Flessibile, buona integrazione con Sinon
UI (Reagire)	Libreria di prova	Testare l'interfaccia utente come la vede l'utente
End-to-end	Cipresso	Test del browser reale, debug visivo
BDD	Cecumber.js	Sintassi Gherkin, integrazione Jest/Cypress

Flusso TDD passo dopo passo

Scrivi il test che fallisce (rosso).
Implementare il codice minimo per passare (verde).
Refactoring mantenendo i test verdi (refactoring).
Ripeti.

Esempio pratico, funzione di formattazione dei prezzi

// priceFormatter.test.ts (Jest)
import { formatPrice } from './priceFormatter';

test('formata número como moeda BRL', () => {
  expect(formatPrice(1234.5)).toBe('R$ 1.234,50');
});

// priceFormatter.ts (implementação mínima)
export function formatPrice(value: number): string {
  return new Intl.NumberFormat('pt-BR', { style: 'currency', currency: 'BRL' }).format(value);
}

Flusso BDD con Cucumber.js

Definizione dello scenario (Gherkin)

Feature: Cadastro de Usuário
  As a visitor
  I want to create an account
  So that I can access protected features

  Scenario: Cadastro bem-sucedido
    Given I am on the registration page
    When I fill the form with valid data
    And I submit the form
    Then I should see a confirmation message
    And I receive a verification email

Realizzazione dei passaggi (Cipresso + Cetriolo)

import { Given, When, Then } from 'cypress-cucumber-preprocessor/steps';

Given('I am on the registration page', () => {
  cy.visit('/register');
});

When('I fill the form with valid data', () => {
  cy.get('#email').type('usuario@example.com');
  cy.get('#password').type('SenhaForte123!');
  cy.get('#confirmPassword').type('SenhaForte123!');
});

When('I submit the form', () => {
  cy.get('form').submit();
});

Then('I should see a confirmation message', () => {
  cy.contains('Cadastro concluído').should('be.visible');
});

Buone pratiche generali

Mantieni i test veloci: se un test dura più di 500 ms, probabilmente sta eseguendo I/O non necessari.
Isolamento: utilizza mock/stub per dipendenze esterne (API, banche).
Copertura minima: una copertura della linea dell'80% è un buon punto di partenza, ma dare priorità alla logica critica.
Integrazione continua: configura la pipeline (GitHub Actions, GitLab CI) per eseguire npm test su ciascun PR.
Feedback visivo: utilizza plugin IDE che mostrano i risultati dei test in tempo reale.

Lista di controllo per l'implementazione

[] Scegli il framework di test (Jest, Cypress, ecc.)
Configura jest.config.js e cypress.json
Crea le directory tests/unit e tests/e2e
Scrive il primo test fallito per ogni nuova funzionalità
[] Integrare i test nella pipeline CI
Monitorare la copertura e gli errori di fallback

Conclusione

TDD e BDD non sono solo tecniche, sono cambiamenti di mentalità. Se adottati correttamente, garantiscono che il tuo codice si evolva senza timore di interrompere le funzionalità esistenti. Inizia in piccolo, scrivi test chiari e lascia che guidino il tuo sviluppo.

Qual è la tua esperienza con TDD o BDD? Condividi nei commenti!