Sta avendo un test unitario che è per lo più una verifica fittizia un odore?

Question

Ho una classe che collega altri tre servizi, specificamente progettati per rendere l'implementazione degli altri servizi più modulare, ma la maggior parte della mia logica di test delle unità è in fase di verifica fittizia. C'è un modo per ridisegnare per evitare questo?

pitone esempio:

class Input(object): pass 

class Output(object): pass 

class Finder(object): pass 

class Correlator(object): pass 
    def __init__(self, input, output, finder): 
    pass 
    def run(): 
    finder.find(input.GetRows()) 
    output.print(finder) 

Poi deve deridere ingresso, uscita e ricerca. Anche se faccio un'altra astrazione e restituisco qualcosa da Correlator.run(), sarà comunque necessario testarlo come un mock.

Answer 1

Basta chiedere a te stesso: che cosa è esattamente necessario verificare in questo caso di prova particolare? Se questo controllo non si basa su altre classi che non sono fittizie, allora sei OK.

Tuttavia, un sacco di mock è solitamente un odore nel senso che probabilmente stai provando a testare l'integrazione senza effettivamente fare integrazione. Quindi se si assume che se la classe supera il test con i mock, funzionerà correttamente con le classi reali, che sì, è necessario scrivere altri test.

Personalmente, non scrivo molte prove di Unità. Sono uno sviluppatore web e preferisco test funzionali, che testano l'intera applicazione tramite richieste HTTP, come farebbero gli utenti. Il tuo caso potrebbe essere diverso

Answer 2

Non c'è motivo di utilizzare solo il test dell'unità - Forse i test di integrazione sarebbero più utili in questo caso. Inizializza correttamente tutti gli oggetti, usa un po 'la classe principale e asserisci i risultati (possibilmente complessi). In questo modo testerai le interfacce, la prevedibilità dei risultati e altre cose che sono importanti più in alto nello stack. L'ho usato prima e ho scoperto che qualcosa che è difficile da test di integrazione probabilmente ha troppi attributi/parametri o output troppo complicato/formattato erroneamente.

Answer 3

In una rapida occhiata, sembra che il livello di derisione diventi troppo grande. Se sei in un linguaggio dinamico (sto assumendo sì da quando il tuo esempio è in Python), proverei a costruire entrambe le sottoclassi delle classi di produzione con i metodi più problematici sottoposti a override e presentando dati derisi, quindi dovresti ottenere un mix di produzione e codice deriso. Se il percorso del codice non consente l'istanziazione degli oggetti, proverei lo in metodi di sostituzione che restituiscono dati fittizi.

Meteo o meno questo è odore di codice anche in base alla qualità dei dati derisi. Passare a un debugger e copiare i dati conosciuti corretti o annusarli dalla rete è nella mia esperienza il modo preferito per garantirlo.

Il test di integrazione e unità è anche una questione economica: quanto è doloroso sostituire i test di unità con test di integrazione/funzionamento? Maggiore è la scala del tuo sistema, maggiore è il guadagno con il mocking leggero e, quindi, i test unitari.