2. 程式人生 > >單元模擬測試--UT 自動生成+JMockit 工具

單元模擬測試--UT 自動生成+JMockit 工具

阿新 • • 發佈：2019-01-17

UT自動生成外掛使用說明

  • 特性
  • IDEA外掛使用步驟
  • Maven外掛使用步驟
  • 程式碼結構說明
  • 外掛可選配置項
  • Mock注意事項
    • Mock點的選擇
    • 介面和抽象類的Mock
    • 類初始化器和構造器的Mock
    • 獲取任意型別的Mock物件
    • 私有欄位的讀寫
  • Release Notes

特性

  1. 自動生成被測類所有宣告方法的測試程式碼
  2. 自動生成被測類依賴的Mock程式碼，並與測試程式碼分離
  3. 支援增量（新增類和方法）生成
  4. 不會覆蓋已有測試程式碼
  5. 簡單易用，生成速度快
  6. 配置靈活多變
  1. 準備環境
    IDEA、Maven環境、Maven專案
     
  2. 安裝
    下載外掛zip安裝包，UTGenerator.zip
  4. 在IntelliJ IDEA中選擇File > Settings > Pluggins，然後選擇Install plugin from disk...如下圖：

          選擇下載的UTGenerator.zip，然後OK，IDEA會提示重啟，重啟完成後外掛就安裝好了。

          注意：不要解壓zip包，直接選擇UTGenerator.zip進行安裝，如果只安裝zip包中lib下的UTGenerator.jar可能會出現java.lang.NoClassDefFoundError: javassist/NotFoundException。

       5 . 執行外掛

          在Project或Module的任意目錄或檔案上右擊，選中第二項的Generate UT，然後會彈出如下對話方塊：

          

      6. 配置項說明

         本地Maven倉庫：一般不用填寫，預設自動通過mvn help:effective-settings命令獲取倉庫地址，若實際倉庫地址與此命令讀取的地址不同，則填寫實際倉庫地址

         檔案輸出路徑：可不填，預設為專案的src\test\java目錄

         不生成預設fail：預設生成的測試程式碼最後都有一句fail("This test case is a prototype.")，勾選則不生成

         不生成Mock程式碼：勾選後不生成任何Mock相關程式碼

         互動式Mock：預設生成的Mock程式碼為全量Mock，在互動式Mock模式下提供視覺化的依賴樹介面讓使用者選擇需要進行Mock的依賴，如下圖

        

        每一個存在依賴的被測類都會彈出一個對話方塊，用於展示被測類的所有依賴，例如上圖中FlightweightFactory為被測類，紅色斜體的是它的方法，

        藍色的類為當前方法依賴的類，而黑色的方法為具體依賴的類中的哪些方法。對依賴項進行勾選，然後點選OK，最終生成的Mock程式碼中就只包含勾選的那些依賴。

        注意：外掛執行時會對所選的project和module進行編譯，所以外掛執行前請確保編譯能夠成功(單獨module編譯失敗時需要對整個project進行mvn install -DskipTests)；在互動式Mock模式下選擇的被測類個數上限為50個；新增Jmockit依賴可以參考下面的Maven外掛使用步驟3。

Maven外掛使用步驟

  1. 準備環境
    外掛執行需jdk1.8，生成的程式碼要求jdk1.7+

     2 在pom.xml中：

