2. 程式人生 > >談談單元測試之（三）：測試工具 JUnit 4

談談單元測試之（三）：測試工具 JUnit 4

阿新 • • 發佈：2018-12-20

前言


 上一篇文章《測試工具 JUnit 3》簡單的討論了 JUnit 3 的使用以及內部的方法。這篇文章將會在 JUnit 3 的基礎上，討論一下 JUnit 4 的新特性。同時，與 JUnit 3 做一個簡單的對比。那麼，廢話就不多說了，直接進入正題。

介紹


 JUnit 4.x 是利用了 Java 5 的特性（Annotation）的優勢，使得測試比起 3.x 版本更加的方便簡單，JUnit 4.x 不是舊版本的簡單升級，它是一個全新的框架，整個框架的包結構已經徹底改變，但 4.x 版本仍然能夠很好的相容舊版本的測試用例。

使用


 先來點實在的，看看程式碼中是怎麼使用的。其餘的待會再說。

下載



加入專案

  • 把 junit4.8.1.jar 檔案，加入到專案的 classpath 中。


對比


 在程式碼之前，先讓我們看一下 JUnit 4 和 JUnit 3 的區別，看看 JUnit 4 到底簡化了哪些東西。


演示程式碼

[java] view plain copy print ?
  1. <span style=“font-family:Microsoft YaHei;”>package com.tgb;  
  2.   
  3. import static org.junit.Assert.*;  
  4.   
  5. import org.junit.Ignore;  
  6. import org.junit.Test;  
  7.   
  8.   
  9. public class TestWordDealUtil {  
  10.     // 測試 wordFormat4DB 正常執行的情況  
  11.     @Test  
  12.     public void testWordFarmat4DBNormal() {  
  13.         String target = ”employeeInfo”;  
  14.         String result = WordDealUtil.wordFormat4DB(target);  
  15.           
  16.         assertEquals(”employee_info”, result);  
  17.     }  
  18.       
  19.     // 測試 null 時的處理情況  
  20.     @Test(expected=NullPointerException.class)  
  21.     public void testWordFormat4DBNull() {  
  22.         String target = null;  
  23.         String result = WordDealUtil.wordFormat4DB(target);  
  24.           
  25.         assertNull(result);  
  26.     }  
  27.       
  28.     // 測試空字串的處理情況  
  29.     @Test  
  30.     public void testWordFormat4DBEmpty() {  
  31.         String target = ”“;  
  32.         String result = WordDealUtil.wordFormat4DB(target);  
  33.           
  34.         assertEquals(”“, result);  
  35.     }  
  36.       
  37.     // 測試當首字母大寫時的情況  
  38.     //@Ignore  
  39.     @Test  
  40.     public void testWordFormat4DBBegin() {  
  41.         String target = ”EmployeeInfo”;  
  42.         String result = WordDealUtil.wordFormat4DB(target);  
  43.           
  44.         assertEquals(”_employee_info”, result);  
  45.     }  
  46.       
  47.     // 測試當尾字母大寫時的情況  
  48.     @Test  
  49.     public void testWordFormat4DBEnd() {  
  50.         String target = ”employeeInfoA”;  
  51.         String result = WordDealUtil.wordFormat4DB(target);  
  52.           
  53.         assertEquals(”employee_info_a”, result);  
  54.     }  
  55.       
  56.     // 測試多個相連字母字母大寫時的情況  
  57.     @Test  
  58.     public void testWordFormat4DBTogether() {  
  59.         String target = ”employeeAInfo”;  
  60.         String result = WordDealUtil.wordFormat4DB(target);  
  61.           
  62.         assertEquals(”employee_a_info”, result);  
  63.     }  
  64. }  
  65. </span>  
<span style="font-family:Microsoft YaHei;">package com.tgb;

import static org.junit.Assert.*;

import org.junit.Ignore;
import org.junit.Test;


public class TestWordDealUtil {
    // 測試 wordFormat4DB 正常執行的情況
    @Test
    public void testWordFarmat4DBNormal() {
        String target = "employeeInfo";
        String result = WordDealUtil.wordFormat4DB(target);

        assertEquals("employee_info", result);
    }

    // 測試 null 時的處理情況
    @Test(expected=NullPointerException.class)
    public void testWordFormat4DBNull() {
        String target = null;
        String result = WordDealUtil.wordFormat4DB(target);

        assertNull(result);
    }

