TDD-嵌入C語(yǔ)言的測(cè)試驅(qū)動(dòng)開(kāi)發(fā)

要點(diǎn)

1.為什么你會(huì)遇上這些bug？因?yàn)樗鼈兪悄惴诺摹?/p>

2.在TDD(測(cè)試驅(qū)動(dòng)的開(kāi)發(fā))中，你會(huì)在一個(gè)嚴(yán)格的反饋循環(huán)中，開(kāi)發(fā)測(cè)試與生產(chǎn)代碼。

3.TDD可能有助于避免惱人的Zune bug。

4.目標(biāo)硬件瓶頸有多種形式，你可以在嚴(yán)格的TDD反饋循環(huán)中，用TDD來(lái)避開(kāi)瓶頸。

5.TDD幫助你確保自己的代碼如期望那樣運(yùn)行。但如果不是這樣，你該如何建立一個(gè)可靠的系統(tǒng)？

6.TDD快速地發(fā)現(xiàn)小的和大的邏輯錯(cuò)誤，防止出現(xiàn)bug，使最終得到較少的bug。

我們的工作方式都是編寫代碼，然后努力讓它運(yùn)行起來(lái)。先建立，然后改錯(cuò)。測(cè)試是以后的事，即寫完代碼后才要做的事。在不可預(yù)期的調(diào)試工作上，大概要花掉我們一半的時(shí)間。在日程表上，調(diào)試工作都穿著測(cè)試與集成的外衣。它是風(fēng)險(xiǎn)與不確定性的一個(gè)來(lái)源。修正了一個(gè)bug可能會(huì)產(chǎn)生另一個(gè)bug，有時(shí)甚至是一連串的bug。

保持調(diào)試的統(tǒng)計(jì)有助于預(yù)測(cè)要花多少時(shí)間才能消除bug。你要度量和管理bug?？辞€的拐點(diǎn)，拐點(diǎn)表示了趨勢(shì)，告訴你最后修正的bug要比產(chǎn)生的多。拐點(diǎn)表示的是已經(jīng)做的事，但你永遠(yuǎn)不知道是否在代碼的某個(gè)陰暗角落還躲藏著其它的致命bug。

可制造性設(shè)計(jì)的一個(gè)方面是確定為什么你會(huì)有這些bug。答案很簡(jiǎn)單：錯(cuò)誤是我們放進(jìn)去的。這就是我們的工作方式。在開(kāi)發(fā)以后的測(cè)試時(shí)，就會(huì)發(fā)現(xiàn)問(wèn)題(圖1和參考文獻(xiàn)1)。我們?cè)陂_(kāi)發(fā)時(shí)會(huì)制造錯(cuò)誤，測(cè)試的工作就是找到這些問(wèn)題。只要仔細(xì)地測(cè)試，就會(huì)發(fā)現(xiàn)錯(cuò)誤。開(kāi)發(fā)后的測(cè)試工作意味著必須找到、修復(fù)和管理大量的錯(cuò)誤。

圖1，在開(kāi)發(fā)以后做測(cè)試時(shí)，會(huì)發(fā)現(xiàn)缺陷

這種調(diào)試居后的編程程序是當(dāng)今最常見(jiàn)的編程方式。先寫代碼，再調(diào)試它。調(diào)試居后的編程方式有風(fēng)險(xiǎn)。人都會(huì)犯錯(cuò)誤。你既不能確定bug將在何時(shí)現(xiàn)身，也不能確定會(huì)花多長(zhǎng)時(shí)間才能發(fā)現(xiàn)它們(圖2)。

圖2，人都會(huì)犯錯(cuò)誤。你無(wú)法確定bug何時(shí)出現(xiàn)，以及要花多少時(shí)間才能找到它們

當(dāng)發(fā)現(xiàn)一個(gè)bug的時(shí)間(TD)增加時(shí)，尋找bug根源的時(shí)間(TFIND)也會(huì)增加，通常增加得更多。如果從錯(cuò)誤的引入到發(fā)現(xiàn)要花數(shù)小時(shí)、數(shù)天、數(shù)周，甚至數(shù)月時(shí)間，你已忘掉了當(dāng)時(shí)的背景，必須開(kāi)始做bug大掃蕩。當(dāng)你在開(kāi)發(fā)周期以外發(fā)現(xiàn)缺陷時(shí)，就必須管理bug。對(duì)于有些bug，發(fā)現(xiàn)的時(shí)間不會(huì)影響修復(fù)的時(shí)間(TFIX)，但有些代碼的運(yùn)行也可能依賴于bug，修改這些bug會(huì)造成其它bug。