注意：1. plugin配置要加在build節點下的plugins節點下，而非只新增在pluginManagement節點下面；在包含多個module的maven專案中推薦把UT外掛依賴新增在外層父pom中，然後在需要生成UT的module根目錄下執行mvn ut:generate，idea中則可以在子模組的Plugins節點下雙擊ut:generate。

                    2. 外掛執行時會首先編譯專案，所以外掛成功執行的前提是專案能夠編譯通過，即能夠在待生成UT的project或mudule下執行mvn clean compile成功，如果在子module下執行編譯失敗，可以先把整個project進行mvn clean install -DskipTests，因為子module單獨編譯失敗往往是沒有把其依賴的其他模組的jar包安裝到本地maven倉庫導致的。

                    3. 當出現java.lang.ClassNotFoundException時，在保證編譯(mvn clean compile)成功的前提下，檢查一下UT外掛讀取的maven倉庫地址（外掛執行時會顯示）與mvn install的倉庫地址是否一致，因為UT外掛會從本地maven倉庫中載入依賴，而在命令列（系統的cmd或者idea中的terminal）中執行mvn命令與idea圖形介面中雙擊執行時讀取到的maven本地倉庫地址可能是不一致的，這個不一致是由於idea的maven選項中User settings file或者Local repository勾選了override，所以可以嘗試去除勾選override再重新執行UT外掛。

                    4. 當出現類似Error injecting: com.ctrip.flight.testframework.tools.GenerateMojojava.lang.TypeNotPresentException: Type com.ctrip.flight.testframework.tools.GenerateMojo not present的錯誤時，需要把專案的jdk切換成1.8，執行完外掛後可以切回1.7。

程式碼結構說明

自動生成的UT程式碼儲存在專案目錄中的src\test\java\下，每個被測類會生成兩個檔案，例如被測類App.java會對應生成AppAutoTest.java和AppAutoMock.java，前者是測試程式碼，後者是Mock程式碼，三者程式碼內容關係用下面一個簡單的例子說明：

(1)被測類App.java 內容

public class App {

private OuterService outerServiceA = new OuterService("serviceA");

private OuterService outerServiceB = new OuterService("serviceB");

//方法依賴OuterService#isNormal方法，並呼叫了兩次

public boolean checkStatus() {

boolean b1 = outerServiceA.isNormal();

boolean b2 = outerServiceB.isNormal();

return b1 && b2;

}

}

(2)AppAutoMock.java內容

public class AppAutoMock {

//每個被測方法都會對應一個靜態內部類，類名為被測方法名+Mock

static class CheckStatusMock {

//每個被測方法依賴的類都會對應一個靜態方法，該方法命名方式為mock+依賴的類名。靜態方法會把被測方法依賴此類的所有方法Mock掉。接收的Map引數為Mock方法被調次數（從0開始計數）與返回值之間的對映。

static void mockOuterService(final Map<Integer, Boolean> isNormalMockValue) {

new MockUp<OuterService>() {

//記錄isNormal方法被調次數

int isNormalCount = 0;

//儲存最後一次呼叫的返回值，當實際呼叫次數多於Map中給出的返回值個數時返回此值

boolean lastIsNormalMockValue;

//Mock被測方法App#checkStatus依賴的isNormal方法

@Mock

public boolean isNormal() {

boolean result = lastIsNormalMockValue;

if (isNormalMockValue.containsKey(isNormalCount)) {

result = isNormalMockValue.get(isNormalCount);

lastIsNormalMockValue= result;

}

isNormalCount++;

return result;

}

};

}

}

}

(3)AppAutoTest.java 內容：

@RunWith(JMockit.class)

//繼承AppAutoMock

public class AppAutoTest extends AppAutoMock {

private App testInstance;

@Before

public void setUp() {

//可以複用

testInstance = new App();

}

//方法名為test+被測方法名，如果是過載方法則為test+被測方法名+下劃線+引數型別組合

@Test

public void testCheckStatus() {

//mock class OuterService

boolean z = true;

Map<Integer, Boolean> isNormalMockValue = new HashMap<>();

//外掛自動給出第一次呼叫Mock方法時返回的值，使用者可以按需修改，也可以新增Mock方法第二次及更多次呼叫時返回的值(存在這樣的場景)，如isNormalMockValue.put(1,false)，即給定第二次呼叫OuterService.isNormal方法時返回false

isNormalMockValue.put(0, z);

CheckStatusMock.mockOuterService(isNormalMockValue);

//呼叫被測方法

boolean actualResult = testInstance.checkStatus();

//斷言

assertFalse(actualResult);

//TODO: remove this default call to fail

fail("This test case is a prototype.");

}

}