    // 測試空字串的處理情況
    @Test
    public void testWordFormat4DBEmpty() {
        String target = "";
        String result = WordDealUtil.wordFormat4DB(target);

        assertEquals("", result);
    }

    // 測試當首字母大寫時的情況
    //@Ignore
    @Test
    public void testWordFormat4DBBegin() {
        String target = "EmployeeInfo";
        String result = WordDealUtil.wordFormat4DB(target);

        assertEquals("_employee_info", result);
    }

    // 測試當尾字母大寫時的情況
    @Test
    public void testWordFormat4DBEnd() {
        String target = "employeeInfoA";
        String result = WordDealUtil.wordFormat4DB(target);

        assertEquals("employee_info_a", result);
    }

    // 測試多個相連字母字母大寫時的情況
    @Test
    public void testWordFormat4DBTogether() {
        String target = "employeeAInfo";
        String result = WordDealUtil.wordFormat4DB(target);

        assertEquals("employee_a_info", result);
    }
}
</span>


從圖中可以看出，TestWordDealUtil 測試類中，有6個測試方法，其中有5個測試方法都已經通過，另外一個丟擲了 NullPointerException （空指標）異常，需要注意的是，這裡並不是單元測試的失敗（Failure），而是測試出現了錯誤（Error）。那麼，這兩種有什麼區別呢？下面就討論一下這兩者的區別。
JUnit 將測試失敗的情況分為兩種：Failure 和 Error 。 Failure 一般是由單元測試使用的斷言方法判斷失敗引起的，它表示在測試點發現了問題（程式中的 bug）；而 Error 則是有程式碼異常引起的，這是測試目的之外的發現，它可能產生於測試程式碼本身的錯誤（也就是說，編寫的測試程式碼有問題），也可能是被測試程式碼中的一個隱藏 bug 。不過，一般情況下是第一種情況。

深入

常用註解

  • @Before
初始化方法，在任何一個測試方法執行之前，必須執行的程式碼。對比 JUnit 3 ，和 setUp（）方法具有相同的功能。在該註解的方法中，可以進行一些準備工作，比如初始化物件，開啟網路連線等。
  • @After
釋放資源，在任何一個測試方法執行之後，需要進行的收尾工作。對比 JUnit 3 ，和 tearDown（）方法具有相同的功能。
  • @Test
測試方法，表明這是一個測試方法。在 JUnit 中將會自動被執行。對與方法的宣告也有如下要求：名字可以隨便取，沒有任何限制，但是返回值必須為 void ，而且不能有任何引數。如果違反這些規定，會在執行時丟擲一個異常。不過，為了培養一個好的程式設計習慣，我們一般在測試的方法名上加 test ，比如：testAdd（）。
同時，該 Annotation（@Test） 還可以測試期望異常和超時時間，如 @Test（timeout=100），我們給測試函式設定一個執行時間，超過這個時間（100毫秒），他們就會被系統強行終止，並且系統還會向你彙報該函式結束的原因是因為超時，這樣你就可以發現這些 bug 了。而且，它還可以測試期望的異常，例如，我們剛剛的那個空指標異常就可以這樣：@Test(expected=NullPointerException.class)。再來看一下測試結果。



  • @Ignore
忽略的測試方法，標註的含義就是“某些方法尚未完成，咱不參與此次測試”；這樣的話測試結果就會提示你有幾個測試被忽略，而不是失敗。一旦你完成了相應的函式，只需要把 @Ignore 註解刪除即可，就可以進行正常測試了。當然，這個 @Ignore 註解對於像我這樣有“強迫症”的人還是大有意義的。每當看到紅色條（測試失敗）的時候就會全身不舒服，感覺無法忍受（除非要測試的目的就是讓它失敗）。當然，對程式碼也是一樣，無法忍受那些雜亂不堪的程式碼。所以，建議大家都寫漂亮的程式碼。這樣人人都喜歡看你的程式碼。哎，有強迫症的人傷不起啊！
  • @BeforeClass
針對所有測試，也就是整個測試類中，在所有測試方法執行前，都會先執行由它註解的方法，而且只執行一次。當然，需要注意的是，修飾符必須是 public static void xxxx ；此 Annotation 是 JUnit 4 新增的功能。
  • @AfterClass
