2014/02: 嵌入式測試驅動開發

嵌入式測試驅動開發
Hugo
2/13/2014

先寫程式，再寫測試找 bug

Test-After Development (TAD)

問題是 ...
沒出錯不知道哪裡有 bug

有什麼方法 ...
能盡早把 bug 找出來 ?

先寫測試找 bug ，再寫程式

Test-Driven Development (TDD)

Test
Driven
Development
測試驅動開發

TDD 循環
• 紅燈：增加一個運行失敗，
甚至無法編譯的測試。
• 綠燈：快速修改，只做能讓
測試通過的工作。
• 黃燈：重構，移除重複改進
代碼可讀性。

《 Test Driven Development: By Example 》

建立
建立

Setup
Setup

運行
運行

Exercise
Exercise

驗證
驗證

Verify
Verify

單元測試四階段

拆卸
拆卸

Teardown
Teardown

自動化單元測試框架
測試案例 #1 測試案例 #2 ...
測試案例 #1 測試案例 #2

report

測試結果 #1
測試結果 #1

測試框架
測試框架

測試結果 #2
測試結果 #2

產品代碼 ((受測代碼 ))
產品代碼受測代碼

...

proj/

fun.c

objs/
projTest/

src/

func.o

src/

funTest.c

objs/

func.o
funcTest.o

目標環境

測試環境

TDD 的好處
•
•
•
•
•
•

產生 bug 更少
除錯時間更短
不會說謊的文件
改善設計
監督進度
內心平靜

嵌入式測試驅動開發
有什麼特別的地方嗎 ?

Code
Code

單元測試
單元測試

運行系統
運行系統

開發環境
開發環境

目標環境
目標環境

雙目標開發 - 解開硬體的依賴

嵌入式 TDD 循環
階段一

階段二

階段三

階段四

階段五

開發環境
TDD

交叉編譯
相容測試

評估版
單元測試

目標硬體
單元測試

目標硬體
驗收測試

很頻繁

不頻繁

《 Test-Driven Development for Embedded C 》

嵌入式驅動開發工具
• Unity
– C 語言自動化測試框架
– 用 Ruby Script 安裝測
試

• CppUTest
– C/C++ 自動化測試框架
– 用 Ruby Script 將測試
轉換成 Unity 測試
Unity http://throwtheswitch.org/, CppUTest http://cpputest.github.io/

範例 - 開發 LED 驅動程式

這玩意我 10 行程式就搞定了

這麼簡單還需要測試嗎 ?
MyLedDriver.c
MyLedDriver.c
#define LED_REGISTER 0x80001234
#define LED_REGISTER 0x80001234
void LedDriver_Set (uint16_t value)
void LedDriver_Set (uint16_t value)
{
{
*((uint16_t *)LED_REGISTER) = value;
*((uint16_t *)LED_REGISTER) = value;
}
}
uint16_t LedDriver_Get (void)
uint16_t LedDriver_Get (void)
{
{
return *((uint16_t *)LED_REGISTER);
return *((uint16_t *)LED_REGISTER);
}
}
LedUser.c
LedUser.c
void TurnOnLed8 (void)
void TurnOnLed8 (void)
{
{
LedDriver_Set (1 << 8);
LedDriver_Set (1 << 8);
}
}

沒有測試把關
再怎麼簡單都可能出錯

先寫出測試失敗的測試
LedDriverTest.c
LedDriverTest.c
TEST (LedDriver, LedsOffAfterCreate)
TEST (LedDriver, LedsOffAfterCreate)
{
{
uint16_t virtualLeds = 0xffff;
uint16_t virtualLeds = 0xffff;
LedDriver_Create (&virtualLeds);
TEST_ASSERT_EQUAL (0, virtualLeds);
}
}
LedDriver.c
LedDriver.c
void LedDriver_Create (uint16_t* address)
{
{
}
}
Dependence Injection ( 依賴注入 )

用最簡單的方式讓測試通過
LedDriver.c
LedDriver.c
{
{
*address = 0;
*address = 0;
}
}

$ make
compiling LedDriver.c
Linking LedDirver_tests
Running LedDriver_tests
.
OK (1 tests, 1 ran, 1 checks, 0 ignored)

再增加一個測試
LedDriverTest.c
LedDriverTest.c
TEST (LedDriver, TurnOnLedOne)
TEST (LedDriver, TurnOnLedOne)
{
{
uint16_t virtualLeds;
uint16_t virtualLeds;
LedDriver_TurnOn (1);
LedDriver_TurnOn (1);
}
}
LedDriver.c
LedDriver.c
void LedDriver_TurnOn (int ledNumber)
{
{
}
}

寫 hardcode 讓測試通過
LedDriver.c
LedDriver.c
static uint16_t* ledsAddress;
static uint16_t* ledsAddress;
{
{
ledsAddress = address;
ledsAddress = address;
*ledsAddress = 0;
*ledsAddress = 0;
}
}
{
{
*ledDriver = 1;
*ledDriver = 1;
}
}
Data Encapsulation ( 資料封裝 )

等等 ! 這不科學啊 ...
hardcode 的實作有問題

