Как начать писать модульные тесты для унаследованного приложения Embedded C - очень тесно связанных модулей? - PullRequest
Новая
       7

Как начать писать модульные тесты для унаследованного приложения Embedded C - очень тесно связанных модулей?

7 голосов
/ 28 июня 2010

В настоящее время я работаю над базой кода, на которой никогда не было написано никаких модульных тестов.Он был написан для 16-разрядного встроенного процессора, и я хотел бы начать как минимум добавлять модульные тесты для всего кода, который я пишу, а затем распространить его на другие части кода.

Моя проблема с этим заключается в том, что я обнаружил, что каждый модуль (файл .c) на уровне приложения, похоже, тесно связан с другими файлами C в проекте.Для любого данного файла это может быть где-то от 2-10 файлов.

  1. Как мне начать писать модульные тесты?
  2. Каковы наилучшие / быстрые / наиболее эффективные способы удаления этой жесткой муфты?
  3. Также на ПК будут выполняться модульные тесты (32-разрядные), а встроенный код предназначен для 16-разрядного процессора.Как убедиться, что об этом позаботятся при переносе кода на ПК?

Ответы [ 2 ]

4 голосов
/ 29 июня 2010

Относительно № 3 - убедившись, что он переносим на ПК, вот стратегия, которую я использую:

Сначала просмотрите встроенный код и измените любое значение int или unsigned long на int16. или 'uint32' (или любое другое соглашение, которое вы выберете).

Обертка раздела во встроенном заголовке, где вы определяете типы внутри условия: 

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

создайте файл "PC_Types.h", который определяет те же типы для ПК. 

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

В проекте для ПК создайте оболочку для каждого встроенного файла c, которая содержит следующее: 

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

Оборачивая каждый файл, вы получаете все связанные функции, доступные по мере необходимости. # Включение исходного файла исходного кода в файл оболочки позволяет добавлять обновления встроенного кода непосредственно из системы контроля версий без каких-либо изменений. Добавление тестовых функций после включенного источника дает тестовому коду полный доступ ко всем функциям модуля, даже если у них нет открытого заголовка.

4 голосов
/ 28 июня 2010
...