第一次編寫簡單的中間件測試工具（2） - 讀代碼的方法

加入新員工訓練營的有開發也有測試，你們的coding水平良莠不齊。

我發現一個問題，就是當面對一個新學的語言時，咱們這期訓練營裏除了我之外全部的測試人員甚至一些開發人員都不會讀代碼，不知道怎麼去讀，或者雖然讀了，卻只知其一;不知其二，毫無效率。

 

首先分享一下我讀代碼的方法供從手工測試轉自動化測試的同窗們參考（可能各人思惟模式不一樣，僅供參考）：

我讀代碼時的思惟方式屬於一級一級嚴密的邏輯思惟，因此一旦個人邏輯鏈中間斷掉，我就不能理解這些代碼。

 

一句話總結：先跑起來，再調試，理解原理，掌握細節。

 

第一步，看有沒有文檔。遺憾的是一般要麼麼有，要麼不全。但一般咱們能找到一些參考資料，可能來自某些文檔也可能來自某些人。

在開始以前先收集全部可利用的資源，這個習慣在此次訓練營裏成功讓我從scrum master處獲得了一個「能夠不看的需求文檔」和對於整個工具架構的大體介紹。

後來我發現這個「能夠不看的需求文檔」在個人編碼過程當中起到了巨大做用， 而且令我驚訝的是，除了我之外，其餘人居然在沒有這個文檔的狀況下硬看代碼，因而他們雖然能夠看懂一部分代碼，但卻沒法徹底把這個工具轉化成「和本身寫的同樣」的內化知識。

第二步，看有沒有單元測試。有單元測試的，那麼就能夠執行單元測試。看看結果。看看測了哪些東西。有不少人不知道單元測試框架，實際上，無論你用java，c，c++，python，ruby，仍是隨便什麼語言，據我所知絕大部分語言都有本身的單元測試框架，或者叫單元測試執行器。這些名字一般叫xxxUnit的東西，全都是同樣的原理。隨便學一個，其餘都同樣掌握了。若是你是測試人員，建議你至少掌握一鍾單元測試執行器，好比java語言的testNG。有這個基礎的人才能搞自動化測試，不要等老師來教你，教比學麻煩多了。

第三步，找獨立模塊。比方說咱們的中間件測試工具裏，對消息的編碼解碼部分調用了第三方庫來作。而對第三方庫的調用和一些數據結構的準備，就是一個相對獨立的模塊。而且我發現這個獨立的模塊還有本身獨立的單元測試。因此這就是我閱讀代碼的突破口。

第四步，從突破口調試代碼。我從編碼解碼的單元測試文件裏開始單步執行他的單元測試，因而我看到了整個代碼執行的全過程，消息是如何從一段英文轉化成指定數據格式的對象，再以怎樣的方式定義消息頭設置消息長度，傳怎樣的數據給第三方庫，以及最後編碼的結果如何去驗證。這一步對後續工做的意義重大。

第五步，看核心模塊。咱們這個工具的核心模塊是消息收發的模擬器。能夠把他理解成單元測試裏的樁的概念（stub）或者驅動（driver），也有人喜歡說這是相似於mock的東西。

這個核心模塊作了幾件事：

1，創建socket鏈接，等待客戶端鏈接他。

2，使用多線程，支持複數的客戶端鏈接。

3，和客戶端之間進行消息收發。調用了我前面看到的消息編碼解碼獨立模塊，把消息封裝好，而後經過socket鏈接把消息發送出去和接收回來。

4，創建消息隊列，把和複數客戶端的通訊的消息序列分別存放。

5，即時處理須要馬上回復的消息。

6，生成一些須要自動生成的消息字段。

7，定時發送一些相似於心跳消息的東西給客戶端，以及處理對方發過來的這種消息。

第六步，從總的單元測試開始，一個一個單步調試。

第七步，爲了證實我徹底讀懂了，我本身畫了一個結構圖：

整個工具我劃成4個模塊，

1.消息編碼解碼

2.模擬器及其相關api封裝，調用消息編碼解碼模塊來發送消息

3.robot關鍵字，調用模擬器提供的api發送用戶想發的消息

4.單元測試

而且對每一個模塊內部的邏輯，畫了詳細流程圖，從哪一個類到哪一個類，瞭解清楚單元測試的執行中每一步驟的流程和消息是怎麼組裝、怎麼編碼、怎麼發送、怎麼接受回覆的。

 

所有讀完，我一共用了越24小時，也就是3天（天天8小時）。至此整個測試工具不說了如指掌，也已經掌握得八九不離十了。再看咱們要作的任務，個人感受只有兩個字：簡單。

此時咱們的其餘成員（已讀了5+3=8天這些代碼）仍在埋頭苦讀，最令我不解的是，在我以前，沒有人嘗試去執行單元測試，也沒有人去問訓練營的導師這個測試代碼可不能夠執行。

有開發人員能讀懂核心模塊，但每一個人都在重複讀，沒有造成協力。至於測試人員則都根本不知道在讀什麼東西。

因而我提議你們把本身讀的東西開會分享，讓徹底不知道在讀什麼東西的人也能對代碼有必定了解。