Quanto ridondante dovrebbero essere i miei test?

Question

Quanto ridondante dovrebbero essere i miei test?

#1 da (6 voti)
#2 da (1 voti)

2

Questo è qualcosa con cui spesso faccio fatica a testare, ma non riesco mai a trovare una risposta canonica o ragionevole a

.

Scenario semplice

Una funzione, f() , prende un file, lo elabora e restituisce il file elaborato. f() ha test unitari per verificare che si comporti come previsto.

Un'interfaccia della riga di comando (CLI) accetta un percorso file come input e utilizza f() per elaborare il file corrispondente.

Come dovrei testare la CLI? Passandogli un percorso e assicurandoti che gestisca quel percorso, indipendentemente dal fatto che il file esista o meno, è logico, ma passando quel file a f() e controllando l'output è esattamente quello che sto facendo nei test unitari per f() . È ridondante e il doppio del lavoro. Inoltre, mantenere i test quando la funzione cambia è il doppio del lavoro di nuovo.

Nota: f() può essere ovunque - in una libreria che qualcun altro ha scritto, per esempio, o parte dell'intero programma stesso. Sto cercando di capire le best practice in (non) testare in modo ridondante le funzionalità, non solo in questo piccolo esempio.

testing

posta Jamie Schembri 06.08.2014 - 14:09

fonte

2 risposte

1

How should I test the CLI?

In generale, lascio la verifica dell'interfaccia utente all'utente o di qualche sostituto / avvocato per l'utente (persone QA). Se ci sono funzioni di utilità per dire ... analizzare gli argomenti della riga di comando, allora vorrei testare quelli.

Se la funzione di wrapping non è un'interfaccia utente, probabilmente dovrebbe prendere f() come parametro / strategia. A quel punto, è banale testare che il wrapper chiama f() , senza in realtà re-testare f() . Per un'interfaccia utente, penso che sia eccessivo.

risposta data 06.08.2014 - 15:14

fonte

Leggi altre domande sui tag testing

Creazione di un'interfaccia nella libreria standard di una lingua? Struttura del database per vari elementi

score 6 · Accepted Answer

Supponendo che la CLI sia un wrapper che analizza gli argomenti della riga di comando e li passa a f () e fa qualcosa con i risultati, l'unit test per la CLI sarebbe che analizza correttamente gli argomenti della riga di comando e i marshals gli argomenti della funzione per f (), e che i risultati sono correttamente 'usati' (comunque è definito).

Se f () fa il file system o l'accesso alla rete, probabilmente vorrai simulare / inserire uno stub di test per f () che verifica che gli argomenti siano come previsti, che fornisca valori restituiti da f ().

Uno dei vantaggi dei moduli / della scomposizione è il rinvio alla responsabilità del modulo per l'adempimento del contratto. È tua responsabilità scegliere saggiamente i moduli. Che il modulo / funzione a cui ci si sta rimettendo abbia dei test unitari è un punto a favore della fiducia e del suo utilizzo, tuttavia, vorrei davvero vedere che i test sono in realtà dei BUONI test. :)