《測試驅動的嵌入式C語言開發》——3.9節我們到哪裡了

3.9　我們到哪裡了

在本章裡，我們開始了leddriver的開發。leddriver并不是什麼複雜的例子，但對于表現tdd的機制和過程來講，最好從簡單的例子入手。

我們用一個測試清單來幫助驅動設計和滿足驅動程式的使用者要求。本章開始的幾個測試産出了一個骨架的測試夾具和驅動程式代碼。我們已經準備好給骨架上添加更多的肉了。

大概有些讀者會很關心代碼不完整的結果，隻是完成了部分的實作。别發愁。不管怎樣你也不可能同時做完所有的事情。我們在有序地而且增量式地增加并校驗行為。我們一直在拖延，但在這裡拖延并不是一個貶義詞。

我們通過把led的位址傳入給驅動程式來斷開驅動程式與硬體之間的依賴關系。這個設計決定使得我們有機會去仿冒驅動程式，允許它去截取以硬體為目标的資料位映射。

從某種意義上講，tdd就像從湍急的水中踩着突出的石頭穿過一條山中小溪。這條路徑并不是完美的直線，正如後期調試式程式設計所表現出來的那樣。但我們要在不濕鞋的情況下穿過小溪。後期調試式程式設計就像要一次性的跳躍來飛過這條小溪。如果小溪很窄，這可能行得通。但更多情況下的結果是我們掉在溪水中要與意料之外的暗流纏鬥才能到達目的地。每個測試都把代碼一點點地引向完成的目标，如圖3-3所示。tdd曲折的路線風險更小，因為代碼總是能通過現有已經定義的測試。因軟體bug而阻礙我們程序的風險更小些。我們正在通過小溪的半路上。我們将在第4章中走完剩下的路。