#
摘要: 對于mock對象上的mock方法的調用,easymock支持指定次數，默認為1.同時easymock提供了其他的方法，用于指定具體調用次數或者放寬調用次數檢驗。
閱讀全文
摘要: easymock并不是萬能的，在使用easymock時有一些限制需要注意。
閱讀全文
摘要:
前面教程中有個章節討論到mock和stub的概念差別，一般來說easymock如其名所示，主要是用來做mock用的，但是easymock中也提供有對stub的支持, 主要體現在andStubAnswer(),andStubDelegateTo(),andStubReturn(),andStubThrow()和asStub()等方法的使用上。
閱讀全文
大家都知道sonar是個好東東，在有CI支持的情況下，使用好了可以非常好的控制代碼的質量，諸如代碼覆蓋率，代碼規則檢查等。
而解決violation的辦法，除了正統的修改代碼來滿足規則外，還有一個變通的方法， NOSONAR。這個標記本意是在一些特殊情況，有不得已的理由不得不違反規則，為了避免sonar繼續報錯而不得已做了一個"變通"。
NOSONAR本意雖好，但要是有人濫用，變通就會變成取巧，因為解決sonar violation的最簡單的方法，就是直接NOSONAR！
當問題很簡單時，一般人都會選擇正常的方式修改代碼，如果只是舉手之勞基本上還是能遵守規則的。但是當問題復雜時，或者說當解決問題不再是舉手之勞時，每個人都要受到NOSONAR的誘惑。而NOSONAR的底線在哪里？沒有人定義，沒有人檢測，自然不會每個人都堅守，NOSONAR的底線隨著一個一個的NOSONAR慢慢的在降低。退五十步的人，是沒有資格笑百步的。
返回到現實代碼中，不知道是大家都沒有頂住誘惑，還是說我們開啟的規則不大合理，總之越來越頻繁的在代碼中看到NOSONAR了，雖然還沒有到泛濫的地步，但是已經讓我有些不安了。簡單搜索了一下剛才讓我感覺到很多NOSONAR的project，結果是58個。
更糟糕的是，每個NOSONAR后面都不會帶有注釋說明為什么要NOSONAR，因此一個個飛舞的NOSONAR就變成了一個個謎團。想知道為什么要NOSONAR嗎？恩，你猜......
我沒有辦法去檢查這個58個NOSONAR是不是都合理的，都站得住腳的。出于程序員的習慣，對于一切不可確認性都報以懷疑的眼光和質疑的姿態，我總覺得這58個NOSONAR讓我總是沒有底，每次我看到sonar上100%的規則檢測通過率時，我總是禁不住在心里浮現NOSONAR的字樣。
好吧，我承認，我是個心里有些陰暗的家伙......
摘要: 在easymock的使用過程中，當創建mock對象時，我們會遇到 strict mock和nice mock的概念。上述的測試案例驗證了strict mock和nice mock的基本使用，對于同一個mock對象，strict模式下多個方法之間的調用順序在record階段和replay階段下是需要保持一致的。但是故事并不是到此結束，更有意思的內容在后面：如果出現多個mock對象，那么這些不同mock對象的方法之間，他們的調用順序是否檢測？普通mock和nice mock模式下自然是不會檢測順序，但是strict模式下呢？
閱讀全文
摘要: IMocksControl接口容許創建多個mock對象，這些創建的對象自動關聯到這個mocksControl實例上，以后再調用replay()/verify()/reset()時就不需要逐個列舉出每個mock對象。當mock對象比較多，尤其是原有代碼上新增mock 對象時非常方便。
閱讀全文
摘要: 前面的例子中，mock的對象都是基于interface，雖然說我們總是強調要面對接口編程，而不要面對實現，但是實際開發中不提取interface而直接使用class的場景非常之多。尤其是一些當前只有一個明確實現而看不到未來擴展的類，是否應該提取interface或者說是否應該現在就提取interface，總是存在爭論。
這種情況下，我們就會面臨主要測試對象依賴到一個具體類而不是interface的情況，easymock中通過class extension 來提供對class mocking的支持。
閱讀全文
摘要: 關于easymock的典型使用方式，在easymock的官網文檔中，有非常詳盡的講解，文檔地址為 http://easymock.org/EasyMock3_0_Documentation.html，文檔的開頭一部分內容都是easymock中最基本的使用介紹，雖然是英文，但是非常容易看懂，適用新學者入門。
這里只羅列一些簡單的常用功能。
閱讀全文
摘要: record-replay-verify 模型容許記錄mock對象上的操作然后重演并驗證這些操作。這是目前mock框架領域最常見的模型，幾乎所有的mock框架都是用這個模型，有些是現實使用如easymock，有些是隱式使用如jmockit。
record-replay-verify 模型非常好的滿足了大多數測試場景的需要：先指定測試的期望，然后執行測試，再驗證期望是否被滿足。這個模型簡單直接，易于實現，也容易被開發人員理解和接受，因此被各個mock框架廣泛使用。
閱讀全文
摘要: 在單元測試中，通常我們都會有一個明確的測試對象，我們測試的主要目的就是為了驗證這個類的工作如我們預期。
閱讀全文
摘要: easymock是目前java mock 工具中比較流行的工具，這個教程將系統的介紹easymock的使用。
主要內容來自easymock的官網教程，針對日常使用進行了一些篩選和補充，另外增加一些個人的理解和認識。
另外考慮到網絡上已有不少分散的教程，我將適當的鏈接進來。
教程的內容將在隨后逐漸添加，目前計劃的目錄如下，相應內容完成之后我將逐個更新此文的鏈接。
閱讀全文
近期發現一個問題，hudson執行任務時，經常不能獲取到最新的代碼，從而導致出現各種問題。
日常開發中的典型例子：發現一個bug，修改代碼，本地測試通過，提交代碼到subversion，手工激活hudson構建，原本期望hudson獲取到剛剛提交的代碼并測試/打包/發布。結果事與愿違，測試的結果發現剛剛做出的修改似乎沒有生效。正費解之時，再執行一次hudson構建，又成功了...
經歷過幾次上述蹊蹺遭遇之后，發現這個問題不是偶然。之后檢查hudson的日志，發現問題的發現在最開始update / check out subversion代碼時，明明已經提交的代碼，hudson做update / check out時，居然沒有update / check out下來！顯示的subversion版本號也和subversion上實際的最新版本不一致，hudson總是要小一些，換言之，hudson update / check out的代碼要比當前最新代碼老一些。
google一番，發現這個問題之前就有人遭遇過，hudson上甚至已經有了好幾個關于這個問題的bug，比如 http://issues.hudson-ci.org/browse/HUDSON-1241 "force using HEAD SVN version for build"。問題的根源在于hudson 獲取subversion代碼的方式，hudson是通過時間戳的方式來獲取代碼，而不是我們一般認為的"最新代碼"即"HEAD"。這種方式通常沒有問題，因為獲取當前時間戳，然后要求update / checkout這個時間戳前的代碼，理論上也是可以拿到最新代碼的。
但是，如果hudson所在的服務器和subversion服務器時間不一致，這個機制就會出現問題:
我們假設subversion服務器的時間是準確的，再假設當時時間是15:10分，開發人員A提交代碼，subversion上當前這個最新提交的代碼時間戳為15:10:00。然后開發人員A手工激活hudson進行構建。hudson在15:10:20時開始check out代碼。如果hudson時間無誤，則hudson會發出請求說要求獲取時間戳在15:10:20之前的代碼，這樣這個實際提交時間為15:10:00的新代碼就可以如期的被check out。但是如果hudson的時鐘有誤，由于某些原因導致時鐘偏慢2分鐘，即在hudson上，"當前時間"為"15:08:20"，則hudson獲取代碼的請求為:獲取時間戳為15:08:20之前的代碼，此時時間戳為15:10:00的新代碼就無法checkout。
幾分鐘之后，疑惑的開發人員A再次激活hudson再次構建，假設此時時間時間是15:15:00，hudson慢兩分鐘為15:13:00。此時hudson發出請求: 獲取時間戳為15:13:00之前的代碼, 因此實際提交時間為15:10:00的新代碼可以正常checkout，問題又在不知不覺被回避了。
總結說，hudson 獲取代碼的機制不是我們直覺中的獲取最新代碼(即subversion中HEAD checkout)，而是基于時間戳。由于這個方式通常如HEAD般工作，因此我們總是容易誤解為是獲取最新代碼。當hudson的時鐘晚于subversion時，悲劇就出現了。
對這個問題，有幾點疑惑：
1. 不明白為什么hudson不采用最直接最簡單最容易被人理解最不容易出誤解的HEAD checkout，而要基于時間戳
2. 這個問題很早就發生了，上面提到的bug 08年就被人提出, "Created: 31/Jan/08 05:37 AM Updated: 01/Jul/10 11:06 AM"，三年了類似的bug被多次提出，但是就是始終沒有修復。
修復的方式很簡單，就改一個類的一行代碼
in Class: hudson.scm.SubversionSCM
line 377:
final SVNRevision revision = SVNRevision.create(timestamp);
replace to:
final SVNRevision revision = SVNRevision.HEAD;
hudson拒絕修復的理由是什么？
Maven 3.0 的第一個RC版本終于發布了，下面是sonatype給出的發布信息：
Maven 在apache上的頁面目前還沒有放出RC1版本。下面是關于mavne3.*版本相對于2.* 版本的改進列表：
https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes
PS: 坦言說，改進很少，尤其沒有大的功能改進，有點失望。
修訂：上面的URL是兼容性列表，因此看起來和2.*差別不大，是我理解錯了，抱歉。
摘要: 最新版本的confluence 3.3.1 linux 安裝筆記。
閱讀全文
摘要: 之前安裝的fisheye2.2.1，破解不是很好用，最近看到fisheye2.3.6版本有出新的破解方式，特地嘗試了一下，成功安裝。現在將過程簡單分享給大家。
閱讀全文
摘要: 作為測試的基本概念，在開發測試中經常遇到mock和stub。之前認為自己對這兩個概念已經很明白了，但是當決定要寫下來并寫清楚以便能讓不明白的人也能弄明白，似乎就很有困難。
試著寫下此文，以檢驗自己是不是真的明白mock和stub。
閱讀全文
講個笑話吧，關于"keep it simple"
這其實是個真實的故事，發生在兩年前，當我從上一家公司離職時。
當時我移交了一個重要模塊，后來不久，記不清了，大概一兩個月后吧，有關系不錯的同事告訴我說：某某人大肆宣揚，***模塊我只找個了***的人，*天就接手了，云云。
言下之意自不必說。
而我，則將上述評論視為對自己的嘉獎，深以為榮。
*******************************************************************************
為了大家能看懂這個笑話，羅嗦一點介紹兩個背景故事：
1. 最驕傲的事
工作9年了，回首看最令自己驕傲的事情，就是在07年的夏天，加班加點的工作了1個半月，將上述模塊的新需求完成。開發模式是我最喜愛的TDD + 持續重構，完備的unit測試案例覆蓋。后面測試中，3位負責測試同事用了三天的時間，測試完成所有的測試案例，全部一次性通過，沒有一個bug，哪怕是小bug。
此記錄本人之后兩年中一直試圖復制，至今沒有成功。
2. 荒謬的問題
發生在離職做上述模塊移交時，被接收人問了一個問題：項目代碼里面，test目錄下是什么東西啊？
import junit.***, extends TestCase...
無言以對。
摘要: Tokyo Tyrant基本規范，翻譯自Tokyo Tyrant官網。
本節為Tokyo Tyrant的基礎教程。
閱讀全文
摘要:
Tokyo Tyrant基本規范，翻譯自Tokyo Tyrant官網。
本節介紹Tokyo Tyrant的遠程數據庫API，Lua擴展和協議。部分細節內容沒有翻譯。
閱讀全文
摘要:
Tokyo Tyrant基本規范，翻譯自Tokyo Tyrant官網。
本節介紹Tokyo Tyrant的客戶端程序。
閱讀全文