針對所有測試，也就是整個測試類中，在所有測試方法都執行完之後，才會執行由它註解的方法，而且只執行一次。當然，需要注意的是，修飾符也必須是 public static void xxxx ；此 Annotation 也是 JUnit 4 新增的功能，與 @BeforeClass 是一對。

執行順序


 所以，在 JUnit 4 中，單元測試用例的執行順序為：



每一個測試方法的呼叫順序為：





規範


 最後，在來說說關於測試的規範，這些規範是從程式設計規則，以及日常的實踐中，由那些大牛們總結出來的。作為後人的我們，在大樹下乘涼的同時，更要遵守這些規則，使得大樹更加茁壯成長。
  • 單元測試程式碼應位於單獨的 Source Folder 下
此 Source Folder 通常為 test ，這樣可以方便的管理業務程式碼與測試程式碼。其實，在專案管理工具 Maven 上已經做了這種規範了。在我們自己寫程式碼時，注意一下即可。


  • 測試類應該與被測試類位於同一 package 下
便於進行管理，同時減少引入帶測試類的麻煩。



  • 選擇有意義的測試方法名
無論是 JUnit 4 ，還是 JUnit 3 ，單元測試方法名均需使用 test<待測試方法名稱>[概要描述] ，如 public void testDivideDivisorIsZero() ，很容易知道測試方法的含義。
  • 儲存測試的獨立性
每項單元測試都必須獨立於其他所有單元測試而執行，因為單元測試需能以任何順序執行。
  • 為暫時未實現的測試程式碼忽略（@Ignore）或丟擲失敗（fail）
在 JUnit 4 中，可以在測試方法上使用註解 @Ignore 。在 JUnit 3 中，可以在未實現的測試方法中使用 fail(“測試方法未實現”); 以告知失敗是因為測試方法未實現。
  • 在呼叫斷言（assert）方法時給出失敗的原因
在使用斷言方法時，請使用帶有 message 引數的 API ，並在呼叫時給出失敗時的原因描述，如 assertNotNull（”物件為空”, new Object()）。

結束語


 請牢記：測試任何可能的錯誤。單元測試不是用來證明您是對的，而是為了證明您沒有錯。
JUnit 4 到這裡就差不多了，如果文章中有什麼不對的地方，還希望各位大牛拍磚。說了這麼多，能真正用上才是王道，當然，希望以我這篇文章為契機，IT 界的精英們，之前沒有用單元測試的，能夠喚醒你們體內的小宇宙；之前已經在用的，也能夠再體會一番，提高開發的效率，寫出 漂亮 的程式碼。

資料：本文中的Demo（下載地址）

【原創】地址：http://blog.csdn.net/happylee6688/article/details/38069761這裡寫連結內容


前言


 上一篇文章《測試工具 JUnit 3》簡單的討論了 JUnit 3 的使用以及內部的方法。這篇文章將會在 JUnit 3 的基礎上，討論一下 JUnit 4 的新特性。同時，與 JUnit 3 做一個簡單的對比。那麼，廢話就不多說了，直接進入正題。

介紹


 JUnit 4.x 是利用了 Java 5 的特性（Annotation）的優勢，使得測試比起 3.x 版本更加的方便簡單，JUnit 4.x 不是舊版本的簡單升級，它是一個全新的框架，整個框架的包結構已經徹底改變，但 4.x 版本仍然能夠很好的相容舊版本的測試用例。

使用


 先來點實在的，看看程式碼中是怎麼使用的。其餘的待會再說。

下載



加入專案

  • 把 junit4.8.1.jar 檔案，加入到專案的 classpath 中。


對比


 在程式碼之前，先讓我們看一下 JUnit 4 和 JUnit 3 的區別，看看 JUnit 4 到底簡化了哪些東西。



演示程式碼

