Unit test di dati caricati staticamente

Un file di configurazione fa parte della configurazione dell'applicazione. In quanto tale, puoi testarlo in due modi.

Un modo è fare riferimento al sistema di controllo della versione e vedere se il file è identico a quello che avrebbe dovuto essere distribuito. È possibile abbreviare questo processo creando un file separato con un hash (ciò che viene chiamato un digest) del file di configurazione e confrontando il digest previsto con il digest effettivo.

Puoi anche impostare una revisione automatica della tua configurazione usando Tripwire o applicazioni simili.

I file di configurazione nel controllo sorgente sono praticamente equivalenti alle costanti in un linguaggio di programmazione.

E la particolarità delle costanti, almeno nella maggior parte dei linguaggi di programmazione, è che se le tratti come unità sotto test, non possono letteralmente avere alcun bug interno.

Ad esempio:

final static double PI = 4.2;

non ha bug localmente rilevabili. Ha solo un sacco di "potenziali problemi di integrazione" ...

Puoi scrivere un test come:

assertThat(PI, is(closeTo(4.2, epsilon));

e non solo non troverà il problema, ma fallirà quando qualcuno lo risolverà.

Se lavori su una base di codice con questo stile, allora ogni modifica apportata fallirà un test. Che è più o meno equivalente a non avere alcun test; è praticamente come avere due copie del codice sorgente in git e richiedere che siano uguali per "prevenire modifiche non intenzionali".

O devi leggere e rivedere il codice, o testare a un livello più ampio. Ad esempio, notando che le cerchie che usano PI sono strabilianti.

Nel tuo caso, questo significherebbe testare che:

• il comportamento predefinito è corretto
• cambiando il valore di configurazione cambia il comportamento

Non eccessivo.

I valori del file di configurazione devono essere modificati dagli amministratori, ma ...

I file di configurazione che vivono nel controllo sorgente probabilmente fanno parte di una configurazione predefinita distribuita. Pertanto, dovrebbero essere modificati solo cambiando la configurazione predefinita in mente, tuttavia ...

Gli sviluppatori devono essere in grado di modificarli, per aiutare a isolare i bug o implementare nuove funzionalità.

Ciò che vuoi impedire sono le modifiche non intenzionali ai file di configurazione.

Pertanto, adotterei lo stesso approccio per questi file di configurazione, come per i letterali che fanno parte dell'API di un'applicazione.

Suppongo di avere test unitari su tutti i letterali utilizzati in un'API. Tutti questi letterali sono ovviamente codificati come costanti, quindi gli errori di battitura non sono necessariamente una preoccupazione. I test servono a rilevare modifiche non intenzionali dei valori letterali di queste costanti. I test, in base alla progettazione, fanno non utilizzano queste costanti. Il pensiero è che se si modifica solo il valore letterale della costante, o solo il valore letterale nel test, probabilmente non era intenzionale e si ha bisogno della notifica di un fallimento del test. Mentre se hai modificato entrambi i valori letterali, probabilmente hai inteso la modifica e il test può passare.