最近一直在寫操作符處理的單元測試。正如liangfei所說，想要更好的優化表示式，首先得十分了解操作符的功能，而寫單元測試就是非常好的乙個途徑。十分贊同這個觀點，所以我最近一直在寫測試，也確確實實地了解了操作符的功能。
在測試類中如何獲得操作符物件呢？我參考了一下寫完的測試類，發現是 new 出來的。可是在程式中，操作符不是new出來的，而是通過乙個ioc容器獲得的，而且獲得是某一種操作符的handler，例如下面這樣：
configuration config = propertiesconfigurationloader.loadstandardconfiguration();
// 缺省會取得 standardoperatorhandlerprovider
operatorhandlerprovider = config.getoperatorhandlerprovider();
handler = operatorhandlerprovider.getunaryoperatorhandler(".");
所以，在commontemplate裡，是不可能直接得到操作符物件的。因此，在測試類中，我也就使用了這種方式，來獲得操作符進行測試。
不過liangfei並不同意這種方式。他認為測試操作符的時候，應該在測試類中 new 出操作符，然後對操作符進行測試。理由是這樣可以把要測試的目標功能分隔開來。我的理解就是降低測試的粘結度。但是這樣就產生另外乙個問題，如何保證 operatorhandler的正確性？
或許應該再編寫測試類，從 operatorhandler 開始，測試到每乙個操作符。這樣確實很麻煩。但是如果不做這種測試的話，又不能保證 operatorhandler 的正確性。
那麼測試的粘合度如何控制比較好？例如乙個專案，有業務層，和持久層。那麼當對這兩個層寫測試的時候，改如何進行？
按照所理解的tdd的方式，在實現持久層的時候，必然會寫持久層的測試。在寫業務層的時候，再去寫業務層的測試，這時，業務層的測試也間接包含了持久層的內容。那我們是不是可以跳過持久層的測試？當然不可以。
所以問題又回來了，對於commontemplate來說，我們是不是可以跳過操作符的測試？當然不可以--事實上我們也確實沒有跳過，現在寫的就是操作符的測試。那麼我們可以不可以跳過 operatorhandler 的測試？也是不可以。不過，operatorhandler 中邏輯很少，只是按照責任鏈的模式把變數分配到正確的操作符上。
因此，我們是不是可以把 operatorhandler 的測試和操作符的測試一起做了？雖然這樣做測試粘合度比較大，但是 operatorhandler 的邏輯幾乎沒有，如果再單獨對它進行測試，就和測試操作符完全重複了。
所以，是不是也可以這樣考慮，兩個類，雖然有關聯，但是其中乙個類沒有邏輯，或者邏輯非常少，那麼可以不考慮粘合度，而直接對這兩個類一起進行測試？
這個問題我不知道答案。不過我還是遵從liangfei的意見，按照降低粘合度的方式修改了測試類。希望能在以後的積累中，得到乙個滿意的答案。
效能測試中「併發度」的意義
之前的文章中曾出現過 併發度 這個概念，這個詞不知道是不是我原創，它意在表達 併發 的可能性，是壓力的一種度量。一些同學可能還沒有理解這個概念的意義，下面我們看看它是怎麼來 看過之前文章的同學應該知道，我將 併發 這個容易產生誤解的詞拆分成了 相對併發 和 絕對併發 為什麼這麼做呢？那是因為 絕對併...
小小的瓷磚粘結劑增稠劑會引起怎樣的蝴蝶效應？
貼瓷磚可以依仗瓷磚粘結劑，可還有瞬乾型 厭氧型 壓敏型 熱熔型等這麼多分類，那稠度低了，就會引起蝴蝶效應，波及面太廣了，調整依仗原料或者膠水?可能加了之後就後悔了，無論是穩定性，還是粘接耐久度都不盡人意。依仗瓷磚粘結劑增稠劑吧?可以是可以，不過我想有不少需要大家留個心眼的地方。按照基礎配方，除開基礎...
測試演算法的時間複雜度
通常我們編寫乙個演算法後,都很想知道它的時間複雜度,也就是他的執行速度.測量演算法的運算時間,一般需要採用多執行緒程式設計.在網上找到乙個有關的c 可以參考一下.新建乙個類 hiperftimer 如下 using system using system.runtime.interopservice...