[java] view plain copy print ?
  1. <span style=“font-family:Microsoft YaHei;”>package com.tgb;  
  2.   
  3. import static org.junit.Assert.*;  
  4.   
  5. import org.junit.Ignore;  
  6. import org.junit.Test;  
  7.   
  8.   
  9. public class TestWordDealUtil {  
  10.     // 測試 wordFormat4DB 正常執行的情況  
  11.     @Test  
  12.     public void testWordFarmat4DBNormal() {  
  13.         String target = ”employeeInfo”;  
  14.         String result = WordDealUtil.wordFormat4DB(target);  
  15.           
  16.         assertEquals(”employee_info”, result);  
  17.     }  
  18.       
  19.     // 測試 null 時的處理情況  
  20.     @Test(expected=NullPointerException.class)  
  21.     public void testWordFormat4DBNull() {  
  22.         String target = null;  
  23.         String result = WordDealUtil.wordFormat4DB(target);  
  24.           
  25.         assertNull(result);  
  26.     }  
  27.       
  28.     // 測試空字串的處理情況  
  29.     @Test  
  30.     public void testWordFormat4DBEmpty() {  
  31.         String target = ”“;  
  32.         String result = WordDealUtil.wordFormat4DB(target);  
  33.           
  34.         assertEquals(”“, result);  
  35.     }  
  36.       
  37.     // 測試當首字母大寫時的情況  
  38.     //@Ignore  
  39.     @Test  
  40.     public void testWordFormat4DBBegin() {  
  41.         String target = ”EmployeeInfo”;  
  42.         String result = WordDealUtil.wordFormat4DB(target);  
  43.           
  44.         assertEquals(”_employee_info”, result);  
  45.     }  
  46.       
  47.     // 測試當尾字母大寫時的情況  
  48.     @Test  
  49.     public void testWordFormat4DBEnd() {  
  50.         String target = ”employeeInfoA”;  
  51.         String result = WordDealUtil.wordFormat4DB(target);  
  52.           
  53.         assertEquals(”employee_info_a”, result);  
  54.     }  
  55.       
  56.     // 測試多個相連字母字母大寫時的情況  
  57.     @Test  
  58.     public void testWordFormat4DBTogether() {  
  59.         String target = ”employeeAInfo”;  
  60.         String result = WordDealUtil.wordFormat4DB(target);  
  61.           
  62.         assertEquals(”employee_a_info”, result);  
  63.     }  
  64. }  
  65. </span>  
<span style="font-family:Microsoft YaHei;">package com.tgb;

import static org.junit.Assert.*;

import org.junit.Ignore;
import org.junit.Test;


public class TestWordDealUtil {
    // 測試 wordFormat4DB 正常執行的情況
    @Test
    public void testWordFarmat4DBNormal() {
        String target = "employeeInfo";
        String result = WordDealUtil.wordFormat4DB(target);

        assertEquals("employee_info", result);
    }

    // 測試 null 時的處理情況
    @Test(expected=NullPointerException.class)
    public void testWordFormat4DBNull() {
        String target = null;
        String result = WordDealUtil.wordFormat4DB(target);

        assertNull(result);
    }

    // 測試空字串的處理情況
    @Test
    public void testWordFormat4DBEmpty() {
        String target = "";
        String result = WordDealUtil.wordFormat4DB(target);

        assertEquals("", result);
    }

    // 測試當首字母大寫時的情況
    //@Ignore
    @Test
    public void testWordFormat4DBBegin() {
        String target = "EmployeeInfo";
        String result = WordDealUtil.wordFormat4DB(target);

        assertEquals("_employee_info", result);
    }

    // 測試當尾字母大寫時的情況
    @Test
    public void testWordFormat4DBEnd() {
        String target = "employeeInfoA";
        String result = WordDealUtil.wordFormat4DB(target);

        assertEquals("employee_info_a", result);
    }

    // 測試多個相連字母字母大寫時的情況
    @Test
    public void testWordFormat4DBTogether() {
        String target = "employeeAInfo";
        String result = WordDealUtil.wordFormat4DB(target);

        assertEquals("employee_a_info", result);
    }
}
</span>


從圖中可以看出，TestWordDealUtil 測試類中，有6個測試方法，其中有5個測試方法都已經通過，另外一個丟擲了 NullPointerException （空指標）異常，需要注意的是，這裡並不是單元測試的失敗（Failure），而是測試出現了錯誤（Error）。那麼，這兩種有什麼區別呢？下面就討論一下這兩者的區別。
JUnit 將測試失敗的情況分為兩種：Failure 和 Error 。 Failure 一般是由單元測試使用的斷言方法判斷失敗引起的，它表示在測試點發現了問題（程式中的 bug）；而 Error 則是有程式碼異常引起的，這是測試目的之外的發現，它可能產生於測試程式碼本身的錯誤（也就是說，編寫的測試程式碼有問題），也可能是被測試程式碼中的一個隱藏 bug 。不過，一般情況下是第一種情況。

