敏捷測試指引(3)- 用面向技術的例子支援程序員

　　敏捷測試指引(3)- 用面向技術的例子支援程序員  軟件測試

　　為了幫助討論和理解，我把“敏捷項目中的測試”這一主題分解成4個區分的主題。今天，我講一下我們怎樣使用面向技術的例子來幫助和支援程序開發。

　　這里適用的一個是測試驅動開發，在Kent Beck的書中，David Astel最近的書，Phlip,J.B.Rainsberger接下來的書中都討論了這種開發方式。我認為測試驅動開發(我現在會叫它例子驅動開發，example-driven development)是可靠的。它不是主流的開發方式，但是看起來要成為主流了。套用Geoffrey Moore的話，我認為它正在跨越鴻溝的路途中。

　　也可以這樣說，例子驅動開發已經從Thomas Kuhn所說的“革命性的科學”發展到“正規科學”。在正規科學中，人們擴展了特定方法的適用范圍。因此我們現在很多人在GUI應用EDD(sic)，設法讓它與遺留代碼(legacy code)一起工作，討論mock objects的好的使用方法，討論處理私有方法的技術，等等。但是這些都不是重大的發展。

　　我希望不久的將來會看到更多同時擁有測試和編程的技巧的人被吸引到敏捷項目中來。這些人既不會成為像純測試人員那樣的好測試員，也不會成為像純編程人員那樣好的編程人員。但是那還是不錯的，如果你跟我一樣相信敏捷項目應該重視通才多于重視專才的話。

　　我不是這樣的混合人物。我沒有與純編程人員一起做很多的結對編程。但是我注意到，在維持編程的進度和目標的希望與確保很多好的測試的主意被考慮到的希望之間存在著緊張的關系。我發現我自己在進入程序員模式和退出并考慮全局的之間振蕩。從經驗看來，我們需要更好的思路來管理這個過程，以及關于什么類型的“測試思考”在編碼過程中是合適的。

　　也可能有一些測試員在敏捷項目中不擔當程序員的工作。不過，他們中的一些人還是跟程序員結對討論單元測試(關于程序員如何檢查代碼)。程序員學習如何避免哪些類型的bug，測試員學習他們正在測試的是什么。不知何故，加拿大的卡爾加里成為了這些活動的溫床，我指望Jonathan Kohl，Janet Gregory和其他人告訴我怎樣才能做好。

　　我需要強調這些都是關于人的。傳統上，測試員與編程人員會有很緊密(或者很廣闊)的關系。對于矩陣的支援程序員這部分，我相信傳統的關系是不合適的。

　　我使用術語“checked examples(檢查例子)”作為支援程序員的測試。我們可以把這個概念一分為二。一部分作為指引下一步編碼的決定。另外一部分是自動化的例子，作為“改變探測器”(change detectors)，看剛才的修改是否是你期待的。

　　通常的習慣是，改變探測器僅僅是保留的代碼的保護性例子。(你讓你的單元測試套件作為救助，一個對應一個地，在編碼的同時測試。)那不是邏輯上的要求。我喜歡先建立一些關于什么時候做其他事情的知識。

　　例如，考慮這樣的維護場景：你首先開發了一些代碼例子。一個月后，別人加了一個新的例子并改變了代碼以便匹配。很多之前為那部分代碼開發的例子都成了“bad examples”壞例子了。(測試失敗，但是因為他們現在是錯誤的，不是因為代碼錯誤。)修正那些例子以便他們一致。我的意思是在下表的左邊的事件序列本來是期望與右邊的測試一樣的。(先看左邊欄，然后看右邊。)

　　Example foo written Example bar written

　　Code written to match foo Code written to match bar

　　Example bar written (foo invalidated) Example better-foo written (bar is still a good example)

　　Code changed to match bar - oops, now foo doesn't check out Code changed to match better-foo (and bar continues to check out)

　　Update foo to be better-foo

　　最近壞掉的例子被重寫以便匹配一個理想的開發順序，在這個過程中不需要重寫任何例子。但是為什么?在上表的左列，新的例子foo沒有用于驅動開發，只是作為檢查。對于驅動開發來說是最佳的可能對于檢查來說不是最佳的。

　　假設軟件系統開發切面層(shearing layers)，切面層的接口通常是不會改變很大的。為了可維護性，在修改時移植壞掉的例子到界切面層是有意義的。取代一個例子對應一個類的一個方法的做法，我們現在使用一個例子對應整個子系統。那可能會很糟糕 - 想想調試 – 但是它減少了維護的負擔，甚至能提供關于子系統的行為的完整文檔的好處。

　　我希望人們分清楚兩個角色 – 指引不遠的將來和重新檢查過去 – 會發現有建設性的知識。例如，什么時候編寫面向技術的“改變探測器”(而這些與指引編程沒有任何關系)可能會有用?

　　我在上面說的測試驅動開發是“期中一個適合”今天的主題的東西。那么其他適合的是什么?我不知道。EDD是否是最合適的?(是否最近可能發生革命性的改變?)我也不知道 – 我要依賴那些善于打破舊習的人來幫我找出來。對此我將非常感興趣。

原文轉自：http://www.anti-gravitydesign.com