DRY, string, e unit test

C'è un piccolo avvertimento sul principio ASCIUTTO di cui molte persone non sono consapevoli: non essere così ossessionato dall'evitare la ripetizione di rimuovere "duplicati" di cose che sembrano essere le stesse ma in realtà concettualmente molto diverse.

Come esempio estremo, non proverai a rimuovere la ripetizione dei duplicati di "/ s", "th", "on", "nt", ecc all'interno della tua stringa originale.

Nel tuo esempio particolare, non devi / non preoccuparti dei dettagli di implementazione del tuo codice sotto test. (Ad esempio, utilizza STRING_TEMPLATE const.) Il tuo test si preoccupa del fatto che quando tu:

void Test() {
  DoSetup(...);
  ActualResult = DoProcess(...);
  Check(ActualResult == "/some/constant/string/with/1234/that/needs/interpolation/");
}

Il fatto che "/ some / constant / string / with / 1234 / that / needs / interpolation /" sia simile a STRING_TEMPLATE dovrebbe essere considerato casuale, non una violazione di DRY.

NOTE: This of course doesn't apply if you're actually testing some localisation aspect of your system, or if your system is affected by localisation that you initially set up via STRING_TEMPLATE. Because then the duplication is explicit.

Prima di tutto nel tuo esempio, stai effettivamente testando due cose in un singolo test, un test unitario dovrebbe testare solo una cosa alla volta.

Cosa dovresti provare:

1. il valore costante è nel formato o un URL corretto con una singola posizione jolly % .
2. la sostituzione della stringa all'interno della funzione build_url produce effettivamente un URL valido dato un input valido per la funzione

inoltre dovresti testare

1. la costante non riesce a convalidare il valore costante se non è un pattern URL valido con una posizione % (e tutte le mutazioni di questo)
2. la sostituzione delle stringhe all'interno della funzione non riesce a creare URL validi con input non valido

Questi dovrebbero essere due test unitari separati.

Di solito preferisco specificare manualmente il risultato previsto. Sebbene sia improbabile che l'interpolazione della stringa nell'esempio si interrompa, potrebbe esserci un caso in cui si utilizza una libreria di terze parti per creare il risultato. L'uso dei risultati manuali rivelerà le incompatibilità di versione in queste librerie. Inoltre, c'è sempre il pericolo di strane circostanze ambientali che potrebbero interrompere la funzione, come le impostazioni locali, la codifica, le piattaforme a 32/64 bit o simili. A volte, quelli effettivamente rompono la funzione. Altre volte, hanno appena superato i test unitari con i risultati digitati manualmente. In entrambi i casi, vale la pena controllare.

Se si testano le funzioni senza effetti collaterali, è possibile utilizzare test basati sui dati, che consente di mantenere uniti gli input di test e le uscite previste.

Tuttavia, nel tuo particolare esempio, potrebbe essere una buona idea non codificare il URL_TEMPLATE , ma leggerlo da qualche file di configurazione. Ciò faciliterà la transizione tra diversi ambienti.

Questo è un buon candidato per "Cose che non dovrebbero essere testate da unità".

Quale logica aziendale stai testando?

Che la costante è impostata correttamente? Il test sta semplicemente ripetendo il codice (che è un segno che non dovresti testarlo).

Che la lingua sta facendo correttamente la sostituzione delle stringhe? Non è compito tuo testare la lingua.