深入

常用註解

  • @Before
初始化方法，在任何一個測試方法執行之前，必須執行的程式碼。對比 JUnit 3 ，和 setUp（）方法具有相同的功能。在該註解的方法中，可以進行一些準備工作，比如初始化物件，開啟網路連線等。
  • @After
釋放資源，在任何一個測試方法執行之後，需要進行的收尾工作。對比 JUnit 3 ，和 tearDown（）方法具有相同的功能。
  • @Test
測試方法，表明這是一個測試方法。在 JUnit 中將會自動被執行。對與方法的宣告也有如下要求：名字可以隨便取，沒有任何限制，但是返回值必須為 void ，而且不能有任何引數。如果違反這些規定，會在執行時丟擲一個異常。不過，為了培養一個好的程式設計習慣，我們一般在測試的方法名上加 test ，比如：testAdd（）。
同時，該 Annotation（@Test） 還可以測試期望異常和超時時間，如 @Test（timeout=100），我們給測試函式設定一個執行時間，超過這個時間（100毫秒），他們就會被系統強行終止，並且系統還會向你彙報該函式結束的原因是因為超時，這樣你就可以發現這些 bug 了。而且，它還可以測試期望的異常，例如，我們剛剛的那個空指標異常就可以這樣：@Test(expected=NullPointerException.class)。再來看一下測試結果。



  • @Ignore
忽略的測試方法，標註的含義就是“某些方法尚未完成，咱不參與此次測試”；這樣的話測試結果就會提示你有幾個測試被忽略，而不是失敗。一旦你完成了相應的函式，只需要把 @Ignore 註解刪除即可，就可以進行正常測試了。當然，這個 @Ignore 註解對於像我這樣有“強迫症”的人還是大有意義的。每當看到紅色條（測試失敗）的時候就會全身不舒服，感覺無法忍受（除非要測試的目的就是讓它失敗）。當然，對程式碼也是一樣，無法忍受那些雜亂不堪的程式碼。所以，建議大家都寫漂亮的程式碼。這樣人人都喜歡看你的程式碼。哎，有強迫症的人傷不起啊！
  • @BeforeClass
針對所有測試，也就是整個測試類中，在所有測試方法執行前，都會先執行由它註解的方法，而且只執行一次。當然，需要注意的是，修飾符必須是 public static void xxxx ；此 Annotation 是 JUnit 4 新增的功能。
  • @AfterClass
針對所有測試，也就是整個測試類中，在所有測試方法都執行完之後，才會執行由它註解的方法，而且只執行一次。當然，需要注意的是，修飾符也必須是 public static void xxxx ；此 Annotation 也是 JUnit 4 新增的功能，與 @BeforeClass 是一對。

執行順序


 所以，在 JUnit 4 中，單元測試用例的執行順序為：



每一個測試方法的呼叫順序為：





規範


 最後，在來說說關於測試的規範，這些規範是從程式設計規則，以及日常的實踐中，由那些大牛們總結出來的。作為後人的我們，在大樹下乘涼的同時，更要遵守這些規則，使得大樹更加茁壯成長。
  • 單元測試程式碼應位於單獨的 Source Folder 下
此 Source Folder 通常為 test ，這樣可以方便的管理業務程式碼與測試程式碼。其實，在專案管理工具 Maven 上已經做了這種規範了。在我們自己寫程式碼時，注意一下即可。


  • 測試類應該與被測試類位於同一 package 下
便於進行管理，同時減少引入帶測試類的麻煩。



  • 選擇有意義的測試方法名
無論是 JUnit 4 ，還是 JUnit 3 ，單元測試方法名均需使用 test<待測試方法名稱>[概要描述] ，如 public void testDivideDivisorIsZero() ，很容易知道測試方法的含義。
  • 儲存測試的獨立性
每項單元測試都必須獨立於其他所有單元測試而執行，因為單元測試需能以任何順序執行。
  • 為暫時未實現的測試程式碼忽略（@Ignore）或丟擲失敗（fail）