說明：1. Mock框架使用JMockit（快速上手），相比於Mockito、EasyMock等Mock工具其功能更加強大，能夠方便地讓你對單元測試中的final類、靜態方法、建構函式、private static final屬性進行mock。

           2. 不同的測試方法（@Test標註的方法）的Mock操作是相互隔離的，不會相互影響，即當前測試方法中呼叫的Mock操作產生的Mock效果在方法執行結束後也就失效了。

           3. @Mock標註的被mock方法，預設邏輯為根據被呼叫次數返回相應的Mock值，使用者可以對其進行重寫，實現任意自定義邏輯，比如驗證Mock方法被呼叫的次數、丟擲異常以模擬異常情況， 還可以呼叫原有方法實現（藉助JMockit中的Invocation）。

           4. 每個生成的Test類上面都標註有@RunWith(JMockit.class)，可以刪除，這樣就可以替換成其他的Runner，比如替換成@RunWith(SpringJUnit4ClassRunner.class)，使測試在Spring容器環境下執行，但此時必須保證專案pom檔案中JMockit依賴寫在Junit依賴之前（JMockit官方文件中有說明）。

           5. 被測類中新增方法後，再次執行UT外掛，只會生成新增方法的測試程式碼和Mock程式碼，追加到原檔案內容的後面。

外掛可選配置項

<plugin>

<groupId>com.ctrip.flight.testframework.tools</groupId>

<artifactId>ut-maven-plugin</artifactId>

<version>2.2.3</version>

<executions>

<execution>

<phase>none</phase>  

<goals>

<goal>generate</goal>

</goals>

</execution>

</executions>

<configuration>

<!--只對xxx(包名、全類名或它們的字首)生成UT程式碼-->

<onlyIncludeGeneratePackages>

<param>xxx</param>

</onlyIncludeGeneratePackages>

<!--只不對xxx(包名、全類名或它們的字首)生成UT程式碼-->

<onlyExcludeGeneratePackages>

<param>xxx</param>

</onlyExcludeGeneratePackages>

<!--自定義輸出檔案的絕對路徑，預設為專案的src/test/java-->

<outputPath>D:\xxx</outputPath>

<!--*********************************************Mock相關配置項**********************************************-->

<!--不生成Mock檔案和程式碼，預設為false-->

<closeMock>false</closeMock>

<!--只對依賴類中包名（或全類名）為packageA的所有方法和包名（或全類名）為packageB中的someMethod方法進行mock-->

<onlyIncludeMockPackageMethods>

<param>packageA</param>

<param>packageB:someMethod</param>

</onlyIncludeMockPackageMethods>

<!--不進行mock的包名、全類名或它們的字首-->

<excludeMockPackages>

<param>xxx.xxx</param>

</excludeMockPackages>

<!--不進行mock的方法名或其字首-->

<excludeMockMethodPrefixes>

<prefix>somePrefix</prefix>

</excludeMockMethodPrefixes>

<!--不進行mock的方法名或其後綴-->

<excludeMockMethodSuffixes>

<suffix>someSuffix</suffix>

</excludeMockMethodSuffixes>

<!--somePackage（包名、全類名或它們的字首）中methodPrefix（方法名或其字首）不進行mock-->

<excludeMockPackageMethodPrefixes>

<packageMethodPrefix>somePackage:methodPrefix</packageMethodPrefix>

</excludeMockPackageMethodPrefixes>

<!--somePackage（包名、全類名或它們的字首）中methodSuffix（方法名或其後綴）不進行mock-->

<excludeMockPackageMethodSuffixes>

<packageMethodSuffix>somePackage:methodSuffix</packageMethodSuffix>

</excludeMockPackageMethodSuffixes>

<!--*********************************************其他配置項***************************************************-->

<!--生成的檔名中類名與Test或Mock的間隔名稱，預設為Auto，填blank代表間隔為空-->

<fileSuffix>blank</fileSuffix>

