摘要: 用Commons Modeler 開發JMX應用 Modeler組件是Jakarta Commons 項目針對Model MBeans提供的一個便利的開發組件。 首先介紹一下基本的概念：Managed bean簡稱Mbean，是對可被管理的資源的抽象定義，ModelBean是JMX定義的Mbean中動態和靈活的一種。但是要實現它開發人員必須設置大量的Metadata信息。Modeler組件針對Mo...  閱讀全文

單元測試的局限
關于單元測試的一篇好文章，我只翻譯了一段，有興趣的可以看看原文。

譯自：http://www.theserverside.com/blogs/showblog.tss?id=Unitized

考慮一下單元測試的目的和原則：
1。盡量小粒度的“單元”被測試。
2。測試在于其它模塊隔離地情況下獨立地完成。
3。Mocking在隔離的方面作出了強化。
4。代碼和測試都是同一個人完成的。

把上面提到的考慮在一起，意味著單元測試是測試整個代碼中最低層次的部分，每一個部分是和其它部分隔離的。測試和編碼是同一個人完成的。
這種方式的測試正是“我”所說的“low hanging fruit”[可輕易實現的目標 (easy targets)]。它可以捕獲小的問題，也就是可以找到不符合單元測試的要求的單獨的函數或者類。

單元測試是一個好事，提供了對于自己代碼正確性的有價值的反饋。但是“Keep in mind" 它只能得到“low hanging fruit”。在設計上，單元測試被期望“簡單的”、“作為系統中獨立的小部分”。因為這些，在它的本質上（與生俱來的），單元測試沒有考慮系統的“組合”，它只考慮獨立的部分。單元測試從不檢查一個系統中內部的聯絡，從不檢查他們是如何捆綁在一起的。

根據“我”的經驗，系統中如何聯絡和如何捆綁在一起正是系統的復雜度所在。
正是這種“連接”定義了你的設計，如果在一個足夠高的層次上考慮，這種聯系甚至可以理解為系統的架構。
信息是如何在不同的軟件層上和不同的組件之間的流動實實在在的定義了一個應用。
由此看來，單元測試是不會測試一個應用的這些方面的。單元測試忽略了信息是如何在不同的層和不同的組件之間流動的，忽略了類和對象在一個大的架構和設計中如何相互關聯和組合在一起的。
這就意味著單元測試只能在獨立的代碼片斷中捕獲簡單的錯誤，但是對系統的整體的設計或者機構Say nothing。
設計和架構限定了你的系統的性能，內存使用，“端到端”的正確性。[用戶的輸入，到Server處理所使用的，到最后的返回的整個路徑]。所以這些是如何進行聯系的顯示了系統的行為，并且正是在這個范圍中存在著the toughest bug 和 problems，要想讓一切OK，程序員們也要在這個地方苦干不止。
編寫隔離的獨立組件是容易的，把他們粘合在一起是困難的。單元測試只在隔離的在獨立的部分上作判斷，而不是在整體上。

使系統中的一個組件的動作正確相當來說是價值不高的活動。獨立的編寫一個系統的組件不是計算機編程的困難的部分，任何一個個體的小的組件都是容易編寫的。在開發中最難的部分來自于如何把所有的組件捆綁在一起工作。單元測試可以驗證每一個你編寫的獨立組件是不是按照你所想的那樣工作，但是它不能檢查更復雜的“wiring”--“wiring”正是我們的設計，開發和調試絕大部分工數所在。

從上看來，單元測試不會指出“端到端”的處理是否正常，不會關心性能，不會關心內存的使用，不會關心可用性，不會關心代碼是否正是用戶想要的。它也不會捕獲多線程的bug，或者錯誤的理解了外部API或者子系統的使用等等。這些并不意味著單元測試是不好的或者應該避免的，它只是說明單元測試只會給你一個有限的回報。設想我們作為開發人員，我們沒有無限的資源去開發我們的代碼，我們不得不聰明的決定我們要把我們的精力放在那里。我們不得不經常的折衷和決定怎樣做有最好的效果。

