Va bene testare più file simili in un test funzionale

Question

Va bene testare più file simili in un test funzionale

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

1

Ho un test funzionale con Junit che verifica la consegna del file xml a un end-point. Il file XML viene inviato dal client, quindi l'ho copiato in una cartella di test, letto da lì nel mio test e faccio affermazioni.

Abbiamo 10-20 di questi file con dati diversi ma dello stesso formato, il mio architetto vuole che li copi tutti nella stessa cartella, li analizziamo nello stesso test, giusto per assicurarmi che vengano consegnati con successo. Nota, non sto testando alcuna convalida dei dati in questo test, solo una consegna di successo.

Non sono sicuro che sia una buona idea fare un ciclo di più file in un singolo test nel mio caso, perché se uno fallisce il resto non verrà eseguito e anche non convinto per aver scritto 20 test facendo esattamente la stessa cosa. Si prega di consulenza

unit-testing java functional-testing

posta Charu Khurana 20.11.2013 - 19:00

fonte

3 risposte

1

Se l'obiettivo del test è determinare se il metodo in prova fornirà tutti e 20 i file, allora è un test singolo e dovrebbe essere scritto di conseguenza.

Non sono sicuro che ti comprerebbe molto per dividerlo in 20 test separati, dal momento che stai testando la stessa funzionalità in ciascuno di essi.

risposta data 20.11.2013 - 19:03

fonte

0

Per un test per verificare che tutti i file siano consegnati usa la risposta di Robert Harvey.

Se è necessario eseguire un test con 20 input diversi, utilizzare un fornitore di dati. Non creare loop nel codice ma utilizzare la struttura dei loop con i fornitori di dati in modo da avere meno codice e utilizzare una soluzione standard per il problema.

risposta data 20.11.2013 - 19:37

fonte

Leggi altre domande sui tag unit-testing java functional-testing

Importanza dell'uniformità dell'architettura di sviluppo all'interno del team È consigliabile creare una backdoor per testare un servizio web?

score 3 · Accepted Answer

Come scrivere questo test è più una questione di stile che altro.

Alcuni dicono che ogni metodo di test dovrebbe avere un'unica asserzione, perché questo rende il test molto focalizzato, ed è facile dire rapidamente esattamente cosa non ha funzionato.

Questo mi sembra troppo estremo, quindi potresti seguire la guida del tuo architetto ma rendere il messaggio di errore nella tua asserzione chiaro su quale file ha causato il fallimento del test.

Ancora meglio, per testare tutti i file anche quando uno fallisce, non usare asserzioni per ogni file. Memorizza nella cache il risultato di ogni file nel ciclo di esecuzione e, in caso di errore, invia i dettagli e fallisce il test. Ad esempio:

@Test
public void testAllFiles() {
    final Set<String> failures = new HashSet<>();
    for (File file : getAllFiles()) {
        final Boolean success = processFile(file); // or however you determine success/failure
        if (!success) failures.add(file.getName());
    }

    if (!failures.isEmpty()) {
        log.error("Failed file(s):");
        for (String filename : failures) {
            log.error("\t"+filename);
        }
        fail();
    }
}