TDD Duplica test su classi correlate

2

Seguendo il principio di testare solo le funzioni esportate su un pacchetto (usando Go - o per altre lingue, le funzioni pubbliche su una classe), sto correndo in uno scenario in cui i pacchetti correlati stanno causando il codice base testato più volte.

Ad esempio, ho un Preprocessore che chiama un pacchetto parser, che chiama un pacchetto scanner che chiama un pacchetto Lexer.

Preprocessore - > Parser - > Scanner - > Lexer

I risultati risalgono al pacchetto precedente e i risultati finali sono compilati nel preprocessore. Nessun pacchetto sotto il Preprocessore viene chiamato da nessun'altra parte dell'app.

Ogni pacchetto ha test, il che significa che il lexer è testato 4x, lo scanner 3x, il parser 2x e il preprocessore 1x.

Credo che ogni caratteristica dovrebbe essere il suo pacchetto separato perché se le ho combinate tutte in un unico pacchetto Preprocessore, parser, scanner e lexer non hanno bisogno di un'API pubblica, tuttavia la funzionalità è troppo complessa per non essere testata individualmente sarebbe difficile rintracciare dove si stavano verificando errori.

Questo tipo di test sui duplicati è raccomandato o è un segno che i pacchetti sono troppo correlati per essere separati? Oppure, è un segno che i pacchetti di livello inferiore stanno facendo troppo e dovrei estrarre più logica di business nel pacchetto Preprocessor in modo che possa chiamare ciascuno dei pacchetti di livello inferiore, invece di avere le loro richieste concatenate?

    
posta Andy Brewer 10.09.2015 - 01:57
fonte

1 risposta

3

Una tecnica per evitare questo - se è in realtà un problema per il tuo progetto - è usare i mock. Lo scanner, per esempio, sarebbe stato testato con un finto Lexer; il parser con uno scanner fittizio, ecc. In questo modo il tuo Lexer effettivo viene esercitato solo dai test Lexer.

    
risposta data 10.09.2015 - 02:24
fonte

Leggi altre domande sui tag