<!--優先使用有參建構函式生成程式碼，預設為false-->

<preferConstructorWithParams>false</preferConstructorWithParams>

<!--不生成每個測試用例最後面的預設fail語句，預設為false-->

<closeDefaultCallToFail>true</closeDefaultCallToFail>

<!--非maven管理的專案依賴的絕對路徑-->

<addClassPaths>

<path>D:\lib\xxx.jar</path>

</addClassPaths>

</configuration>

</plugin>

說明：

  1. 當不配置onlyIncludeGeneratePackages和onlyExcludeGeneratePackages時，外掛會生成當前專案所有類的測試程式碼，即預設全量生成。
  2. closeMock配置項是全域性的Mock開關，設為true時所有Mock相關的程式碼都不會生成，包括Mock類和Test類中的Mock操作程式碼。
  3. 新增onlyIncludeMockPackageMethods配置 ，實現只對特定的依賴類和方法生成Mock程式碼，此時excludeMock字首的配置項會被忽略。
  4. excludeMockMethodPrefixes和excludeMockMethodSuffixes配置項會對所有包和類中的方法進行匹配，而excludeMockPackageMethodPrefixes和excludeMockPackageMethodSuffixes只對“：”（英文冒號）之前所表示的包和類中的方法進行匹配，即前者是全量匹配後者是部分匹配。
  5. 可以在命令列中傳入需要生成單元測試的類名或包名，例如mvn ut:generate -Dtarget=xxx  其中xxx為需要生成UT的包名、全類名、類名或者它們的字首，多個名稱用英文逗號隔開，這樣就只會對符合條件的類生成UT。
  6. 可以在命令列中傳入目標輸出檔案的路徑，例如mvn ut:generate -DoutputPath=D\:test，代表生成的檔案會放在D盤test資料夾中。可以結合target選項一起使用，例如mvn ut:generate -DoutputPath=D\:test -Dtarget=xxx。
  7. 當專案存在非maven管理的依賴時，需要加上addClassPaths配置項，否則執行UT外掛會出現ClassNotFoundException。

Mock注意事項

Mock點的選擇

在單元測試時，被測試程式碼可能會依賴其他程式碼，可以通過第三方Mock框架來mock被依賴的程式碼，從而進行隔離測試。

在使用Mock的過程中，發現如何選擇Mock點非常關鍵，會直接影響到測試效果。Mock並不是越多越好，過多的Mock往往會得不償失，同時不恰當的Mock選擇反而會對我們的測試產生誤導，從而在後期的整合和系統測試中引入更多的問題。

在Mock點的選擇過程中，以下的一些點會是一些不錯的選擇：

  • 網路互動：如果兩個被測模組之間是通過網路進行互動的，那麼對於網路互動進行mock通常是比較合適的，如RPC
  • 外部資源：比如檔案系統、資料來源，如果被測物件對此類外部資源依賴性非常強，而其行為的不可預測性很可能導致測試的隨機失敗，此類的外部資源也適合進行mock
  • 真實物件的某些行為很難觸發，比如某些異常的邏輯在正常測試中很難觸發，通過Mock可以人為的控制觸發異常邏輯
  • 真實情況令程式的執行速度很慢，而被測物件依賴於這一個操作的執行結果，例如大檔案寫操作，資料的更新等等，出於測試的需求，通常將這類操作進行mock
  • 真實物件實際上並不存在(當需要和其他開發小組進行合作，對方介面功能還沒有開發完成) 

UT外掛在生成Mock程式碼時除了會對jdk和一些公共類庫如guava進行排除之外，其他被測方法依賴的類和方法都會進行mock，包括同一類中的其他方法，即mock了所有的外部依賴（最純粹的UT）。這樣自動生成的程式碼中就會包含一些不必要的Mock操作，比如pojo的get、set方法的mock，使用者需要根據實際情況進行篩選。在保留有意義的Mock程式碼時除了註釋或刪除其它Mock程式碼這種方式之外，還可以按照外掛可選配置項中介紹的新增排除mock的選項，就能夠不生成相應的Mock程式碼。例如在excludeMockPackages配置項中加上被測專案所在的包名，那麼被測方法的所有依賴（類和方法）中屬於當前被測專案的部分都不會進行mock，只會對不屬於被測專案中的其他依賴（類和方法）生成Mock程式碼。

