Unit test side-codice pesante

10

Sto iniziando a scrivere codice C ++ per far funzionare un robot, e non so come incorporare i test di unità, se davvero posso. Mi è stata fornita una libreria che consente la creazione di "comandi" per il robot, che sono automaticamente programmati ed eseguiti. Il meccanismo per creare questi comandi consiste nel sottoclasse una classe di base di comandi che forniscono e implementa metodi virtuali void Initialize() , void Execute() e void End() . Queste funzioni vengono eseguite esclusivamente per i loro effetti collaterali, che fanno cose al robot (far funzionare i motori, estendere i pistoni, ecc.). Per questo motivo, in realtà non vedo da nessuna parte collegare i test unitari al codice, a meno di deridere l'intera libreria in modo da poter controllare gli stati virtuali prima e dopo del robot. C'è un modo per testare ciò che non è eccessivamente oneroso?

Modifica

Penso che possa essere stato fuorviante sulla funzionalità della libreria. La libreria fornisce la maggior parte dell'interfaccia per il robot e il sistema di comando / programmazione, quindi non è così semplice come il mocking della classe base di comando, dovrei prendere in giro l'intera interfaccia con l'hardware. Sfortunatamente non ho il tempo per farlo.

    
posta Will Kunkel 12.12.2013 - 17:18
fonte

2 risposte

7

Quello che farei in questo caso sarebbe introdurre la mia propria interfaccia RobotControl con metodi corrispondenti a quelli nella vera lib.

Dopo aver fatto ciò, vorrei creare una classe RobotControlImpl che implementa questa interfaccia con la vera lib robot.

I comandi che scriverò di conseguenza non estenderanno la classe base, ma opereranno invece sull'interfaccia che hai introdotto.

In questo modo puoi prendere in giro RobotControl, passare la simulazione a qualsiasi comando e verificare che chiami i metodi giusti nell'interfaccia.

In prod passeresti il vero impl di RobotControl ai comandi che hai implementato.

Non sono sicuro se questo è ciò che avevi in mente e considerato ingombrante?

Modifica: Oh, e se ti aspetti che i comandi si addormentino per attendere il completamento (incubo, ma a volte questo è quello che hai), richiederei ai comandi di chiamare un metodo sleep su RobotControl. In questo modo è possibile disabilitare il sonno durante il test e solo verificare che il comando tenti di dormire.

    
risposta data 12.12.2013 - 17:31
fonte
0

Penso sia possibile rendere il codice testabile in un modo minimamente invasivo. Con ciò intendo che è possibile scrivere i comandi esattamente come previsto dagli autori delle librerie di robot. Questo può essere vantaggioso se vuoi scambiare il codice con altri che non usano il tuo livello intermedio.

Richiede una "build test di unità" separata del tuo codice.

Quello che fai è che in un file di intestazione centrale, controlli un tempo di compilazione definisci se questa è la build del test di unità e, in caso affermativo, ridefinisce il nome della classe base e forse alcune altre classi nella libreria del robot per nomi di classi della tua implementazione di test. È necessario definire le stesse funzioni virtuali della lib robot e fornire stub per i metodi che si invocano sul robot.

Poi hai i comandi che puoi lanciare nel tuo framework di test che invoca gli stessi metodi che farebbe la libreria del robot.

Ciò comporterà una certa quantità di stubbing e mocking, ma ciò è inevitabile in qualsiasi progetto di test unitario.

Cambiare il nome della classe base potrebbe essere fatto con un #define o probabilmente preferito, un typedef.

    
risposta data 12.12.2013 - 20:35
fonte

Leggi altre domande sui tag