短周期以及主動(dòng)的測(cè)試自動(dòng)化可節(jié)省時(shí)間和工作量。這時(shí)，你再不需要重復(fù)繁重而易錯(cuò)的手工測(cè)試。有了測(cè)試自動(dòng)化，重復(fù)測(cè)試幾乎不會(huì)增加額外工作量。測(cè)試自動(dòng)化快速地探測(cè)出副作用，避免了對(duì)調(diào)試事務(wù)的需求。

另一種方案是TDD(測(cè)試驅(qū)動(dòng)的開(kāi)發(fā))，它在一個(gè)嚴(yán)格反饋的循環(huán)中開(kāi)發(fā)出測(cè)試代碼與生產(chǎn)代碼(參考文獻(xiàn)2和3)。一個(gè)TDD微循環(huán)是：編寫一個(gè)測(cè)試，未編譯時(shí)觀察該測(cè)試，做編譯且測(cè)試失敗，使編譯通過(guò)，清除任何多余內(nèi)容，并重復(fù)該過(guò)程直至結(jié)束。編寫測(cè)試代碼與編寫生產(chǎn)代碼是整合的過(guò)程。如果犯了一個(gè)錯(cuò)誤，沒(méi)有通過(guò)新測(cè)試，你馬上就可以知道并改正錯(cuò)誤。測(cè)試會(huì)告訴你是否通過(guò)了新測(cè)試卻產(chǎn)生了某個(gè)錯(cuò)誤。在設(shè)備測(cè)試裝置中加入自動(dòng)化測(cè)試(圖3)，就可以自由地做重復(fù)測(cè)試。

圖3，測(cè)試會(huì)告訴你是否通過(guò)了新的測(cè)試，但卻引入了一個(gè)bug。自動(dòng)測(cè)試要插入到一個(gè)單元測(cè)試裝置中

在TDD反饋回路中做開(kāi)發(fā)與測(cè)試時(shí)，只能避免一部分bug的出現(xiàn)，但不能完全消除。TDD對(duì)設(shè)計(jì)以及時(shí)間的分配方式有著意義深遠(yuǎn)的影響。

與后調(diào)試的編程模式相反，TDD并不包含追蹤錯(cuò)誤的風(fēng)險(xiǎn)與不確定性(圖4)。當(dāng)發(fā)現(xiàn)一個(gè)錯(cuò)誤的時(shí)間接近于0時(shí)，尋找錯(cuò)誤根源的時(shí)間也會(huì)趨于0。剛產(chǎn)生的代碼問(wèn)題通常顯而易見(jiàn)。如果不那么明顯，則開(kāi)發(fā)人員只要簡(jiǎn)單地恢復(fù)剛做的修改，就可以回到一個(gè)可運(yùn)行的系統(tǒng)。尋找和修改錯(cuò)誤的時(shí)間和產(chǎn)生的時(shí)間一樣少，只有當(dāng)程序員記憶隨時(shí)間而模糊，并且有更多的代碼依賴于較早的錯(cuò)誤時(shí)，事件才會(huì)變?cè)恪?/p>

TDD為錯(cuò)誤提供了即時(shí)的通知，可防止出現(xiàn)很多要被迫追蹤的bug。TDD可防止出現(xiàn)缺陷，而后調(diào)試編程會(huì)帶來(lái)耗時(shí)耗力的調(diào)試工作。

TDD可能有助于避免惱人的Zunebug。微軟公司的Zune是為了與蘋果公司的iPod競(jìng)爭(zhēng)。2008年12月31日，Zune變成了“專為一天的程序塊(abrick for a day)”。12月31日是新年前夜，是一個(gè)閏年的最后一天，這是30G Zune要經(jīng)歷的第一個(gè)閏年。很多人都將Zune錯(cuò)誤歸因于時(shí)鐘驅(qū)動(dòng)程序中的一個(gè)函數(shù)。雖然列表1中的代碼并非實(shí)際的驅(qū)動(dòng)程序碼，但它有相同的效果。你可以從列表1中Zune的無(wú)限循環(huán)中找到一些端倪嗎？

圖4，TDD對(duì)于設(shè)計(jì)以及時(shí)間的使用有深遠(yuǎn)的影響。與調(diào)試居后的編程模式比較，TDD

沒(méi)有回溯追蹤bug的風(fēng)險(xiǎn)與不確定性