如果需要mock的依賴很少，而且事先已經知道哪些依賴類和方法需要進行mock，通過上述配置排除mock的方式會比較麻煩，此時可以配置onlyIncludeMockClassMethods選項 ，只對需要mock的生成Mock程式碼，避免了全量mock生成過多的程式碼，這種方式是比較推薦的。

預設不進行mock的包名字首如下：

  • java.
  • sun.
  • javax.
  • org.xml
  • org.w3c
  • org.omg.
  • sunw.
  • org.jcp.
  • org.ietf.
  • daikon.
  • com.google.common
  • org.exsyst
  • org.joda.time

介面和抽象類的Mock

上一節例子中的Mock程式碼較簡單，沒有涉及到介面或抽象類的Mock，當被測方法中存在介面呼叫時，例如存在介面：

interface IDpend{

    void foo();

}

被測方法內部這樣使用IDepend：

IDepend depend1 = new DependA();

depend1.foo();

其中DependA是IDepend的一個實現類，這時自動生成的Mock程式碼會對對IDepend介面進行mock：

public static <T extends IDepend> void doMock() {

new MockUp<T>() {

@Mock

void foo() {

}

};

}

以上Mock程式碼會導致實現IDepend介面的所有類（包括匿名類）的foo方法都會被mock掉，而之所以沒有生成對DependA的MockUp，是因為UT外掛只識別物件的編譯時型別，而非執行時型別，所以如果被測方法中同時存在這樣的程式碼：

DependA depend2 = new DependA();

depend2.foo();

那此時自動生成的mock程式碼中就會同時出現對DependA的MockUp,即:

new MockUp<DependA>() {

@Mock

void foo() {

}

};

而此時depend1和depend2物件的foo方法會被哪個MockUp給mock掉呢，答案是MockUp<DependA>，即優先尋找執行時型別所對應的MockUp，如果沒有則尋找其介面的MockUp。

如果此時被測方法裡還有IDepend介面的另外一個實現類DependB的方法呼叫：

IDepend depend3 = new DependB();

depend3.foo();

顯然此時depend3的foo方法會被IDpend介面的MockUp給mock掉（因為沒有對DependB的MockUp）。

如果此時不想對DependB進行mock，但我們又不能把對IDepend介面的MockUp給刪掉，因為它可能還有用處，比如用於對DependC、DependD、DependE...進行mock，如何做到對其中的一個實現類DependB不進行mock呢？此時前面提到的JMockit中的Invocation就派上用場了，藉助強大的Invocation，只需對IDpend介面的MockUp稍作修改即可：

public static <T extends IDepend> void doMock() {

new MockUp<T>() {

@Mock

void foo(Invocation invo) {

if (invo.getInvokedInstance() instanceof DependB) {

invo.proceed();

}

}

};

}

實現原理很清晰，呼叫DependB的foo方法還是進入了IDepend的MockUp中的foo方法，只是這裡增加了型別判斷，判斷被呼叫foo方法的例項的執行時型別，如果是DependB就執行invo.proceed()，即呼叫原方法實現，達到了不進行mock的效果。

類初始化器和構造器的Mock

如果被測類的類初始化器（static程式碼塊，static欄位初始化）和建構函式存在一些依賴性的操作，也可以對其進行mock。自動生成的Mock檔案中包含相關的Mock程式碼，在使用相關的Mock方法時需要注意一下程式碼註釋中的說明，即需要把握好類初始化器和構造器的Mock方法的呼叫時機，否則會不起作用。

獲取任意型別的Mock物件

可以通過生成的Mock檔案中的getMockInstance方法來獲取任意型別的Mock物件，尤其是對於介面和抽象型別十分便利。

