一個測試程序迭代的故事

緣起

大學的時候學的是C，畢業以后聽說聰明的程序員用Delphi，從那時起就開始了這段緣分。2000年已經有了Delphi5，多功能和高效率深入人心。隨著多年的演進和眾多開發者的奉獻，如今功能更多，效率也更高。但是好工具也要配合好方法去使用，更要探索適合自己的方法。

探索提高效率的方法就是這個故事的主要內容。

第一個需求 測試一段代碼

每一個開發者，無論是在學習階段，還是在實踐階段，都會做一件事情，測試代碼。

最簡單的方法，就是新建一個工程，放一個按鈕，修改標簽，雙擊按鈕，在Click事件中寫一段代碼，然后編譯運行程序，點擊按鈕，觀看代碼的作用。這一套行云流水的操作，簡直成了開發者的站樁功夫，不要太熟練！

很多入門書籍也都是從這個站樁功夫開始的，很多網上分享的文章也都是這么做的，包括人氣很旺的“萬一的 Delphi 博客”。

簡單就真的簡單嗎？

第二個需求 測試多段代碼

測試了第一段代碼后，再測試一段代碼怎么做？再新建一個工程？還是打開原來的工程，再放一個按鈕？

哈哈，迭代開始了！（這里應該有字幕：“迭代 即 黑格爾辯證法的無限循環”）

第一個方案：再新建一個工程？

重復了很多步驟，多占了磁盤空間，以后再次查閱或修改也不方便！

但也許這些都不是問題，可以不保存工程，直接把代碼和結果以文字描述或圖片的形式保存到一個筆記軟件或博客就行了。重復的步驟大部分是IDE完成的，自己只是點擊幾下鼠標，查閱功能也交給了筆記軟件或博客。以后想修改一點代碼再次測試的時候，重復一下站樁功夫就好了。

不過，如果代碼涉及組件，記錄和恢復就不那么簡單了，直接把窗體文件轉成文字一起保存是一個方法，但增加了很多無關的內容。

第二個方案：打開原來的工程，再放一個按鈕？

測試代碼再多呢？窗體上總有放滿的時候，再說，按鈕多了也容易搞混，找到要測試的按鈕都要花點時間。分類放到不同的工程中，又回到了第一個方案。還可以在一個工程中多建幾個窗體，分類放置按鈕，這樣更高效一些。

一個工程，多個窗體，分類放置按鈕，這樣改進目前看還不錯。

看來吃一頓飯是一種需求，頓頓有飯吃卻是新的需求，量的變化會導致需求的變化。

1到n，就這樣了嗎？

第三個需求 多一點信息標識代碼

寫了一些測試代碼后，有一天想再看看某一段測試代碼的效果，結果發現很難找到那個按鈕。標簽寫的太簡單了！放置按鈕的時候還知道，過后就忘了。

這個簡單，標簽寫詳細一點就好了！連迭代都不算。

改起來卻發現不那么簡單。文字多了，按鈕就要變大，占的地方就大。有的按鈕字多，有的字少，大小不一，很不美觀。要是統一大小，占的地方就更大，而且還要浪費時間設置大小和位置。

還是要迭代！

菜單可以顯示更多的文字，而且占的地方不大。而且菜單是樹形結構，可以添加子菜單，用于分類測試代碼很適合。

按鈕改成菜單項的工作量變化不大。打開測試工程，打開相關窗體，打開MainMenu編輯器，插入一個MenuItem，設置標簽，雙擊菜單項，在Click事件中寫代碼，然后編譯運行程序，點擊菜單項，觀看代碼的作用。

不太好的地方就是運行后，要點擊主菜單，才能看到子菜單。

瑕不掩瑜，可以接受。

一時爽不等于時時爽，如果以后的路還很長，還是一開始就把事情做完善一點。

微瑕，需要改進嗎？