使用高度抽象的DSL來減輕測試負擔？

用戶界面和用戶期待，也即用戶模型之間的不一致性，是bug的一個重要來源。如果沒有面面俱到的信息來描述軟件的工作方式，那么用戶就會覺得它的行為是不可預知的。Leonardo Vernazzade的觀點是，用戶和UI所使用的并不是同一種語言，所以需要進行翻譯。 
        他在自己最近的blog上說到，“語言之間的差異越大，翻譯時出現的問題也會越多”，同時，為了保證翻譯的一致性而帶來的測試壓力也就越大。所以，在很多 情況下，比較好的解決方式就是提供一個用戶模型和用戶界面可以共享的“高度抽象的語言”，也就是領域特定語言（DSL）。這可以幫助我們避免翻譯和相應的 測試所造成的浪費。Leonardo認為，從更通用的角度來說，提高抽象級別可以減輕測試負擔，而且這一做法可以被應用到任何其他模型中，如軟件設計、實 現等等：

        當你站在合適的抽象層次上表達一些事情的時候，就無需測試了，[……]你會對C#或者Java中的+=運算符進行測試么？反正我不會。
Andres Aguiar也曾經在他的blog上談論說，如果我們在完善抽象這一方面投入足夠的精力，那么就沒有必要進行TDD，甚至是單元測試了。但還是有一些問題是需要考慮周全的。

        使用DSL來減輕測試的負擔，其前提就是要對DSL本身進行徹底的測試。Leonardo Vernazza聲稱，“在大多數情況下，這比測試所有的用戶界面要簡單的多，而且工作量也會大大減少”。這種方法會帶來“責任的再分配”，把測試的負擔轉移到DSL的作者身上。不過Gareth Jones相信，“很多DSL的作者都不會用大量的語言變量來測試他們的代碼生成器”。

        Scott Bellware在Andres Aguiar的帖子后面著重說到， 判斷“抽象所固有的最佳層次”并非易事，但Brad Head指出，這正好就是TTD所做的事情：“用‘試試看’來挑戰你的設計抽象”。然而Ron Scott卻爭論說，TDD是用來找出代碼中的變化是否造成了破壞的手段。Bellware實際上所強調的是，如果一個經過設計優化的DSL“功能上已經 全部完成，不再變化”，那么要是想通過關注業務或是技術領域來推進DSL的發展的話，那它就無法再像從前一樣為我們帶來同樣的價值。

原文轉自：http://www.kjueaiud.com