Separa i metodi di supporto dalle classi di test?

5

Durante i test, a volte un metodo di supporto può essere utile per attività ripetute, ad es. nella configurazione di prova.

Esempio concreto : Abbiamo alcuni test contro la nostra interfaccia di resto usando% di% della frazione di Spring. Per semplificare, le richieste vengono inviate con l'aiuto di un metodo helper (chiamiamolo metodo RestTemplate per ora), che restituisce gli oggetti dalla risposta.

Questo metodo helper A() sembra inquinare la classe di test, in quanto è un metodo che in realtà non è un test stesso. Avere più metodi di supporto in una classe di test ha un effetto negativo sulla panoramica.

È accettabile creare una seconda classe accanto alla classe di test, che contiene tutto il metodo di supporto? Quali sarebbero le difficoltà se lo facessi? O ci sono altri modi per mantenere una buona panoramica della classe di test?

  • A() - > contenente solo metodi che sono un test attuall
  • MyTestClass - > contenente tutti i metodi di supporto utilizzati da MyTestClassUtil
posta Herr Derb 22.08.2017 - 11:42
fonte

2 risposte

7

Is it acceptable to create a second class next to the test class, which is containing all helper method?

Non con i tutti metodi di supporto, ma con metodi di supporto che vengono utilizzati in più di una classe di test.

Progetta i tuoi test nello stesso modo in cui implementi le classi di business!

Il codice refactore si duplica all'interno di una classe in un metodo locale. Se il metodo viene utilizzato in diverse classi di test, spostalo in una diversa classe helper di test utilizzata da diversi test.

Quindi la mia classe OrderTests ha un metodo locale assertEqual(String message, IOrder expected, IOrder actual) e il mio helper TestDataFactory ha un metodo statico createTestOrder() utilizzato in OrderTests , PriceCalculationTests , PaymentTests , DeliveryTests .

Un test può utilizzare uno o più metodi standard di fabbrica e modificarlo secondo necessità. Esempio:

DeliveryTests.executeOrderWithNoDeliveryAdressShouldThrow() {
    // a valid standard order with one article, user, deliveryadress, ...
    Order sut = TestDataFactory.createTestOrder(); 
    sut.setDeliveryAdress(null); // implements "WithNoDeliveryAdress"

    try {
        sut.execute(); // this should throw
        Assert.fail(); // this should never be reached because of exception.
    } catch(OrderNotCompleteException) {
    }
}
    
risposta data 22.08.2017 - 13:45
fonte
2

Secondo Michael C. Feathers in Funzionante in modo efficace con il codice legacy può creare ciò che ha chiamato Object Seam; Una classe che implementa l'interfaccia che stai testando o che eredita dalla classe che stai testando. in questo caso, non contamina il codice originale con il test dell'unità.

    
risposta data 22.08.2017 - 22:29
fonte

Leggi altre domande sui tag