私有欄位的讀寫

每個自動生成的Mock檔案中都預設包含setField、setStaticField、getField、getStaticField方法，能夠方便地讀寫物件的私有欄位和類的私有靜態欄位。

在例項化被測類時，由於可能依賴於特定環境導致建構函式執行或者欄位初始化失敗，從而可能在執行測試方法時出現NullPointerException，進而導致相關的Mock操作也無法生效，此時可以藉助前面三種手段（構造器的Mock，任意型別的Mock物件，私有欄位的set）來初始化被測物件，具體方式為：

  1. 在例項化被測類之前呼叫Mock檔案中提供的構造器的Mock方法
  2. 例項化被測類得到被測例項，由於mock掉了構造器，被測例項的欄位為未初始化狀態
  3. 通過Mock檔案中的getMockInstance方法獲取需要初始化的欄位型別的Mock物件
  4. 通過setField方法把第三步中得到的Mock物件設定到被測例項中

關於JMockit的更多細節請參考官方文件：Jmockit官方教程

相關推薦

單元模擬測試--UT 自動生成+JMockit 工具

UT自動生成外掛使用說明 特性 IDEA外掛使用步驟 Maven外掛使用步驟 程式碼結構說明 外掛可選配置項 Mock注意事項 Mock點的選擇 介面和抽象類的Mock 類初始化器和構造器的Mock 獲取任意型別的Mock物件 私有欄

Swagger Edit自動生成程式碼工具

一.swagger簡介　 　　swagger是一套開源的API設計工具，包括Swagger UI和Swagger Editor等。其中swagger edit是用來編輯介面文件的小程式，非常簡單易用。在官網上分為線上編輯和下載程式碼線下編輯的兩種編輯方式。 　　swagger是通過YAML來定義你的介面規

自動生成名字工具類，copy即可用

