Come dovremmo verificare che le classi client usino correttamente le loro dipendenze?

Question

Come dovremmo verificare che le classi client usino correttamente le loro dipendenze?

#1 da (1 voti)

1

Nella discussione di J.B. Rainsberger sui test di collaborazione descrive come i test per i "clienti" (utenti di una particolare interfaccia) dovrebbero avere due parti per il loro test.

Il cliente fa le domande giuste dell'interfaccia? Controllato tramite mocking e verifica.
Il client reagisce correttamente quando riceve le risposte? Controllato tramite i valori di ritorno di stub dall'interfaccia.

La mia domanda è in relazione alla parte 1 ("il cliente fa le domande giuste?"). Usa l'esempio che potremmo verificare che il client invii la query corretta a un'interfaccia generica del database. Questo verrebbe verificato verificando una chiamata al metodo su un'interfaccia come query(String qry) . Tutte le informazioni utili sono contenute in un parametro di un metodo di interfaccia.

Questo sembra essere in conflitto con un altro obiettivo dell'uso di livelli di dati collegabili. Immagina un caricatore di record generico che carichi un elenco di stringhe.

public interface RecordLoader {
    public List<String> loadRecords();
}

In questo caso vogliamo avere un FlatFileLoader concreto che carichi i record. Ovviamente non possiamo inserire File nell'interfaccia, perché non sarebbe più possibile implementare un'ipotetica percentuale diDatabaseLoader. Nessun problema, il FlatFileLoader può prendere un File come argomento del costruttore.

public class FlatFileLoader implements RecordLoader {
    public FlatFileLoader(File sourceFile) {
        // ...
    }
}

Ma ora abbiamo creato una lacuna nella nostra copertura di test: il particolare File che viene utilizzato per caricare i record è probabilmente una parte fondamentale della domanda che il client (ad esempio un EmployeeLoader ) sta chiedendo al interfaccia, e non possiamo verificare che questo sia corretto. Siamo stati in grado di farlo nell'esempio del database, favorito dal fatto che la query è una stringa non tipizzata. È il punto che dovremmo creare interfacce ancora più specifiche che prendono parametri ben tipizzati per tutto il loro stato? O dovremmo spingere i dettagli del concreto RecordLoader da qualche altra parte - e in tal caso, dove viene testato?

tdd dependency-injection interfaces

posta amoe 20.10.2017 - 14:01

fonte

1 risposta

Leggi altre domande sui tag tdd dependency-injection interfaces

Esecuzione dei passaggi di verifica CMMI Come posso gestire il multiproduttore a un particolare utente singolo in Kafka?

score 1 · Answer 1

My question is in relation to part 1 ("does the client ask the right questions?"). He uses the example that we could check that the client sends the correct query to a generic database interface. This would be checked by verifying a method call on an interface like query(String qry). All the useful information is contained within a parameter of an interface method.

But this seems to conflict with another goal of using pluggable data layers. Imagine a generic record loader that loads a list of Strings.

Quindi questo layer di dati collegabili è un'altra dipendenza che prendi in giro e controlli che la stringa restituita dal livello di dati inseribile (secondo la parte 2) sia passata a il metodo di interfaccia di database generico (secondo la parte 1).