~ ~小夥伴們在做 Javaweb 專案的時候,一個功能塊敲完,然後提心吊膽的開啟 Tomcat , 測試功能的時候發現總有那麼一兩個功能點炸成串?而且有時候是很簡單的 SQL 語句編寫錯誤,或者實體名字寫錯這種”筆誤”“.但是像初學者一樣,沒完成一個功能點就跑一遍的話,又很累.而且當你的專案初具規模的時候,開啟伺服器不是那麼快就能完成的,這對一些配置不好的電腦簡直就是噩夢!敲兩個小時的程式碼,一個半小時在等待中度過…

沒關係,看完這篇部落格,你就會知道原來 JavaWeb 的除錯還可以這麼簡單!

宣告:這篇部落格只給出測試類的程式碼,功能類程式碼只會簡單提及,適合有web專案功底的同學; Junit 單元測試並不能為你解決所有潛在的錯誤;本文的案例測試程式碼書寫方式在 SSM 框架, SSH 框架可以互換.

一:建立一個測試類,建議將測試類單獨放在一個包中(在 maven 專案裡有測試類專門的存放位置),新建一個Junit Test Case類,下一步

測試類的命名建議是你將要測試的類名+Test,然後點 Browse, 你可以選擇要進行測試的類(一般選擇 Service, 因為 Service 關心的是業務需求),用這種方式建立可以自動生成要測試類的測試類,你只需要進行測試程式碼的書寫.

    @Test
    public void testqueryById(){

    }
    @Test
    public void testQueryAll(){

    }
    @Test
 

    public void testReduceNumber(){

    }

如果裡面有自動生成的程式碼,刪除或註釋即可…

二:配置 spring 和 junit 整合, junit 啟動時載入 springIOC 容器,這裡你需要 Spring-test jar包

@RunWith(SpringJUnit4ClassRunner.class)
    //告訴junitspring配置檔案
    @ContextConfiguration(locations = {"classpath:spring/spring-dao.xml"})

同樣的,在測試類中我們會呼叫 Service 的邏輯,由於我們使用的是 Spring+SpringMVC+ 持久化框架,所以要注入一個 IService 介面(這裡我直接對 DAO 進行測試了)

@Autowired
    private SeckillDao seckillDao;

接下來是測試邏輯,在編寫測試程式碼之前建議覆蓋實體中的 toString 方法,不然列印會很麻煩.

@Test
    public void testqueryById(){
        long id = 1000;
        Seckill seckill = seckillDao.queryById(id);
        System.out.println(seckill.getSeckillName());
        System.out.println(seckill);
    }

    //JAVA沒有儲存形參的記錄,如果你在 dao 中傳了多個引數,那麼需要宣告它的形參對應的實參,否則 JVM 會顯示找不到引數.宣告方式稍後奉上
    @Test
    public void testQueryAll(){
        List<Seckill> seckills = seckillDao.queryAll(0, 100);
        for(Seckill seckill:seckills){
            System.out.println(seckill);
        }
    }

    @Test
    public void testReduceNumber(){
        Date killTime = new Date();
        //對增加進行測試的時候,只要資料庫增加了一條資料,我們就預設這個方法執行成功了
        int updateCount = seckillDao.reduceNumber(1000L, killTime);
        System.out.println("updateCount = "+updateCount);
    }

解決JAVA不儲存形參的記錄

int reduceNumber(@Param("seckillId")long seckillId,@Param("killTime")Date killTime);

    Seckill queryById(long seckillId);

    /**
     * mysql的分頁查詢
     * @param offset 告訴它實際的形參
     * @param limit
     * @return 
     */
    List<Seckill> queryAll(@Param("offset")int offset,@Param("limit")int limit);

接下來我們根據他返回的結果和我們想要的結果對應就可以了. 測試類不用部署專案, 測試周期非常短, 而且可以進行專項測試. 測試類程式碼邏輯十分簡單, 幾乎不會出錯. 如果結果不是預期的, 那麼根據你的需求修改!
當然, 它的侷限性也很打. 從單元測試不能看出頁面傳值的錯誤, 許多專案在伺服器中的表現也不能模擬.
那麼我們什麼時候用junit呢?
當你的資料庫操作非常複雜, 你不確定能輸出你想要的值的時候, 相比用 debug 除錯, 使用 Junit 是更方便的手段.或者新手出錯概率非常大, 也不用在伺服器中專門測試專案的表現, Junit 是個必備的工具!而且測試類的測試程式碼重用性很高.
如果你的資料和預期相悖, 那麼修改業務邏輯; 否則, 檢視頁面是否有錯! Junit在一定程度上減輕了我們業務程式碼除錯的壓力, 讓我們關注於一點解決錯誤.
最後一點 就像上一篇Junit部落格說的一樣, Junit測試並不能證明你是對的,而是證明你沒有錯!