Come iniziare a scrivere test di unità per un'applicazione legacy Embedded C - moduli strettamente accoppiati?

Question

Attualmente sto lavorando su un codice base, su cui non sono mai stati scritti test di unità. È stato scritto per un processore Embedded a 16 bit, e vorrei iniziare ad aggiungere test di unità per tutto il codice che scrivo, come minimo e quindi estenderlo ad altre parti del codice.

Il mio problema con questo è, ho trovato che ogni modulo (file. C) a livello di applicazione, sembra essere strettamente accoppiato ad altri file C nel progetto. Per ogni file dato, questo può essere ovunque da 2 a 10 file.

1. Come si inizia a scrivere i test di unità?
2. Quali sono i modi migliori/rapidi/più efficienti per rimuovere questo accoppiamento stretto?
3. Anche i test delle unità verranno eseguiti sul PC (32 bit) e il codice incorporato è per un processore a 16 bit. Come faccio a garantire che questo venga risolto quando si trasferisce il codice sul PC?

Answer 1

Per quanto riguarda # 3 - assicurandosi che è portatile al PC, ecco la strategia che uso:

In primo luogo, passare attraverso il codice embedded e cambiare qualsiasi 'int' o 'unsigned long' a 'Int16' o 'uint32' (o qualsiasi altra convenzione tu scelga).

Avvolgere la sezione nell'intestazione incorporato in cui si definiscono i tipi all'interno di una condizione:

#ifndef CORE_TYPE_DEFINITIONS 
#define CORE_TYPE_DEFINITIONS 
typedef long int16; 
/*...*/ 
#endif 

creare un file "PC_Types.h" che definisce gli stessi tipi per il PC.

#ifdef CORE_TYPE_DEFINITIONS 
#error "Core Types already defined" 
#else 
#define CORE_TYPE_DEFINITIONS 
typedef short int16; 
/*...*/ 
#endif 

Nel progetto PC, creare un wrapper per ogni file embedded C, che contiene quanto segue:

#include "PC_Types.h" 
#include "ModuleX.c" //the file under test 

#include "TestHarness.h" //verification functions 

int TestModuleXUnit1(void) 
{ 
    /* setup */ 
    /* call Unit1(); */ 
    /* verify post-conditions */ 
    return result; 
} 

Avvolgendo ogni file, hai tutte le funzioni accoppiati a disposizione, se necessario. #includendo il file sorgente originale nel file wrapper consente di inserire aggiornamenti del codice incorporato direttamente dal sistema di controllo del codice sorgente senza alcuna modifica. Aggiungendo le funzioni di test dopo l'origine inclusa, il codice di test ha pieno accesso a tutte le funzioni del modulo, anche se non hanno un'intestazione pubblica.

Answer 2

Vorrei iniziare rileggendo Michael Feathers' Working Effectively with Legacy Code.