2009-11-09 30 views
10

Possiedo un codice di base legacy C++ con 10-15 applicazioni, tutte in condivisione di più componenti.Test unitario. Struttura file

Durante l'impostazione di unittests per i componenti condivisi e per le applicazioni stesse, mi chiedevo se ci sono strutture di file accettate/comuni per questo.

Poiché i miei test di unità hanno diverse classi di base per semplificare le impostazioni di test specifiche di progetto/cliente, ci sono molti file comuni per tutti i test.

Per me sembra naturale creare una nuova directory che contenga tutti i file relativi ai test, i mock, ecc. Per avere tutto centralizzato, e anche mantenere le definizioni relative ai test dai file make principali.

D'altra parte, vedo che è prassi comune che i file di test risiedano insieme ai file di codice testati.

C'è un modo più o meno accettato di farlo?

risposta

4

Fuori dagli occhi, lontano dalla mente; se si conservano i file di test insieme ai file di codice, agli sviluppatori potrebbe essere più ovvio che quando aggiornano un file di codice devono aggiornare anche i test.

2

Come notato, esistono due metodi comuni per individuare i file di test delle unità: accanto al codice di implementazione che stanno testando e in una gerarchia di file separata. La scelta è una questione di ciò che è la pratica comune nella tua organizzazione e il gusto personale.

Per quanto riguarda l'ubicazione del codice di test comune, è sufficiente organizzare il codice di test per organizzare il codice di implementazione.

Nel caso specifico, se alcune infrastrutture di test sono comuni a più componenti indipendenti, sarebbe una buona idea creare un nuovo componente (chiamarlo "testing", ad esempio) da cui dipendono altri componenti per i test, invece di aggiungere dipendenze tra componenti esistenti.

2

Io di solito organizzo tale codice in una struttura di file che sembra (in un caso semplice) come questo:

apps 
    app1 
     app1module1 
     app2module2 
     app1tests 
    app2 
     app2module1 
     app2tests 
components 
    comp1 
     comp1module1 
     comp1module2 
     comp1tests 
common_test_stuff 

Non esiste un unico modo giusto per fare questo, ma questo sembra essere una pratica comune che mantiene separato il codice di produzione e di prova e tenta di rimuovere il problema non visibile (citato da zac) allo stesso tempo.

+0

'app2module2' dovrebbe essere' app1module2'. – Etherealone

1

Tieni il codice di prova vicino al codice prodotto e disponi il tuo Makefile (o qualsiasi altra cosa tu stia utilizzando) in modo che i test vengano compilati contemporaneamente al test, per renderli visibili, specialmente se non tutti nel la squadra sta scrivendo dei test.