Cosa sono i test parametrizzati e i test data-driven?

Question

Accepted Answer

**Test parametrizzati (data-driven)** eseguono la **stessa logica di test con più insiemi di input e output attesi** — evitando di duplicare il test per ogni caso. Rendono facile testare molti scenari (inclusi i casi limite) in modo conciso.

## Il problema: test duplicati

```text
Without parameterization, testing many input/output cases means COPYING the test:
  test('add 2+3', () => expect(add(2,3)).toBe(5));
  test('add 0+0', () => expect(add(0,0)).toBe(0));
  test('add -1+1', () => expect(add(-1,1)).toBe(0));
  → lots of near-identical, repetitive tests (tedious, hard to maintain)
```

## Test parametrizzati — un test, molti casi

```js
// run the SAME test logic over a TABLE of cases (Jest's test.each)
test.each([
  [2, 3, 5],
  [0, 0, 0],
  [-1, 1, 0],
  [100, 200, 300],
])('add(%i, %i) === %i', (a, b, expected) => {
  expect(add(a, b)).toBe(expected);     // one logic, run per case
});
// → each row is a separate reported test case; add a case = add a row
```

La maggior parte dei framework supporta questa funzionalità (Jest `test.each`, pytest `@parametrize`, JUnit `@ParameterizedTest`).

## Vantaggi

```text
✓ CONCISE — test many scenarios without duplicating the test body
✓ Easy to ADD CASES — just add a row of data (great for edge cases / many inputs)
✓ Each case reported SEPARATELY — you see exactly which input failed
✓ Clear, maintainable — the data table documents the cases
→ Ideal for functions with many input/output combinations and edge cases.
```

## Perché è importante

Comprendere i test parametrizzati (data-driven) è prezioso perché rendono **facile testare molti scenari in modo conciso**, il che supporta un testing completo (soprattutto dei casi limite), quindi è una conoscenza pratica utile.

Il problema che risolvono — testare molte combinazioni di input/output richiederebbe altrimenti di **duplicare il test per ogni caso** (tedioso, ripetitivo, difficile da mantenere) — è reale, e i test parametrizzati lo affrontano eseguendo la **stessa logica di test su una tabella di casi**.

Ciò rende il testing di molti scenari **conciso** (un corpo di test, molti casi), rende **facile aggiungere casi** (basta aggiungere una riga di dati — il che incoraggia il testing di più input e **casi limite**, supportando la copertura approfondita dei casi limite che cattura i bug), riporta **ogni caso separatamente** (così vedi esattamente quale input ha fallito, aiutando il debug), e mantiene i test manutenibili (la tabella di dati documenta chiaramente i casi).

Comprendere che la maggior parte dei framework supporta questa funzionalità (Jest's `test.each`, pytest's `@parametrize`, JUnit's `@ParameterizedTest`) la rende praticamente applicabile su diversi stack.

I test parametrizzati sono ideali per funzioni con molte combinazioni di input/output — comuni per funzioni di utility, validator, parser e calcoli — dove consentono di testare l'intera gamma di casi (inclusi i confini e i casi limite) senza il carico di codice di test duplicato.

Questo modo conciso e manutenibile di ottenere una copertura ampia degli input incoraggia un testing più completo.

Poiché testare molti scenari (soprattutto i casi limite) è importante per un testing completo e i test parametrizzati lo rendono conciso e manutenibile (evitando test duplicati, incoraggiando una copertura ampia degli input), e poiché comprenderli e il loro supporto nei framework è utile per un testing efficace, comprendere i test parametrizzati e data-driven è una conoscenza preziosa e praticamente rilevante — una tecnica utile per testare molti casi in modo conciso, supportando la copertura approfondita dei casi limite che il testing efficace richiede, e uno strumento utile applicato ovunque le funzioni abbiano molte combinazioni di input/output da verificare.