學寫程式之路-4

 

第一份工作的開發流程是：

1. 老闆下達需求
2. 想出做法，與導師討論
3. 開發並用SVN上傳code(Git還沒流行)
4. 導師 code review，再修正
5. QA 測試，再修正
6. merge 進主線

中間總覺得怪怪的，怎麼冒出來了個 QA(Quality Assurance，就測試人員)？他是誰…是做什麼的？所以我這次就想寫一下我學習測試的過程。

第一份工作雖然讓我奠定不錯的 OO 觀念 以及 GUI 介面的基礎，但總會想說我怎麼還一直在寫單機版的程式…完全沒碰資料庫，或者網路。 那時已經是 2013 年，我當然會惶恐了，我這樣未來還有什麼競爭力！？這時恰好有位好友說他在學及寫一個網頁的框架叫 Ruby on Rails，用起來很棒而且新創的團隊都愛用它！(2013–2014 有一波新創潮) 而且當時根本還不會 Ruby 的我立馬辭了原來的工作，在網路上選了一間好像不用什麼經驗但專用 Rails 的德商進入： Otto 甄圖。

大概簡介一下：Ruby 是一門日本人 Matz 創的程式語言, Rails 是一個用 Ruby 寫的做網站工具，由一位瑞典人 DHH 創立。總之我在懵懂間就開始了 Rails 之路，不過這倒不是重點。

重點是 104 上隨便選的一家公司十分不簡單…，讓我第一次體會到什麼叫「軟體工程」：最大的差別就是「寫測試」這件事，也就是進行「自動化測試」，整間公司完全沒有QA 人員…，所有 Code 要 Merge 到主線前前會執行一遍所有的「寫好的測試」(用 Jenkins)。大學課程裡從來沒有教授提到「測試」這件事，甚至問了許多在大公司的同學：有聽過自動測試嗎？他們也都表示那是什麼，沒聽過。像 X碩就是有大量的 QA 人員。所以對當時缺乏概念的我，真的覺得這…神了！

我前幾個月的工作幾乎都在寫測試。對從來沒接觸過測試的人來說，會想說測試不就是去試著執行程式看結果對不對嗎？然後公司會專門聘請很會亂用、亂試或熟知極限狀況的人員來手動地進行測試，就是所謂的 QA來把關上線的程式。什麼叫「寫測試」？其實就是因為 QA 畢竟也是人，手動測試常一直重複一樣的動作跟檢查一樣的結果，疲乏下很容易漏掉一些測試的 Case ，結果造成程式出現 Bug。那這些重複性質十分高的測試何不另外寫程式去執行呢？於是就有了「為程式寫測試用的程式」一事，就是「自動化測試」。雖然會覺得這樣不是球員兼裁判嗎？所以在寫測試程式的時候要盡量簡單化，要用大量人看的懂的方式去「驗證」程式的結果，否則寫一個很複雜的程式去測試另一個很複雜的程式，根本不知道問題出現在哪裡。另外重要的一點就是測試的目的是驗證程式是否有做出期望的操作，而不是克服「所有的情況」，舉個例，今天做一個很簡單的加法的方法

  
    def add(a, b)

      a + b

    end
  

要看你預期誰會呼叫這個方法，如果是個算商品價錢的程式

那可能驗證 2 加 3 會不會等於 5 就好了

test 'two numbers should be added' do
  assert_equal(5, add(2, 3))
end

不過如果今天不是在台灣，很多國家都要算小數，那就要驗證 a 或 b 是小數的情形

test 'two numbers should be added' do
  assert_equal(5, add(2, 3))
  assert_equal(5.1, add(2.1, 3))
  assert_equal(5.5, add(2.2, 3.3))
end

總之如果要考慮到所有的情形，那連一個加法的測試都很難寫完全…。所以測試也沒有一定的寫法。其實在測試開發者的輕驗

然後由自動化測試的概念延伸，有個稱為 TDD (Test Driven Development，測試驅動開發)的往開發方式。就是「先寫測試，再開發程式本身」。前面提到我前幾個月都在寫測試，其實開發主程式的人是其它人，就有點像 TDD 的變形，是同步進行的順便避免「球員兼裁判」的問題。這裡順便提一下 TDD 或有自動測試的一些好處：

1. TDD 通過了，則代表程式正常運行，至少在開發者想像的世界中
2. TDD 上的文字可以當做需求的文字。那種幾年前的需求 Spec 文件，誰找的到，test 上如有寫預期的行為，就知道為什麼程式要那樣運作了
3. 不用太去在意 code 乾淨程度，變得更 OO

第 3 我解釋一下，科科…。不論程式語言再容易學，程式語言主要要解決一些現實世界的問題，如果工作數年的人，應該可以察覺到…其實真正有解決問題能力的人不多…。就一間公司或一個團隊，真正有能力的人大概少於 20%。開發者這裡也是一樣，不是每一個開發者都有能力寫出 Clean code，或用很好的演算法去解決問題。也要知道那些特殊人才難尋，薪水很高而且非常容易被挖走。但今天如果改成讓能力很好的人去訂出系統的架構，然後開發功能時都有加上測試。這樣即使不論那些 Code 有多爛…至少整個系統是還可以 Work 的…。

總之有 TDD 的概念真的完全影響我開發時的想法，雖然我不一定會真的先寫測試再開發，但幾乎每個功能都會有一個對應的測試。如果時程十分地趕，我也會再之前不趕時再補上必要的測試。網路上還有些人認為會不會寫測試就是「業餘」跟「專業」的分別呢！

這裡就不得不也推一下 Rails 這個框架，雖然是 15 年的老框架，近年有點跟不太上 Web 前端的爆發，但它完整地將測試框架納入 Rails 中，及好用的測試相關套件實在是我持續使用它的一大主因！