圖5，對(duì)快速反饋的需求使TDD微循環(huán)離開(kāi)目標(biāo)硬件，而原生地運(yùn)行在開(kāi)發(fā)系統(tǒng)上。一個(gè)TDD循環(huán)包括雙重目標(biāo)的風(fēng)險(xiǎn)，但提供了快速TDD反饋回路的好處

很多代碼閱讀專家審查了這個(gè)代碼，并得出了可能與您一樣的錯(cuò)誤結(jié)論。閆年的最后一天是該年第366天，而Zune對(duì)這種情況的處理是錯(cuò)誤的。在這一天，該函數(shù)永遠(yuǎn)不會(huì)返回！我編寫了設(shè)定年份以及年中天數(shù)的代碼，看是否像90%的Zune bug專家預(yù)測(cè)的那樣，將天數(shù)的布爾代碼設(shè)定為等于或大于366就能解決問(wèn)題。代碼放入測(cè)試裝置后，我編寫了測(cè)試用例(列表2)。和Zune一樣，測(cè)試進(jìn)入了一個(gè)無(wú)限循環(huán)。我采用了經(jīng)過(guò)數(shù)千名程序員審核的適當(dāng)修復(fù)方法。出乎我的意料，測(cè)試失敗了；設(shè)定年份與天數(shù)的測(cè)試認(rèn)為日期是2009年1月0日。新年前夜，人們?nèi)詴?huì)擁有自己的音樂(lè)，但Zune仍有個(gè)bug。

一次測(cè)試就可以防止Zune bug?？赡阍趺粗酪戇@樣一個(gè)測(cè)試？只有知道bug在哪里才會(huì)寫測(cè)試。問(wèn)題是，你并不知道bug在哪里；它們可以在任何地方。所以，這意味著你必須為所有的部分寫測(cè)試，至少是所有可能中斷的地方。難以想象要考慮到所有需要測(cè)試的東西。但不必?fù)?dān)心，你不需要針對(duì)全年每一天做測(cè)試。你只需要一個(gè)針對(duì)有關(guān)天數(shù)的測(cè)試。

計(jì)算機(jī)編程很復(fù)雜，TDD能夠系統(tǒng)化地讓你的代碼按本意運(yùn)行起來(lái)，并提供能使代碼工作的自動(dòng)化測(cè)試用例。

嵌入設(shè)計(jì)

當(dāng)我首次使用TDD時(shí)，我認(rèn)識(shí)到，它可能有助于解決一個(gè)問(wèn)題：目標(biāo)硬件的瓶頸，這是令很多嵌入軟件開(kāi)發(fā)人員頭疼的事情。瓶頸有多種形式，你可以使用TDD，在嚴(yán)格的TDD反饋循環(huán)期間避免瓶頸的出現(xiàn)。很多嵌入開(kāi)發(fā)工作都已實(shí)現(xiàn)了軟硬件的并行開(kāi)發(fā)。如果軟件只能在目標(biāo)硬件上運(yùn)行，則可能浪費(fèi)至少一次的時(shí)間。例如，目標(biāo)硬件可能遲至交付期還不可用，推遲了軟件的測(cè)試；硬件可能昂貴且稀少；或者它本身就有問(wèn)題。目標(biāo)硬件還可能有長(zhǎng)的建立時(shí)間或長(zhǎng)的上傳時(shí)間。大多數(shù)嵌入開(kāi)發(fā)團(tuán)隊(duì)都遇到過(guò)這些問(wèn)題，它們會(huì)減緩進(jìn)度，并減少了建立今天復(fù)雜系統(tǒng)的反饋。

為避免目標(biāo)硬件的瓶頸，可以采用“雙重目標(biāo)”法，即設(shè)計(jì)自己的生產(chǎn)代碼與測(cè)試，使之大部分運(yùn)行在標(biāo)準(zhǔn)PC上。但雙重目標(biāo)有自己的風(fēng)險(xiǎn)。開(kāi)發(fā)系統(tǒng)中測(cè)試代碼的信任度是建立在交付給目標(biāo)以前的代碼上。大多數(shù)雙重目標(biāo)風(fēng)險(xiǎn)是源于開(kāi)發(fā)環(huán)境與目標(biāo)環(huán)境之間的差異。這些差異包括對(duì)語(yǔ)言特性支持的改變量、不同編譯器的bug、運(yùn)行時(shí)庫(kù)的差異、文件名差異，以及不同的字長(zhǎng)等。由于這些風(fēng)險(xiǎn)，你會(huì)發(fā)現(xiàn)，在一個(gè)環(huán)境下能無(wú)錯(cuò)運(yùn)行的代碼，可能在另一個(gè)環(huán)境下出現(xiàn)測(cè)試錯(cuò)誤。