在 JUnit 4 中，可以在測試方法上使用註解 @Ignore 。在 JUnit 3 中，可以在未實現的測試方法中使用 fail(“測試方法未實現”); 以告知失敗是因為測試方法未實現。
  • 在呼叫斷言（assert）方法時給出失敗的原因
在使用斷言方法時，請使用帶有 message 引數的 API ，並在呼叫時給出失敗時的原因描述，如 assertNotNull（”物件為空”, new Object()）。

結束語


 請牢記：測試任何可能的錯誤。單元測試不是用來證明您是對的，而是為了證明您沒有錯。
JUnit 4 到這裡就差不多了，如果文章中有什麼不對的地方，還希望各位大牛拍磚。說了這麼多，能真正用上才是王道，當然，希望以我這篇文章為契機，IT 界的精英們，之前沒有用單元測試的，能夠喚醒你們體內的小宇宙；之前已經在用的，也能夠再體會一番，提高開發的效率，寫出 漂亮 的程式碼。

資料：本文中的Demo（下載地址）

【原創】地址：http://blog.csdn.net/happylee6688/article/details/38069761這裡寫連結內容

相關推薦

談談單元測試之（三）：測試工具 JUnit 4

前言 上一篇文章《測試工具 JUnit 3》簡單的討論了 JUnit 3 的使用以及內部的方法。這篇文章將會在 JUnit 3 的基礎上，討論一下 JUnit 4 的新特性。同時，與 JUnit 3 做一個簡單的對比。那麼，廢話就不多說了，直

談談單元測試之（四）：測試工具 TestNG

前言 上一篇文章《測試工具 JUnit 4》中提到了 JUnit 4，並對 JUnit 4 做了簡單的討論，這篇文章我們將要圍繞另一款測試工具討論 —— TestNG。其實，這篇文章應該寫在《測試工具 JUnit 3》之後，和《測試工具 JU

談談單元測試之（二）：測試工具 JUnit 3

前言 上一篇文章《 為什麼要進行煩人的單元測試？》討論了一下現階段軟體開發中，程式設計師們測試情況的現狀。這篇文章中，我打算介紹一下單元測試的工具（外掛），並且推薦大家以後在開發中，真正的用上單元測試，用好單元測試。

談談單元測試之（一）：為什麼要進行煩人的單元測試？

前言 最近，在網上看到過一個調查，調查的內容是“程式設計師在專案開發中編寫單元測試的情況”。當然，至於調查的結果，我想聰明的你已經可以猜到了。高達 58.3% 的比例，一般情況下不寫單元測試，只有偶爾的情況才會寫寫。16.6%

淺談單元測試之（一）：單元測試的意義

單元測試是檢查一個獨立工作單元的行為。在JAVA應用程式中，獨立工作單元經常是（但不總是）一個獨立的方法。相比之下，整合測試和驗收測試檢查的是各種元件如何互動。一個工作單元就是一項任務，不直接依賴於其

性能測試入門（三）：性能測試工具

需求 pre tor 不足 廠商 ecdh 腳本編寫 ssi 3.1 這篇文章介紹下性能測試工具： 簡單模擬工具 有很多場景下，我們只是想做一個簡單的壓測，對於監測結果要求並不高，壓測的場景也比較簡單，不想安裝復雜的工具，這種情況下，推薦使用簡單的模擬工具進行就可以了。 a

立體匹配之（三）： A Deep Visual Correspondence Embedding Model for Stereo Matching Costs

摘要 也是基於patches的匹配 加入亮度資訊 最後基於全域性優化 可惜沒有公開程式碼，在KITTI2012資料集上排在16,沒有在2015上排。 1 Introduction This deep embedding model leverages

webUI自動化測試框架（三）：程式碼分層-物件庫層

前言：做UI自動化，不可避免的要和頁面上的元素打交道，有的童鞋可能會選擇把頁面元素的定位，操作都寫在測試程式碼中，當頁面元素比較少，測試程式碼比較少的情況下還好，但是一旦頁面元素多起來（實際運用中也不太可能少），測試程式碼一多，就難以閱讀和維護了，因為元素定位的程式碼並不能

Linux kernel的中斷子系統之（三）：IRQ number和中斷描述符