增加非當下測試所需的代碼
會降低捕捉各種 bug 的動力

先仿冒再建造
保持小而專注的測試

真正的系統長的像這樣

控制輸入 & 監測輸出

直接輸入

直接輸出

間接輸入

間接輸出

何時使用測試替身 ?
•
•
•
•
•
•

獨立於硬體
注入難以產生的輸入
加速緩慢的合作者
依賴不穩定的事情
取代未被實現的服務
對於難以配置的事物的依賴

測試替身的替換技術
• 編譯時期，透過 Preprocessor 替換
• 連結時期，透過 Object File 替換
• 執行時期，透過 Function Pointer 替換

Test Stub

《 xUnit Test Patterns: Refactoring Test Code 》

FakeTimeService.c
FakeTimeService.c
static int theMinute;
void FakeTimeService_SetMinute (int minute)
void FakeTimeService_SetMinute (int minute)
{
{
theMinute = minute;
theMinute = minute;
}
}
void TimeService_GetTime (Time* time)
void TimeService_GetTime (Time* time)
{
{
time->minuteOfDay = theMinute;
time->minuteOfDay = theMinute;
}
}
FakeTimeServiceTest.c
TEST (FakeTimeService, Set)
TEST (FakeTimeService, Set)
{
{
Time time;
Time time;

}
}

FakeTimeService_SetMinute (42);
FakeTimeService_SetMinute (42);
TimeService_GetTime (&time);
TimeService_GetTime (&time);
LONGS_EQUAL (42, time.minuteOfDay);
LONGS_EQUAL (42, time.minuteOfDay);

FakeTimeService.c
FakeTimeService.c
int FakeTimeService_GetMinute (void)
int FakeTimeService_GetMinute (void)
{
{
return theMinute;
return theMinute;
}
}
void TimeService_SetDay (Time* time)
void TimeService_SetDay (Time* time)
{
{
theMinute = time->minuteOfDay;
theMinute = time->minuteOfDay;
}
}
TEST (FakeTimeService, Get)
TEST (FakeTimeService, Get)
{
{
Time time;
Time time;

}
}

time->minuteOfDay = 42;
time->minuteOfDay = 42;
TimeService_SetTime (&time);
TimeService_SetTime (&time);
LONGS_EQUAL (42, FakeTimeService_GetMinute());
LONGS_EQUAL (42, FakeTimeService_GetMinute());

Flash Program 序列圖 - 成功的情形

FlashTest.c
FlashTest.c
TEST (Flash, WriteSucceeds)
TEST (Flash, WriteSucceeds)
{
{
int result = 0;
int result = 0;
MockIO_Expect_Write (0, 0x40);
MockIO_Expect_Write (0, 0x40);
MockIO_Expect_Write (0x1000, 0xBEEF);
MockIO_Expect_Write (0x1000, 0xBEEF);
MockIO_Expect_ReadThenReturn (0, 1<<7);
MockIO_Expect_ReadThenReturn (0, 1<<7);
MockIo_Expect_ReadThenReturn (0, 1<<7);
MockIo_Expect_ReadThenReturn (0, 1<<7);
MockIO_Expect_ReadThenReturn (0x1000, 0xBEEF);
MockIO_Expect_ReadThenReturn (0x1000, 0xBEEF);
Result = Flash_Write (0x1000, 0xBEEF);
Result = Flash_Write (0x1000, 0xBEEF);

}
}

LONG_EQUAL (0, result);
LONG_EQUAL (0, result);
MockIO_Verify_Complete();
MockIO_Verify_Complete();

CMock http://throwtheswitch.org/, CppUMock http://cpputest.github.io/

怎樣才算好設計 ?
可測性、可讀性、可維護性

借用物件導向的設計原則

用 C 語言實現資料封裝
WallClock.h
WallClock.h
void
void
Time
Time

WallClock_SetTime
WallClock_SetTime
WallClock_GetTime
WallClock_GetTime

(Time time);
(Time time);
(void);
(void);

Watch.h
Watch.h
typedef struct WatchStruct Watch;
typedef struct WatchStruct Watch;
void SetTime (Watch* watch, Time time);
void SetTime (Watch* watch, Time time);
Time GetTime (Watch* watch);
Time GetTime (Watch* watch);

用 C 語言實現類別繼承
Watch.h
Watch.h
typedef struct WatchStruct {
typedef struct WatchStruct {
void (*SetTime) (Watch*, Time);
void (*SetTime) (Watch*, Time);
Time (*GetTime) (Watch*);
Time (*GetTime) (Watch*);
} Watch;
} Watch;
DigitalWatch.c
DigitalWatch.c
typedef struct DigitalWatchStruct {
typedef struct DigitalWatchStruct {
Watch* base;
Watch* base;
Time time;
Time time;
} DigitalWatch;
} DigitalWatch;
Watch* DigitalWatch_Create (void) {
Watch* DigitalWatch_Create (void) {
DigitalWatch* self = malloc(sizeof(DigitalWatch));
DigitalWatch* self = malloc(sizeof(DigitalWatch));
self->base->SetTime = mySetTime;
self->base->SetTime = mySetTime;
self->base->GetTime = myGetTime;
self->base->GetTime = myGetTime;
return (Watch*)self;
return (Watch*)self;
}
}