不過(guò)，執(zhí)行環(huán)境中潛在的差異不應(yīng)成為阻礙采用雙重目標(biāo)方法的理由。相反，你可以在實(shí)現(xiàn)目標(biāo)的路途中解決這些障礙。嵌入TDD周期在不犧牲優(yōu)點(diǎn)的前提下，克服了挑戰(zhàn)。

開(kāi)發(fā)循環(huán)

當(dāng)建立與測(cè)試循環(huán)只需幾秒時(shí)間時(shí)，TDD是最有效的。這種方案為大多數(shù)程序員排除了在循環(huán)中使用目標(biāo)硬件的情況。快速反饋的需求將TDD微循環(huán)與目標(biāo)分離開(kāi)，而運(yùn)行在開(kāi)發(fā)系統(tǒng)上。圖5顯示了一個(gè)TDD循環(huán)，它包含著雙重目標(biāo)的風(fēng)險(xiǎn)，提供了快速TDD反饋循環(huán)的好處。

表1中所列的各個(gè)階段，預(yù)計(jì)可以在相應(yīng)的階段發(fā)現(xiàn)問(wèn)題。例如，你會(huì)發(fā)現(xiàn)每個(gè)階段都有助于找到這些問(wèn)題。第1階段會(huì)在你編程時(shí)給出快速反饋，確定代碼做你想要做的事。第2階段確保你的代碼是在兩種環(huán)境下編譯。第3階段確保代碼在主處理器和目標(biāo)處理器上的運(yùn)行相同。評(píng)估硬件可能需要比目標(biāo)更多的存儲(chǔ)器，這樣才能把測(cè)試代碼和生產(chǎn)代碼都裝入地址空間。有時(shí)候，如果你有一個(gè)可靠的目標(biāo)硬件，它有空間運(yùn)行對(duì)單元的測(cè)試，也可以省略掉第3階段。第4階段是在目標(biāo)硬件上運(yùn)行測(cè)試。在第4階段可以引入一些依賴于硬件的單元測(cè)試。第5階段是看你的系統(tǒng)完全整合時(shí)，是否如其應(yīng)該的那樣運(yùn)行。至少讓第5階段的某些部分自動(dòng)運(yùn)行，這是一種好的想法。采用TDD的團(tuán)隊(duì)會(huì)發(fā)現(xiàn)第1階段中的巨大價(jià)值，可能不要實(shí)現(xiàn)全部各個(gè)階段。

嵌入TDD循環(huán)并不能阻止所有問(wèn)題，不過(guò)它應(yīng)有助于在適當(dāng)?shù)碾A段發(fā)現(xiàn)大多數(shù)剛剛產(chǎn)生的問(wèn)題。你還應(yīng)至少每個(gè)夜晚手動(dòng)執(zhí)行第2至第4階段。連續(xù)的集成服務(wù)器(如Cruise Control或Jenkins)都可以觀察你的源碼庫(kù)，在check-in后開(kāi)始做建立工作。

TDD有助于確保你的代碼做你想要做的事。如果不是這樣，如何才能建立一個(gè)可靠的系統(tǒng)呢？它幫助你讓代碼在最開(kāi)始時(shí)保持正確，它建立一個(gè)逐步測(cè)試的組件，幫助你維持代碼的運(yùn)行。你在發(fā)現(xiàn)、追蹤和修改bug上要花掉相當(dāng)多的時(shí)間。很多開(kāi)發(fā)人員現(xiàn)在都用TDD來(lái)防止這些bug的出現(xiàn)。它基本上改變了你的編程方式。

TDD能快速地發(fā)現(xiàn)小的和大的邏輯錯(cuò)誤，阻止bug的產(chǎn)生，并最終得到較少的bug。較少的bug也意味著較少的調(diào)試時(shí)間，以及較少的缺陷。當(dāng)新代碼危及一個(gè)約束或一個(gè)假設(shè)時(shí)，測(cè)試會(huì)告訴你。然后，有良好結(jié)構(gòu)的測(cè)試會(huì)成為一種形式的可執(zhí)行文檔。

TDD還讓你放心，這種信心來(lái)自于一個(gè)帶有完備回歸測(cè)試組件的徹底測(cè)試代碼。采用TDD的開(kāi)發(fā)人員稱周末不再受干擾，并且睡眠更好。TDD還監(jiān)控進(jìn)度，追蹤當(dāng)前的工作，以及做了多少工作。當(dāng)代碼變得難以測(cè)試時(shí)，它還對(duì)設(shè)計(jì)問(wèn)題提出早期警告。