Test di integrazione, ma quanto?

8

Un recente dibattito all'interno del mio team mi ha fatto meravigliare. L'argomento di base è che quanto e cosa copriremo con test funzionali / di integrazione (certo, non sono gli stessi ma l'esempio è fittizio dove non ha importanza).

Diciamo che hai una classe "controller" come:

public class SomeController {
    @Autowired Validator val;
    @Autowired DataAccess da;
    @Autowired SomeTransformer tr;
    @Autowired Calculator calc;

    public boolean doCheck(Input input) {
        if (val.validate(input)) {
             return false;
        }

        List<Stuff> stuffs = da.loadStuffs(input);
        if (stuffs.isEmpty()) {
             return false;
        }

        BusinessStuff businessStuff = tr.transform(stuffs);
        if (null == businessStuff) {
            return false;
        }

       return calc.check(businessStuff);
    }
}

Abbiamo bisogno di un sacco di test delle unità (ad esempio, se la convalida fallisce, o nessun dato in DB, ...), è fuori questione.

Il nostro problema principale e su cosa non possiamo essere d'accordo è che quanti test di integrazione lo devono coprire: -)

Sono dalla parte che punteremo a meno test di integrazione (test piramide). Quello che vorrei coprire da questo è solo un singolo percorso felice-infelice in cui l'esecuzione ritorna dall'ultima riga, solo per vedere se metto insieme queste cose non esploderà.

Il problema è che non è così facile capire perché il risultato del test è falso, e questo fa sentire a disagio alcuni dei ragazzi (ad esempio, se controlliamo solo il valore restituito, è nascosto che il il test è verde perché qualcuno ha cambiato la validazione e restituisce false). Certo, sì, possiamo coprire tutti i casi, ma quello sarebbe un pesante effetto eccessivo.

Qualcuno ha una buona regola empirica per questo tipo di problemi? O una raccomandazione? Lettura? Parlare? Post sul blog? Qualcosa sull'argomento?

Grazie mille in anticipo!

PS: Sry per l'esempio brutto, ma è piuttosto difficile tradurre una parte di codice specifica in un esempio. Sì, si può discutere di lanciare eccezioni / usare un tipo diverso di ritorno / ecc. ma la nostra mano è più o meno vincolata a causa di dipendenze esterne.

PS2: ho spostato questo argomento da SO qui (domanda originale, contrassegnata in attesa )

    
posta rlegendi 28.02.2017 - 08:45
fonte

2 risposte

6

C'è una scuola di pensiero che mette seriamente in dubbio il valore dei test di integrazione.

Ho il sospetto che tu abbia un ampio spettro di risposte qui, ma a mio avviso dovresti usarle solo quando forniscono un valore chiaro.

In primo luogo, dovresti scrivere quanti più test di unità puoi, perché a) sono economici e b) potrebbero essere gli unici test eseguiti sul server di build (se ne hai uno).

Si è tentati di scrivere test lato client per verificare il database o qualche altro livello, ma questi dovrebbero realmente accadere al livello appropriato, se possibile, piuttosto che inventare un test di integrazione. Ovviamente questo può richiedere alcune basi sotto forma di interfacce, ecc. Per ottenere il mocking e cose simili.

Considera anche lo scopo dei tuoi test. Se stai semplicemente scrivendo un test di integrazione per coprire ciò che accade comunque quando la tua suite viene eseguita o duplicando un test del fumo, allora questo ha un valore limitato. Inoltre, pensate se più la registrazione in posti pertinenti sarebbe un'opzione migliore piuttosto che ottenere un messaggio oscuro da una dozzina di componenti interconnessi e dover rintracciarlo attraverso.

Quindi, supponendo che tu abbia deciso di scriverne un po ', devi pensare a quando scapperanno. Se riescono a cogliere qualche brutto problema, allora è grandioso, ma questo diventa piuttosto inutile se gli sviluppatori non si ricordano mai di eseguirli.

Infine, i test di integrazione sono una sostituzione assolutamente inadatta ai test sul fumo e ai test degli utenti. Se ti preoccupi con loro, dovrebbero costituire una piccola parte di un processo di test ben progettato.

    
risposta data 28.02.2017 - 14:17
fonte
8

Contrariamente a questa risposta , trovo che i test a diversi livelli siano parte importante del processo di test del software. Unità, funzionalità, integrazione, fumo, accettazione e altri tipi di test stanno testando cose diverse, e più siamo meglio è.

E se riesci ad automatizzarli, possono essere eseguiti come lavori di integrazione continua (come jenkins). Nessuno ha bisogno di eseguirli per vedere se si sono rotti, dal momento che tutti possono vedere se i test falliscono.

Nei miei test di integrazione, non approfondisco i dettagli: i dettagli e i casi d'angolo sono per i test unitari. Quello che provo è solo la funzionalità principale, passando tutti i parametri corretti. Ciò significa, nel tuo esempio, nei test di integrazione, non coprire i falsi percorsi.

    
risposta data 02.03.2017 - 14:51
fonte