注釋：TDD是指\"測試驅動設計／開發（Test Driven Design/Development）\"，BDD是指\"行為驅動開發（Behaviour Driven Development）\"。
這篇文章引起了很大的反響，其中有許多是來自Smalltalk社區。這點尤其相關，因為Smalltalk和Ruby是近親。Cincom System的James Robertson，甚至錄了一段截屏視頻（Sceencast），來說明Smalltalk調試器在進行TDD時的用處：
我寫了一個測試，并運行它。測試失敗了。我調試測試，讓調試器替我創建漏掉的方法——于是我在調試器中給該方法編寫代碼，并再次運行它。調試器并不是一件不該過于依賴的工具：它把TDD提升了一個層次。
Avi Bryant——Smalltalk Seaside Web框架的創建者，說：
Giles忽略的一點是，你首先怎樣去理解代碼。要想理解代碼——無論是你寫的，還是其他人寫的——沒什么比得上調試器中逐步跟蹤一遍。既然Giles曾經是一位劇作家，或許可以這樣比喻：閱讀代碼就像閱讀一部電影劇本。編寫測試可能就像在描繪故事板（它們幫助你將最終的產品形象化）。而使用調試器就像實際觀看這部電影。有了調節輪，你就可以一幀一幀慢慢看。
Blaine Buxton提出了調試器角色的另一種觀點：
當你正好在試驗一種新的框架，并想觀察它是如何工作的時候，調試器在檢測程序方面就非常棒。我喜歡一行行地跟蹤。我在學習Seaside的時候就是這么做的，它比任何文檔都更好。此外，看著漂亮的代碼在你的調試器中展開，簡直就像在閱讀一本好書。在處理一些難看的代碼時，調試器會給我展示出在我看代碼時被眼睛所蒙騙了的一些東西。如果動物活著的時候就能觀察各器官是如何工作的，我為什么要解剖它的尸體呢？
Ben Matasar認為\"調試器\"這個名稱可能是問題的根源：
我認為\"調試器\"這個名稱讓人們對它的作用產生了誤解，至少在Smalltalk是這樣。當我去年12月剛接觸Smalltalk的時候，我盡力不用調試器，我的確認為它是一件不該過于依賴的工具�，F在我時刻用它來作為研究代碼的支撐點。事實上，我直接在調試器中編寫相當多的代碼，而讓Web瀏覽器呆在后臺，等待我發送響應。
我現在把它當作是一種方法上下文瀏覽器，在這里，你在調用堆棧的每一步中都有一個活動的REPL。這樣很好，因為你可以發送消息給對象，捅捅它們，然后觀察它們如何對消息做出響應。
因此，傳統的調試器工具允許你通過斷點或者在任意時間中止執行，并允許你查看當前的狀態。它與其他工具一起，幫助開發人員理解系統在運行時實際上是如何表現的——與只查看源代碼相對照。同類的工具還包括覆蓋工具（coverage tools）（如rcov）、剖析器（profiler）、跟蹤器（tracer）或者日志記錄器（logger）。
雖然Giles的文章認為Ruby缺乏調試器支持，但我們不太確定他指的是什么。Ruby攔截器具有調試器支持，既有用Ruby編寫的較慢的版本，也有像ruby-debug這樣的快速版本。JRuby的情形也一樣，快速版的方案（jruby-debug）目前正在開發當中。其他的Ruby實現，如Rubinius具有低開銷的調試，也有的使用底層的VM調試支持。 [Page]
當然，調試器實現只是一個方面——還必須有調試器的用戶界面。但是這在Ruby領域中也不缺。所有主要的現代Ruby IDE都支持調試。RDT（現在是Aptana的一部分）已具有調試支持多年了——最新的NetBeans的調試支持與RDT源自相同的代碼。Eclipse DLTK Ruby具備調試支持，其他非Java的IDE，如Sapphire Steel公司的Ruby in Steel IDE、Komodo等等也都一樣支持調試。
你在軟件測試開發技術的調試Ruby方面又有什么經驗呢？
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/