software test
和軟件測試相關的內容，包括單元測試，集成測試，壓力測試
摘要: 雖然easymock中提供了大量的方法來進行參數匹配，但是對于一些特殊場合比如參數是復雜對象而又不能簡單的通過equals()方法來比較，這些現有的參數匹配器就無能為力了。easymock為此提供了IArgumentMatcher 接口來讓我們實現自定義的參數匹配器。
閱讀全文
摘要: 在easymock中，對于mock對象的同一個方法，可以為每一次的調用定制不同的行為。在record階段easymock會精確的記錄我們錄入的行為，基于每一次的方法調用。
閱讀全文
摘要: 前面的教程中，我們看到easymock可以通過expect方法來設定mock方法的返回值或者異常，但是注意這些案例中設置的返回值都是在調用被測試的類的方法前就已經確定下來的，即我們其實在測試類的代碼運行前(實際是在EasyMock.replay()方法調用前)就已經"預知"了返回結果。
但是在某些情況下，我們可能無法預知返回值，比如我們需要根據輸入的參數值來決定返回什么，而這個參數可能無法在record階段獲得。因此在mock方法中我們無法在record階段就決定應該返回什么。
對于這種場景，easymock提供了IAnswer接口和andAnswer()方法來提供運行時決定返回值或者異常的機制。
閱讀全文
摘要: easymock中提供對于類的mock功能，我們可以方便的mock這個類的某些方法，指定預期的行為以便測試這個類的調用者。這種場景下被mock的類在測試案例中扮演的是次要測試對象或者說依賴的角色，主要測試對象是這個mock類的調用者。但是有時候我們需要將這個測試類作為主要測試對象，我們希望這個類中的部分(通常是大部分)方法保持原有的正常行為，只有個別方法被我們mock掉以便測試。
閱讀全文
摘要: easymock中提供了非常多的方法來實現參數匹配，基本能滿足一般參數匹配的要求。
閱讀全文
摘要: 在創建mock對象的時候，我們可以命名mock對象。
命名mock對象有什么好處呢？其實就是一點，即在當測試案例因為某個mock對象的狀態或行為不符合要求而失敗的時候，在異常信息里面可以輸出這個mock對象的名稱。
閱讀全文
摘要: 對于mock對象上的mock方法的調用,easymock支持指定次數，默認為1.同時easymock提供了其他的方法，用于指定具體調用次數或者放寬調用次數檢驗。
閱讀全文
摘要: easymock并不是萬能的，在使用easymock時有一些限制需要注意。
閱讀全文
摘要:
前面教程中有個章節討論到mock和stub的概念差別，一般來說easymock如其名所示，主要是用來做mock用的，但是easymock中也提供有對stub的支持, 主要體現在andStubAnswer(),andStubDelegateTo(),andStubReturn(),andStubThrow()和asStub()等方法的使用上。
閱讀全文
摘要: 在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的官網教程，針對日常使用進行了一些篩選和補充，另外增加一些個人的理解和認識。
另外考慮到網絡上已有不少分散的教程，我將適當的鏈接進來。
教程的內容將在隨后逐漸添加，目前計劃的目錄如下，相應內容完成之后我將逐個更新此文的鏈接。
閱讀全文
摘要: 作為測試的基本概念，在開發測試中經常遇到mock和stub。之前認為自己對這兩個概念已經很明白了，但是當決定要寫下來并寫清楚以便能讓不明白的人也能弄明白，似乎就很有困難。
試著寫下此文，以檢驗自己是不是真的明白mock和stub。
閱讀全文
摘要: 一直在使用easymock作為mock工具，但是easymock有一個一直令我極其惱火的地方：easymock將interface和class的mock區分開，給出了針對interface mock的easyMock和針對class mock的easyMock class extension。兩種mock被嚴格區分開，連jar包都是兩個，使用時不能混用，比如不能用easymock (非class extension)來mock class。
easymock已經發布了新的3.0版本，該版本的主要改進就是消除上述的問題，新版本中可以直接mock class，不再強制使用easyMock class extension。
強烈推薦還在使用2.*的朋友們升級到3.0版本。
閱讀全文
摘要: TestNG的官方文檔的中文翻譯版第5章，由于內容太長拆開，本文是5.10-5.14，主要話題是Rerunning failed tests,JUnit tests,JDK 1.4,Running TestNG programmatically和BeanShell and advanced group selection。
閱讀全文
摘要: TestNG的官方文檔的中文翻譯版第5章，由于內容太長拆開，本文是5.8-5.9，主要話題是Class level annotations和Parallel running and time-outs。
閱讀全文
Full software test Archive