總結： 二描述了中斷處理示意圖，以及關中斷、開中斷，和IRQ number重要概念。 三介紹了三個重要的結構體，irq_desc、irq_data、irq_chip及其之間關係。 四介紹了irq_desc這個全域性變數的初始化，五是操作中斷描述符相關結構體的API介面介紹。 一、前言 本文主要圍繞IRQ

Stereo Matching文獻筆記之（三）：經典演算法Semi-Global Matching（SGM）之碉堡的動態規劃

上一篇部落格中提到了SGM的第一部分，基於分層互資訊（HMI）的代價計算，本文繼續說說自己對SGM代價聚合部分的理解。 (轉載：http://blog.csdn.net/wsj998689aa/article/details/50488249, 作者：迷霧forest)

RPG遊戲《黑暗之光》流程介紹與程式碼分析之（三）：角色控制系統的實現

第三章：角色控制本篇部落格主要對人物移動及其相關操作進行分析，主要包括主角以及鏡頭的移動。在遊戲介面中，我們使用Camera作為視角。為了方便之後判斷當前tag，我們新建一個Tag指令碼，存入一些tag資訊，之後呼叫就不容易出錯using UnityEngine; using

Pytest測試框架（三）：pytest fixture 用法

xUnit style 結構的 fixture用於初始化測試函式， pytest fixture是對傳統的 xUnit 架構的setup/teardown功能的改進。pytest fixture為測試準備一個良好的測試環境，測試函式使用的每個 fixture通常有一個引數(以 fixture 命名)，測試函式

.NET Core之單元測試（三）：Mock框架Moq的使用

編寫一個API 新增一個介面 public interface IFoo { bool Ping(string ip); } 介面實現 public class Foo : IFoo { public bool Ping(string ip) { return new

JUnit自動化單元測試（三）：各常用註解和測試函式詳細講解

@Test：將一個方法修飾成一個可測試的方法；只有@Test修飾之後，這個方法才會被JUnit執行。 @Test（expected=XXException.class）：表示這個方法一定會丟擲某個異常

Android單元測試的利器：Juint（三）：Juint的詳細用法（上）

前言 這幾天正在成都出差，欣賞著成都的妹紙。 當我開始寫這篇的時候是上週五，沒想到這麼快就星期二了，東西越寫越多，為了保持文章儘量短小精悍，Juint的詳細用法就分成多篇來寫把，具體能寫幾篇我也不清楚… 正文 Assertions（斷言） 斷言

一個鹹魚的Python爬蟲之路（三）：爬取網頁圖片

you os.path odin 路徑 生成 存在 parent lose exist 學完Requests庫與Beautifulsoup庫我們今天來實戰一波，爬取網頁圖片。依照現在所學只能爬取圖片在html頁面的而不能爬取由JavaScript生成的圖。所以我找了這個網站

架構漫談（三）：如何做好架構之識別問題

答案 跟著 發生 做了 解決 長時間 一閃而過 開發 問題解決 按照之前架構的定義，做好架構首先需要做的就是識別出需要解決的問題。一般來說，如果把真正的問題找到，那麽問題就已經解決了80%了。這個能力基本上就決定了架構師的水平。 那麽面對問題有哪些困難呢? 我們先看一

C#可擴展編程之MEF學習筆記（三）：導出類的方法和屬性（轉）

學習 說了 如何 mod ati dem ont num imp 前面說完了導入和導出的幾種方法，如果大家細心的話會註意到前面我們導出的都是類，那麽方法和屬性能不能導出呢？？？答案是肯定的，下面就來說下MEF是如何導出方法和屬性的。 　　還是前面的代碼，第二篇中已經提供了下

機器學習之支持向量機（三）：核函數和KKT條件的理解

麻煩 ron 現在 調整 所有 核函數 多項式 err ges 註：關於支持向量機系列文章是借鑒大神的神作，加以自己的理解寫成的；若對原作者有損請告知，我會及時處理。轉載請標明來源。 序： 我在支持向量機系列中主要講支持向量機的公式推導，第一部分講到推出拉格朗日對偶函數的對

Sping Boot入門到實戰之入門篇（三）：Spring Boot屬性配置

git 測試 add 禁用 rop fix ron org set 　　該篇為Sping Boot入門到實戰系列入門篇的第三篇。介紹Spring Boot的屬性配置。 　　傳統的Spring Web應用自定義屬性一般是通過添加一個demo.properties配置文件（