在“我”參加的所有開發中。單元測試覆蓋了絕大部分的代碼，但是在以下的方面的努力還差得很遠：
1。應用程序設計的本身。你應該花費更多的時間在你的設計上，采用一種迭代的，真實地方式而不是花費在單元測試上，因為一個好的設計得到的回報比任何數量的單元測試都多。
2。集成測試（Integration Test）。集成測試的測試特征是基于“端到端”的。通過它的設計可以證明你的獨立的組件可以工作在一起。通過一個集成測試，你可以更信賴你的系統按照“端到端”的方式工作，而不是一些獨立的對象。
3。功能測試和回歸測試（Functional Test&Regression Test）。系統不是開發人員想的那樣，而是用戶期望它是什么樣子。更進一步，回歸測試當新的特性被追加或者底層的代碼被改變時，驗證高級別的功能的正確性沒有被改變。
4。非功能測試（Non-function Test)。在可接受的運行需求下，代碼作為整體被運行，請求在可接受的時間范圍內被處理。sever不會因為有3個用戶請求就會memory緊張。等等。

做以上的東西會比單元測試難很多。但是在同樣的投入下會得到更多的回報。

Java ClassLoader 實現程序的擴展性

  

今天在完成一個功能的時候，使用了ServiceLocate模式，

通過這個模式，在程序中可以自由的加載其他成員實現的功能模塊

具體的做法：

 1）定義標準的服務接口。

 2）定義描述實現服務接口的xml文件。

 3）程序讀取該xml文件，使用Class.newInstance()實例化具體的服務對象。

 4）建立一個特定服務和特定服務實現的對應的HashMap對象。完成注冊任務。

 5）主程序中根據具體的服務從HashMap中取得具體的對象進行服務。

 

這個方法還不錯，可以完成基于Interface的開發要求，利于Test和程序的拓展性。

有新的要求出現后，只需要添加xml中的元素和具體的實現類就可以了。

 

接下來，繼續想。又發現了一些問題：

1）xml是和程序一起發布的，如果用戶隨意改動了。很明顯程序會崩潰。

解決方法：xml放在jar包中，使用getClass().getResourceAsStream(String name)

自己加載進來。用戶完全不知道具體的情況。

 

2）如果把xml放在了jar包中“藏起來”，實際上原來帶來的動態擴展的特性，

也就沒有那么明顯了。如何解決呢

 

細細想來，這個問題的關鍵在于，所有的服務實例對象的創建和注冊都是在

主控程序中通過xml來完成的。如果可以把這個注冊和實例化的過程從主控程序

中分離出來，通過每個服務實例對象自動注冊來完成，那么才算是真正的可拓展的。

如果需要完成新的功能，只需要把新的服務對象Class發布，重新運行主控程序就會實現新的功能。（看起來就和Eclipse一樣）

這真是一個不錯的想法，但是怎么做呢？

 

看看Eclipse如何做的。

http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html

 

 

首先要有一個規定的plugin deploy目錄，這樣主程序才知道從哪里加載。

要有一個plugin.xml文件描述這個plugin.這著文件中有屬性：class="foo.bar.Plugin">

看上去和我們原來做的方式一樣啊。但是它是如何把這個目錄下的plugin都加載的呢？

（我沒有看過Eclipse的源碼，不知道他是怎么寫的）

 

再想想，其實主要要解決的問題是不通過主框架程序注冊服務實現，

應該由服務程序自己注冊上來。按照這個思路，我想有兩種解決方案。

1）服務接口添加registerService 方法。

   * 在jar的METATINFO文件中定義類名。

   * 從特定的目錄中讀取jar/class文件。

   * 通過URLClassLoader.newInstance()加載

   * 加載后把ServiceLoader作為參數出入 service.registerSevice()中

   * service對象完成自己的注冊。

2）服務添加static代碼端在類被實例化的時候自動完成注冊。

   * 加載之前和上一個方法一樣。

   * 對SeviceLoader對象實現為單態的模式。提供靜態的注冊方法。

   * 在servie對象中實現如下的代碼段完成自動注冊。

   static

              {

                ServiceLoader.registerService(new service());

              }

 

 

這樣看來總算OK了吧。

原來在http://a-ke.blogbus.com 發現太慢了。

自己上都費勁。轉到這里會好一些吧！

回頭把東西都搬過來。