後臺單元測試總結

前言

這週一開始就參與了《商務網站入門》做業提交系統的開發，因爲技術不到位，致使重置學生密碼的功能重寫了屢次，寫了好幾天，主要時間都花在後臺單元測試上了，真的是一點都不明白，而後多半天寫功能，好幾天寫測試，基本上每一次都得請教宜衡學長，在此向李宜衡學長表示感謝。

@Autowired && @MockBean

在參照其餘項目後臺單元測試的時候發現自動裝配Bean的兩種註解@Autowired和@MockBean，也不知道有什麼不一樣，只記得看到過，具體怎麼用也只是據說過，可是一到用就不會了，
@Autowired是自動裝配一個真的Bean，你可使用它全部的的功能，可是不能控制它的功能，而@MockBean是裝配一個Bean，這個Bean是克隆的，具備原來Bean的功能，可是受控制，咱們能夠控制某個方法的執行結果。
以UserServiceImpl這個類的fingByUserName方法爲例，

@Override
    public User findByUsername(String username) {
        return this.userRepository.findByUsername(username);
    }

寫一個測試Demo

public class Demo extends ServiceTest {
    @MockBean
    UserServiceImpl userService;

    @Test
    public void findByUserName(){
        String username = RandomString.make(6);
        User Mockuser = new User();
        Mockuser.setUsername(username);
        User resultUser = new User();
        Mockito.when(userService.findByUsername(username)).thenReturn(resultUser);

        Assert.assertEquals(Mockuser.getId(),resultUser.getId());
    }
}

Mockito.when(userService.findByUsername(username)).thenReturn(resultUser);

上面的代碼便實現了對findByUserName()方法的控制，此時的userService是mock出來的，在這行代碼上打一個斷點，看一下相關信息：

userService中的userRepository都是空的，說明該userRepository是模擬的，假如注入真正的userService，那麼咱們就沒法實現對方法的控制，只能添加數據發起真正的請求，斷言數據相同，假如數據量較大，測試的難度就會大大增長。

依賴注入

經過宜衡學長分享的博客深刻了解了一下依賴注入，也算對依賴注入有了更深的瞭解。
把有依賴關係的類放到容器中，解析出這些類的實例，就是依賴注入，其目的是實現類的解耦。

控制反轉（Inversion of Control，縮寫爲IoC），是面向對象編程中的一種設計原則，能夠用來減低計算機代碼之間的耦合度。其中最多見的方式叫作依賴注入（Dependency Injection，簡稱DI）。經過控制反轉，對象在被建立的時候，由一個調控系統內全部對象的外界實體，將其所依賴的對象的引用傳遞給它。也能夠說，依賴被注入到對象中。

依賴注入以前實現依賴關係：

依賴注入：

舉個不太恰當但有助於理解的例子，在沒有二手車APP或者二手車中介前，咱們想要找符合本身要求的二手車，就得四處打聽，而有了APP和中介，他們蒐集二手車信息，咱們只要說出本身的需求，中介或者APP就能根據需求提供相關信息或車輛。

經過依賴注入也順便了解了控制反轉，教程對控制反轉有着這樣的介紹：

Spring有兩個特性： IOC與 AOP。 IOC即控制反轉，因爲太過於出名，而使得網上的文章有不少。大致的意思就是說：之前咱們須要某個對象是須要本身實例化出來的；而在 Spring中，咱們只須要聲明本身須要一個具備什麼功能的對象，至於最後獲得的這個對象是誰，是由 Spring來控制來完的。在 IOC之前，對象是誰是在代碼編寫階段來控制的；而有了 IOC之後，咱們在代碼編寫階段放棄了控制了權限，而改由 Spring統一控制了。因爲控制權發生了實質性的變動，因此是 控制反轉了。

在自動注入實現以前，要想注入類，須要編程人員手動注入，編程人員擁有控制權，而擁有了Spring框架的IOC特性，Spring擁有了注入類的控制權，實現了控制的反轉。
教程地址

TDD

TDD 是測試驅動開發（Test-Driven Development），它一樣也是敏捷開發的一種方法論。TDD 是再開發代碼以前，先編寫單元測試用例，用測試的代碼肯定要編寫什麼樣的代碼。它的整個思路就是經過測試來驅動整個軟件開發的進度，固然這對測試人員來講是一個更高的要求和標準。

TDD 三大原則：

• You are not allowed to write any production code unless it is to make a failing unit test pass.
• You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
• You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

除非要使失敗的單元測試經過，不然不容許編寫任何生產代碼。

不容許您編寫的單元測試超過了失敗的數量；編譯失敗就是失敗。

不容許您編寫超過足以經過一次失敗的單元測試的生產代碼。

固然對於如今的我來講，水平確定差好多，可是感受TDD是個頗有意思的東西，也給人以樂趣吧，就像闖關遊戲同樣，一關一關闖過去，就能寫完功能，但願本身早日達到這種水平吧。

總結

這一週真的挺虐心的，早起敲到晚上，除了吃飯睡覺就是敲代碼，主要是對單元測試一竅不通，耽誤了太多的時間，終於體會到了了工欲善其事必先利其器這句話的意義。

讀了宜衡學長分享的博客，有一種恍然大悟的感受，之前感受實踐是最好的老師，但我忽略了一個前提，那就是掌握必定的知識，啥也不會就實踐，那純粹是耽誤時間。

特此鳴謝

感謝潘老師的指導，讓我對開發有了更深的體會，感謝李宜衡學長和其餘小夥伴的幫助。

參考資料

徒手擼框架--實現IoC
什麼是【TDD】
@MockBean的使用