Geek Answers Handbook

How to start writing unit tests for an outdated Embedded C application - very closely related modules?

I am currently working on a code base on which there have never been any unit tests. It was written for a 16-bit embedded processor, and I would like to start adding unit tests for all the code that I write, at a minimum, and then distributing it to other parts of the code.

My problem is that I found that each module (.c file) at the application level seems to be closely related to other C files in the project. For any given file, it can be from 2 to 10 files.

  • How do I start writing unit tests?
  • What are the best / fastest / most effective ways to eliminate this tight connection?
  • In addition, unit tests will be performed on a PC (32 bit), and embedded code for a 16-bit processor. How can I guarantee that this will take care of porting the code to the PC?
+7
c unit-testing embedded
source share
2 answers

Regarding # 3 - making sure that it is transferred to the PC, here is the strategy I use:

First go through the inline code and change any 'int' or 'unsigned long' to 'int16' or 'uint32' (or any other convention you choose).

Wrap the section in the inline header, where you define the types inside the condition:

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

create the file "PC_Types.h", which defines the same types for PC.

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

In the PC project, create a shell for each embedded c file that contains the following:

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

Wrapping each file, you have all the related functions available as needed. # including the original source file in your shell file, you can opt out of firmware updates directly from your version control system without any changes. Adding test functions after turning on the source gives the test code full access to all functions of the module, even if they do not have a public header.

+4
source share

I would start by re-reading the Michael Persian Effect with legacy code .

+4
source share

More articles:


All Articles