Wie beginnt man damit, Einheitentests für eine ältere Embedded C-Anwendung zu schreiben - sehr eng gekoppelte Module?

Question

Ich arbeite gerade an einer Codebasis, auf der nie irgendwelche Komponententests geschrieben wurden. Es wurde für einen 16-Bit-Embedded-Prozessor geschrieben, und ich würde gerne beginnen, Komponententests für den gesamten Code, den ich schreibe, mindestens hinzuzufügen und dann auf andere Teile des Codes auszudehnen.

Mein Problem damit ist, habe ich festgestellt, dass jedes Modul (.c-Datei) auf Anwendungsebene scheint eng mit anderen C-Dateien im Projekt gekoppelt werden. Für jede Datei kann dies irgendwo zwischen 2-10 Dateien liegen.

1. Wie fange ich an, die Komponententests zu schreiben?
2. Was sind die besten/schnellsten/effizientesten Möglichkeiten, diese enge Verbindung zu entfernen?
3. Auch die Komponententests werden auf dem PC ausgeführt (32 Bit) und der eingebettete Code ist für einen 16-Bit-Prozessor. Wie stelle ich sicher, dass dies bei der Portierung des Codes auf den PC beachtet wird?

Answer 1

In Bezug auf # 3 - sicherstellen, dass es auf dem PC tragbar ist, hier ist die Strategie, die ich verwende:

Zuerst geht über den eingebetteten Code und ändern Sie jeden ‚int‘ oder ‚unsigned long‘ auf ‚int16‘ oder 'uint32' (oder welche Konvention Sie auch wählen).

Wickeln Sie den Abschnitt im Embedded-Header, wo Sie die Typen innerhalb einer Bedingung definieren:

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

eine „PC_Types.h“ Datei erstellen, die die gleichen Typen für den PC definiert.

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

Im PC-Projekt, einen Wrapper für jede eingebettete c-Datei erstellen, die folgende enthält:

#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; 
} 

Durch jede Datei Umwickeln Sie alle haben zur Verfügung verknüpften Funktionen nach Bedarf. # Mit der ursprünglichen Quelldatei in Ihrer Wrapper-Datei können Sie Aktualisierungen des eingebetteten Codes direkt aus Ihrem Quellcodeverwaltungssystem einfügen, ohne dass Änderungen vorgenommen werden. Durch Hinzufügen der Testfunktionen nach der enthaltenen Quelle erhält der Testcode vollen Zugriff auf alle Funktionen des Moduls, auch wenn sie keinen öffentlichen Header haben.

Answer 2

Ich würde durch erneutes Lesen beginnen Michael Feathers' Working Effectively with Legacy Code.