Considera una suite di test come questa:
public class MyTestSuite {
@Test
public void test_something() {
testHelperMethod("value11", "value12", "value13");
}
@Test
public void test_something_else_meaningful_name() {
testHelperMethod("othervalue21", "othervalue22", "othervalue23");
}
// ...
private void testHelperMethod(String value1, String value2, String value3) {
// set up part (independent of value1, value2, value3)
// action part (dependent on values)
// assertion part (dependent on values)
// tear down part (independent of values)
}
}
In altre parole, tutti i casi di test sono eseguiti tramite un singolo metodo di supporto parametrizzato, che è strutturato secondo lo schema arrangement-act-assert. I test case chiamano questo metodo con vari parametri, in base a cosa esattamente deve essere testato.
Domanda : qual è lo svantaggio, se esiste, di strutturare i test come questo, e questo (anti?) - pattern ha un nome comune?
Commento
-
Ho provato a utilizzare Google per un lungo periodo, tra cui su SO e sul blog , ma non sono riuscito a trovare nulla di utile fino ad ora.
-
Questo domanda è la più vicina che ho trovato, ma le risposte qui affrontano altri aspetti / problemi, ovvero:
- asserzioni / codice di installazione mescolato (non è il caso qui, come tutto le asserzioni sono alla fine del metodo helper)
- più asserzioni per test (anche nel mio esempio, ma penso che questo sia un problema non correlato)
- la responsabilità del metodo helper non è chiara: penso al mio case è chiaro, solo che è diverso da quello "tradizionale"
-
Per essere più precisi, la parte di asserzione in
testHelperMethod
è anche un metodo di utilità separato (chiamato con molti parametri), ma immagino che non sia molto importante per la domanda. (I.e: perché è una cattiva pratica delegare i test ai metodi di supporto, se non del tutto?) -
Nel caso questo sia importante, si tratta di un test di integrazione, ma sospetto che la risposta sia la stessa anche per i test unitari.
EDIT : ha cambiato il nome dei casi di test per evitare confusione (in precedenza erano chiamati test1
, test2
. Infatti, i test nel progetto nelle domande hanno nomi significativi , Avevo appena realizzato questa semplificazione.)