Unit Wrapper Test (Facciata?) Metodo

Question

Unit Wrapper Test (Facciata?) Metodo

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

1

Devo scrivere test unitari per alcune classi che il mio gruppo sta sviluppando. Le lezioni sono abbastanza semplici e non sono sicuro di come migliorarle.

public class MyObjectRegistry
{
    private myDataSetMapper = new MyDataSetMapper();

    public boolean StoreObjects(list<MyObject> myObjectList)
    {
        myDataSetMapper.StoreObjects(myObjectList);
    }
}

public class  MyDataSetMapper
{
    public boolean StoreObjects(list<MyObject> myObjectList)
    {
        for(MyObject myObj: myObjectList)
        {
            boolean result = StoreObject(myObj);
        }
    }

    private boolean StoreObject(MyObject myObject)
    {
        //Store the object in a database
    }
}

Quindi la mia domanda è come testare i metodi MyObjectRegistry.StoreObjects e MyDataSetWrapper.StoreObjects poiché non esiste una logica reale diversa da un ciclo foreach e chiamando ad un altro metodo.

Mi sono guardato intorno alla rete e ho scoperto che penso stia osservando una classe / metodo di "facciata", ma non sono ancora chiaro su cosa dovrei testare / affermare nel metodo di prova.

testing unit-testing java

posta DaveH 25.11.2013 - 18:43

fonte

3 risposte

0

Il problema che stai affrontando è il risultato di un design di classe "cattivo". Specificamente MyObjectRegistry non è stato progettato per facilitare il test delle unità. Fortunatamente, la riflessione ti consente di impostare i valori privati delle classi.

Ecco cosa farei nella tua situazione:

Crea una versione finta di MyObjectRegistry; probabilmente usando una lista, una mappa o, forse, una mappa di elenchi ojects.
All'inizio del test di junit (magari nella configurazione della classe) crea un'istanza MyObjectRegistry quindi imposta il membro myDataSetMapper alla versione fittizia della classe MyDataSetMapper.
Richiama il metodo storeObjects, quindi verifica che i valori passati al metodo storeObjects siano stati aggiunti all'oggetto MyObjectRegistry simulato.

Supponendo che il codice di accesso al database non sia all'interno del metodo MyDataSetMapper.storeObject (), fare la stessa cosa per MyDataSetMapper con un oggetto di accesso ai dati fittizio.

risposta data 25.11.2013 - 20:06

fonte

0

Il problema è che MyObjectRegistry crea un nuovo MyDataSetMapper , invece di iniettare quella dipendenza. L'apparenza di "nuovo" crea una dipendenza dura e in fase di compilazione su MyDataSetMapper . Ci sono due modi per andare:

Utilizzare un'utility reflection (come ReflectionTestUtils) per impostare forzatamente tale variabile su un'istanza fittizia di MyDataSetMapper. Che schifo!
Cambia la classe in modo che invece di istanziare MyDataSetMapper , venga iniettata come dipendenza invece:

public MyObjectRegistry (MyDataSetMapper mapper) { this.myDataSetMapper = mapper; }

Ora è possibile creare un'istanza del registro con un'istanza fittizia inserita, e si sta testando l'unità sotto test (l'oggetto del registro) e non il MyDataSetMapper.

Se MyDataSetMapper parla direttamente al database, non ha senso testarlo da solo, poiché è per sua natura un oggetto di integrazione. Puoi verificarlo nei test di integrazione, o semplicemente eseguendo ed esercitando l'applicazione.

risposta data 25.04.2014 - 07:44

fonte

Leggi altre domande sui tag testing unit-testing java

Come descrivere Importa un'azione di file nel diagramma Sequenza Qualcuno potrebbe aiutarmi a capire la crittografia del database SQL TDE?

score 1 · Accepted Answer

Quindi i test unitari sono lì per testare la logica, non l'impianto idraulico. Non hai alcuna logica nel tuo esempio (anche se piccolo), quindi è necessario testare il dosaggio.

In generale dovrebbe essere ovvio ciò che è necessario testare in un metodo poiché fa una cosa e il suo nome ti dice cosa fa. In caso contrario, dovresti cercare di suddividere il tuo codice in componenti più piccoli.