TDD e BDD — Cheat Sheet

Tag: tdd, bdd, testing, agile, clean-code, refactoring, automated-testing

Livello: intermedio

TL;DR: TDD guida la progettazione software tramite cicli red-green-refactor e test unitari; BDD allinea requisiti di business e implementazione attraverso scenari comportamentali leggibili.

Concetti chiave

-

TDD segue il ciclo Red, Green, Refactor.

-

La fase Red richiede di scrivere un test a fallimento prima di qualsiasi codice di produzione.

-

La fase Green richiede di scrivere il codice minimo necessario per superare il test.

-

La fase Refactor richiede di pulire il design eliminando duplicazioni mantenendo i test verdi.

-

I test unitari in TDD agiscono come specifiche eseguibili a basso livello.

-

BDD estende TDD spostando il focus dal test del codice al comportamento atteso del sistema.

-

BDD utilizza la sintassi Given-When-Then per descrivere scenari leggibili anche dagli stakeholder.

-

Ubiquitous Language in BDD unifica il vocabolario tra sviluppatori, tester e business.

-

Outside-In TDD (Double Loop) combina acceptance test BDD esterni con test unitari TDD interni.

Domande tipiche e risposte pronte

-

Q: Qual e la differenza sostanziale tra TDD e BDD?R: TDD e una pratica di design e sviluppo per ingegneri, guidata da test unitari. BDD e un processo collaborativo che definisce il comportamento dell'applicazione dal punto di vista dell'utente finale.

-

Q: Perche la fase di refactoring e fondamentale nel ciclo TDD?R: Senza refactoring il codice minimo scritto in fase Green accumula rapidamente debito tecnico. Il refactoring protegge la pulizia dell'architettura garantendo che la suite resti verde.

-

Q: Come si gestiscono i test lenti o le dipendenze esterne in TDD?R: Isolo il dominio tramite mock, stub o fakes per le dipendenze esterne come database o API di terze parti, preservando l'esecuzione rapida della suite.

Insidie e errori comuni

-

Testare dettagli implementativi anziche il comportamento pubblico.

-

Saltare la fase di refactoring una volta ottenuto il test verde.

-

Scrivere troppi assert non correlati all'interno di un singolo unit test.

-

Accoppiare strettamente i test alla struttura interna delle classi.

-

Scrivere scenari BDD troppo tecnici invece di usare il linguaggio di business.

Snippet e comandiTypeScript

// Esempio TDD: test unitario con AAA pattern
describe('ShoppingCart', () => {
  it('should calculate total with discount when voucher is applied', () => {
    const cart = new ShoppingCart();
    cart.addItem({ name: 'Book', price: 100 });

    cart.applyVoucher('DISCOUNT10');

    expect(cart.getTotal()).toBe(90);
  });
});

Gherkin

# Esempio BDD: specifica comportamentale
Feature: Calcolo sconto carrello

  Scenario: Applicazione buono sconto valido
    Given un carrello con un articolo da 100 EUR
    When applico il codice coupon "DISCOUNT10"
    Then il totale da pagare deve risultare 90 EUR

Da ripassare

-

[ ] Pattern AAA (Arrange, Act, Assert) vs Given-When-Then

-

[ ] Mocking vs Stubbing secondo la scuola di Londra (mockist) e di Detroit (classicist)

-

[ ] Setup del ciclo Double Loop TDD con framework di acceptance testing

-

[x] Ciclo Red-Green-Refactor di base

Jarvis Interviews
Jarvis