È considerata una cattiva pratica di codifica scrivere metodi / proprietà che supportano (solo) test? [duplicare]

Question

È considerata una cattiva pratica di codifica scrivere metodi / proprietà che supportano (solo) test? [duplicare]

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

3

Quando scrivo (unit) i test cerco sempre di evitare ad esempio i falsi di microsoft perché poi la funzione di modifica e continua non funziona più. Tuttavia questo spesso richiede il refactoring ... e talvolta metodi o proprietà che esistono solo per supportare i test (unit). Un esempio:

Con i falsi che potrei fare in ogni metodo di prova semplicemente questo:

ShimMyClass.InitializedGet = () => false;

ma senza falsi ho bisogno di scrivere un internal metodo ResetInitialized() visibile solo all'assembly test (unit).

Come:

Non renderò pubblici i metodi privati per supportare i test delle unità, ma li scriverò solo per i test delle unità. Tali metodi non avrebbero altri compiti ma essere chiamati in un test unitario. ResetInitialized non verrebbe mai chiamato durante un normale flusso di lavoro ma solo da un test unitario.

In altre parole: se non avessi creato il test unitario non avrei mai dovuto scrivere questo metodo / proprietà di supporto aggiuntivo. Non sarà mai chiamato da nessun'altra cosa che un test unitario.

Esempio

Ho una classe che inizializzo quando l'applicazione si avvia e le successive inizializzazioni sono saltate. L'inizializzazione avviene internamente quando viene utilizzata la prima funzione . In questo caso non sono in grado di testare più di un test case alla volta. Devo essere in grado di resettarlo per far funzionare automaticamente i test.

Sarebbe male renderlo in realtà anche ripristinabile ma l'unico utente di questa funzione sarebbe il test unitario?

unit-testing c# programming-practices

posta t3chb0t 06.11.2015 - 13:50

fonte

3 risposte

Leggi altre domande sui tag unit-testing c# programming-practices

Mantenimento di una linea di progetto principale con progetti satellite Implementazione logica di coupon "compra uno prendi due gratis" per il carrello

score 2 · Answer 1

In other words: if I didn't create the unit test I would never have to write this additional helper method/property. It will never be called by anything other then a unit test.

Una risposta rapida: dovresti non modificare il codice sorgente per soddisfare i tuoi test.

Inoltre, regola empirica: se un pezzo di codice / metodo / classe / funzionalità non verrà mai chiamato, rimuovilo. Non commentare, non renderlo privato - rimuovilo.

Tuttavia, è perfettamente corretto scrivere nuovi mock / stub o metodi falsi nei test che potrebbero riconoscere / sovraccaricare / sostituire la funzionalità originale.

Il test / l'implementazione dovrebbe seguire la regola 80/20, il che significa che approssimativamente l'80% del tuo tempo di sviluppo continuerà a scrivere test (unità, intergrazione, end-to-end, chiama qualsiasi ..) Ed è del tutto ovvio che se tu stai modificando l'interfaccia dei tuoi metodi, quindi dovrai aggiornare i tuoi fakers o la struttura di test delle unità.

score 2 · Answer 2

Un'altra risposta: sì , devi assolutamente modificare il codice sorgente per soddisfare i tuoi test.

Il test soddisfa la funzione di migliorare e mantenere la qualità della base di codice. Pertanto, rendere i test più facili, o possibili, da scrivere, è un obiettivo valido con un valore aziendale positivo, proprio come scrivere codice commerciale. È logicamente incoerente passare il tempo a scrivere test e contestualmente sostenere che è mai giustificabile cambiare codice aziendale per il bene della suite di test.

Come sempre, questa è una questione di compromessi. Ovviamente non si dovrebbe rendere il codice molto meno gestibile per un piccolo miglioramento nella scrittura del test. Ma un'espansione piccola o nulla del codice aziendale per un grande miglioramento nella scrittura di prova può essere assolutamente giustificata.

Molti sviluppatori commettono l'errore di pensare che, poiché il codice di prova non viene spedito al cliente, in qualche modo non fa realmente parte della base di codice e non è necessario che sia scritto e affidabile come il codice aziendale. Questo non potrebbe essere più sbagliato; facciamo test solo perché ci aiuta a creare programmi migliori, quindi non può avere valore zero - altrimenti sarebbe negligente da parte nostra scrivere qualsiasi test.

score 2 · Answer 3

Devi rendere il tuo codice testabile. Questa è la regola numero uno. Qualcos'altro sta assecondando la plebaglia che dice: "non abbiamo bisogno di test pessimi".

Se hai bisogno di reinizializzare qualcosa, c'è la possibilità che il ciclo di vita per il tuo codice sotto test sia il problema. Quando crei una nuova istanza di oggetto, non si inizializza in modo pulito allo stato desiderato?

Se si dispone di uno stato nascosto, potrebbe essere necessario aggiungere variabili di monitoraggio dello stato che vengono utilizzate solo per il test.