《 interface 》
《 interface 》
Watch
Watch

Digital
Digital
Watch
Watch

用 C 語言實現類別多型
User.c
User.c
void doSetTime (Watch* watch, Time time) {
void doSetTime (Watch* watch, Time time) {
watch->SetTime (time);
watch->SetTime (time);
}
}
DigitalWatch.c
DigitalWatch.c
static void mySetTime (Watch* watch, Time time)
{
{
DigitalWatch* self = (DigitalWatch*)watch;
DigitalWatch* self = (DigitalWatch*)watch;
self->time = time;
self->time = time;
}
}
MechanicWatch.c
MechanicWatch.c
{
{
MechanicWatch* self = (MechanicWatch*)watch;
MechanicWatch* self = (MechanicWatch*)watch;
self->time = time;
self->time = time;
}
}

User
User

《 interface 》
《 interface 》
Watch
Watch

Digital
Digital
Watch
Watch

Mechanic
Mechanic
Watch
Watch

SOLID 設計原則
User
User

《 interface 》
《 interface 》
Watch
Watch

Digital
Digital
Watch
Watch

Mechanic
Mechanic
Watch
Watch

Pocket
Pocket
Watch
Watch

SRP 單一職責
OCP 開放封閉
LSP 替換原則
ISP 介面分離
DIP 依賴倒轉

《 Agile Software Development, Principle, Patterns, and Practices 》

隨著代碼不斷增加
系統架構變得越來越混亂

代碼的壞味道
•
•
•
•
•
•
•
•
•
•
•

重複代碼
壞名字
義大利麵式代碼
長函式
眼花撩亂的布林運算
重複的 switch/case
邪惡的嵌套
依戀情結
參數太多
注釋、注釋掉的代碼
條件編譯

CodeSmells.c
CodeSmells.c
void foobar (Time* time, Work* work)
void foobar (Time* time, Work* work)
{
{
if (work->item != NULL) {
if (work->item != NULL) {
Day day = time->dayOfWeek;
Day day = time->dayOfWeek;
int min = time->minuteOfDay;
int min = time->minuteOfDay;
if ((day >= MONDAY && day <= FRIDAY) &&
if ((day >= MONDAY && day <= FRIDAY) &&
((min >= 9*60 && min <= 12*60) ||
((min >= 9*60 && min <= 12*60) ||
(min >= 13*60 && min <= 18*60)) {
(min >= 13*60 && min <= 18*60)) {
if (work->type == CODING)
if (work->type == CODING)
doCode (work->item);
doCode (work->item);
else
else
doDebug (work->item);
doDebug (work->item);
// doSomethingImportant ();
// doSomethingImportant ();
}
}
}
}
}
}

重構是
“在不改變當前外部行為的條件下，
對現有代碼進行修改的過程。”

《 Refactoring: Improving the Design of Existing Code 》

RefactoredCode.c
RefactoredCode.c
static bool
static bool
{
{
...
...
}
}
static void
static void
{
{
...
...
}
}

isWorkTime (Time* time)
isWorkTime (Time* time)

workHard (Work* work)
workHard (Work* work)

void workInOffice (Time* time, Work* work)
void workInOffice (Time* time, Work* work)
{
{
if (!isWorkTime(time))
if (!isWorkTime(time))
return;
return;
}
}

workHard (work);
workHard (work);

但實際動手
你肯定會講一句話 ...

在真實世界裡
我們必須要跟遺留代碼戰鬥

遺留代碼 = 沒有測試的代碼

修改遺留代碼
•
•
•
•
•

發現改動點
找到測試點
斷開依賴
寫測試
改動和重構

《 Working Efficiently with Legacy Code 》

測試點
• 接縫 ( 函式呼叫 )
• 全域變數 / 感知變
量
• 除錯輸出
• 嵌入監控

把遺留代碼放到測試框架中
TestLegacyCode.c
TestLegacyCode.c
void addNewLegacyCTest()
void addNewLegacyCTest()
{
{
makeItCompile();
makeItCompile();
makeItLink();
makeItLink();
while (runCrashes()) {
while (runCrashes()) {
findRuntimeDependency();
findRuntimeDependency();
fixRuntimeDependency();
fixRuntimeDependency();
}
}
addMoreLegacyCTests();
addMoreLegacyCTests();
}
}

參考資料
《
《
《
《
《
《
《

Test-Driven Development for Embedded C 》
Test Driven Development: By Example 》
xUnit Test Patterns: Refactoring Test Code 》
Refactoring: Improving the Design of Existing Code 》
Working Efficiently with Legacy Code 》
Agile Software Development, Principle, Patterns, and Practices 》
Design Patterns for Embedded Systems in C: An Embedded
Software Engineering Toolkit 》

2014/02: 嵌入式測試驅動開發

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 2014/02: 嵌入式測試驅動開發

Similar to 2014/02: 嵌入式測試驅動開發 (20)

More from AgileCommunity

More from AgileCommunity (11)

2014/02: 嵌入式測試驅動開發

Editor's Notes