Unit test markup building logic

Question

Unit test markup building logic

#1 da (2 voti)
#2 da (0 voti)

4

Attualmente sto scrivendo una libreria di funzioni di supporto per produrre dei markup ripetitivi. Ho un riferimento al markup che le funzioni dovrebbero produrre, ma sono curioso di sapere come dovrei fare per testare questa unità?

Ci sono molti test unitari necessari per ottenere una copertura completa del numero di diverse variazioni di output da ciascuna funzione. Attualmente, ho un modello T4 per ogni funzione che costruisce test unitari per ogni combinazione di input per quella funzione.

Ogni test unitario fa un singolo assert contro una stringa contenente il markup di riferimento. Tuttavia, scrivere questi singoli bit di markup a mano richiederebbe molto tempo, quindi ho scritto un'altra piccola funzione di supporto che replica sostanzialmente la stessa logica che sto testando, ma in modo meno flessibile, per produrre la stringa attesa.

Mi sembra che questa potrebbe non essere la migliore idea? O questo è un approccio OK a questo tipo di problema? Quali sono le migliori pratiche che lo circondano?

Esempio di test unitario

[TestMethod]
public void Function_P1_P2_P3()
{
    string markup = HelperLib.MakeMarkup(P1, P2, P3);
    Assert.AreEqual(this.MakeExpectedString(P1, P2, P3), markup);
}

unit-testing programming-practices

posta Andy Hunt 17.01.2013 - 21:10

fonte

2 risposte

0

Potresti analizzare il markup generato e assicurarti che struttura / contenuto corrisponda a ciò che dovrebbe risultare dagli argomenti che hai passato quando hai eseguito il metodo.

Sembra che questo potrebbe essere usato per valutare in modo un po 'programmatico tutte le diverse variazioni (a seconda di quanto cambia il markup per argomenti diversi), ma scommetto che sarà un po' più di lavoro che comparare le stringhe. ;)

risposta data 17.01.2013 - 21:54

fonte

Leggi altre domande sui tag unit-testing programming-practices

I metodi dovrebbero sempre tornare da un posto? [duplicare] Integrazione informatica con la regola trapezoidale

score 2 · Accepted Answer

Quello che potrei considerare è la scomposizione della logica che genera il markup in unità più piccole, che è possibile testare in modo più granulare. Sembra davvero che tu stia descrivendo più di un test di integrazione concettuale - "Ecco uno schema per generare un grosso pezzo di markup che voglio generare e sto testando che è lo stesso di questo schema leggermente diverso per generare quel grosso pezzo di markup. "

Quello che ti suggerisco di testare con un unit test ha più di una narrazione come "Voglio testarlo quando passo x per P1, succede questa cosa specifica". Ora farlo potrebbe comportare la decomposizione. Ad esempio, se ho un metodo GenerateTable (), un metodo GenerateTableRow () e un metodo GenerateTableCell (), potrei avere un test che dice "quando passo foo a GenerateTableCell () torno indietro <td>foo</td> ". Poi hai un altro metodo che assembla le celle in righe e righe in tabelle e stai testando su ogni livello crescente di astrazione.