public class CharUtil { /** * 將字串轉換成相應的字元編碼 * @param s * @return */ public static String bytes2HexString(Strin

Android自動生成程式碼工具-自制外掛篇

搞了一陣子的intellij外掛開發。寫了個關於AndroidStudio的外掛。 主要功能包括： 輔助生成程式碼MZSluggard-code * 根據layout控制元件id，生成可用變數 * 生成mvp模式activity相關類 * 生成adapter關聯layo

【MPC5744P】S32DS中Processor Expert自動生成程式碼工具使用教程（二） FreeMaster除錯

對於使用除錯口，下位機不需要做任何特別的設定，直接按照連結中設定方法來設定上位機即可，注意FreeMaster只能監測下位機中的全域性變數。連結地址：https://blog.csdn.net/u010875635/article/details/84789579   若是使用

【MPC5744P】S32DS中Processor Expert自動生成程式碼工具使用教程（一） 開發環境搭建

MPC5744P是NXP近幾年推出來的主打安全功能的雙核MCU，非常適合在汽車控制器相關產品中使用，非常強大。但是強大的同時，也意味著開發難度增大。 MPC5744P外設功能相關的暫存器非常之多，且對應的參考教程非常少，像STM32之類的工業MCU開發難度根本無法與之相比，早期只能依據官方參

如何在效能測試中自動生成並獲取Oracle AWR報告

由於日常使用最多的資料庫為Oracle，因此，最近又打起了Oracle的AWR報告的主意。 過去我們執行測試，都是執行開始和結束分別手動建立一個快照，然後需要這部分資料的時候再去獲取AWR報告檢視。 但是有的時候忙亂起來或者一個任務項交給別人來做就經常會有忘記建立快照

Json自動生成JavaBean工具

package jsonUtilJar; import java.io.BufferedReader; import java.io.BufferedWriter; import java.io.File; import java.io.FileReader; import java.io.FileWrit

（原創）如何在效能測試中自動生成並獲取Oracle AWR報告

由於日常使用最多的資料庫為Oracle，因此，最近又打起了Oracle的AWR報告的主意。 過去我們執行測試，都是執行開始和結束分別手動建立一個快照，然後需要這部分資料的時候再去獲取AWR報告檢視。 但是有的時候忙亂起來或者一個任務項交給別人來做就經常會有忘記建立快

Mybatis 自動生成程式碼工具(maven方式)

由於MyBatis屬於一種半自動的ORM框架，所以主要的工作將是書寫Mapping對映檔案，但是由於手寫對映檔案很容易出錯，mybatis-gennerator外掛幫我們自動生成mybatis所需要的dao、bean、mapper xml檔案。 1.建立測試工程 選擇maven

mybatis自動生成程式碼工具

該工具來源於github，原專案生產的程式碼比較規範，所有沒有做修改，我只是將其製作成了安裝程式，方便大家使用，效果如下：工具地址連結：https://pan.baidu.com/s/1j31LZUMvZOlu0H5k2LVhxA 密碼：cw9k

PyQT實現一個自動生成配置工具

裝置要量產，需要為每臺裝置燒錄MAC及裝置標識資訊，今天為這事情專門寫個小工具實現 這個功能，主要解決批量生成燒錄配置資訊，這裡對其過程作個總結： 1. 選擇QT的原因在於當時手上的圖形工具就這一種，不想再花時間去搭建新的環境 2. QT簡潔高效，搭配Python比較方便

Mybatis 自動生成程式碼工具--mybatis-gennerator外掛

雖然很多人寫過類似的blog,俗話說好記性不如爛筆頭，還是自己寫寫記得牢，順便默數下 mybatis-gennerator 外掛的前世今生。 主要是為了簡化程式碼，節省時間

idea使用generator外掛自動生成程式碼工具遇到的問題

關於generator工具的使用，百度上已經有很多說明了，這裡不做重複說明，只是說一下使用過程中遇到的一些問題，做出總結。 先說問題： 我的專案結構如下圖 我遇到的問題是，當我在用generator外掛時，由於要在pom.xml裡面新增外掛，所以我是直接將以下程式碼

IDEA 自動生成Junit進行單元測試

沒有 src ner acc 路徑 name cep csdn ctr 1，從插件資源庫中搜索JunitGenerator V2.0版本，通過此工具自動完成test類的生成。Settings > Plugins 2，配置生成test類的路徑。Settings &

Wings與parasoft c++ test在單元測試用例自動生成能力的比對

RoCE 相同 c++ 比較 關心 分享 多少 自己 ××× 作為一個軟件測試培訓講師，主要側重在白盒測試培訓方面，尤其對C++test比較擅長。最近發現市面上跳出一款Wings工具，據說1分鐘可以自動生成100萬行測試代碼，性能方面大大超越C++ test，就想著抽空來×

intellij idea 自動生成test單元測試

在要測試的類上按快捷鍵ctrl + shift + t，選擇Create New Test，在出現的對話方塊的下面member內勾選要測試的方法，點選ok 或者點選選單欄Navigate–》test，選擇Create New Test，在出現的對話方塊的下面m

單元測試maven專案內配置EvoSuite外掛來自動生成test suite

一、新增evosuite兩個外掛 <plugin> <groupId>org.evosuite.plugins</groupId> <artif

JFinal Tables自動生成對應Model及Model程式碼& JUnit 測試單元的編寫

      這幾天在研究JFinal,對ActiveRecord有點興趣，但其執行必須先將Table對應的Model註冊才行， 通過JFinal提供的Model生成工具對資料庫批量生成Model, 生成器的呼叫：package autogen; import javax.s

Greendao 自動生成單元測試

單元測試無疑是個好東西，不然每次都要去編譯整個專案然後安裝到模擬器啟動，按照指定的步驟去看是否有問題，這樣非常浪費時間，之前公司的專案超過10萬行，每次編譯都在3.5分鐘左右，遇到需要除錯的地方更加花時間。所以決定花時間研究下單元測試。先從資料庫開始吧。  1.專案中引入g