今天學習了下erlang單元測試，發現非常有用，現在做個總結：
我們先看乙個例子（吐槽下iteye的erlang**高亮）：
[img]
這個module負責計算1到n的和，現在我們如何確認這個module功能的正確性呢？
方法1：你可以再shell終端下，不斷輸入測試引數，然後驗證程式輸出結果，這種方法比較簡單，而且可能也是每個人的首選方式，但是當我們日後不斷對module進行修改，為了能夠保證功能的正確性，我們又必須把以前的測試資料再輸入一遍，所以這種方式不可持續發展；
方法2：編寫單元測試，「一勞永逸」（下次改完module**，我們只要跑下單元測試即可）
單元測試**：
[img]
[b]需要注意的幾點：[/b]
1.單元測試的module名 = 需要測試的module名 + "_tests"字尾（或者_test_字尾），譬如這裡我需要測試diaocow.erl，那麼我的單元測試**就是diaocow_tests.erl；
2.測試方法名需要以"_test"為字尾；
3.單元測試需要引入標頭檔案：-include_lib("eunit/include/eunit.hrl")
現在我們來執行單元測試（需要先編譯）
[img]
其中：1.erlc 是編譯命令，erlc *.erl表示編譯當前目錄下所有erlang原始檔；
2.eunit:test(module) 執行某個module的單元測試
到目前似乎一切都ok了，但是你有沒有發現**目錄實在是太亂了，原始檔，單元測試檔案，位元組碼檔案都放在乙個目錄下，現在我們就按照業界標準來把它們分下類：
[table]
|src| 存放程式源**檔案|
|ebin| 存放編譯後的位元組碼檔案|
|test| 存放單元測試源**檔案|
[/table]
如下圖[img]
現在我們執行編譯：
[img]
-o 引數用來指定編譯後的位元組碼存放目錄（這裡是ebin）
現在我們在重新執行下單元測試：
[img]
-pa引數用來指定執行檔案（.beam）目錄
為了更方便的建立/編譯erlang工程專案，我自己寫了兩個簡單的指令碼：
1.erlang工程建立指令碼
[img]
2.erlang工程編譯指令碼
[img]
為了能夠更方便的使用這兩個指令碼，我們在.bashrc檔案中配置alias（新增快捷鍵）
[img]
我們看下指令碼執行效果：
1.建立erlang專案
[img]
2.編譯erlang專案(若編譯正常，則自動進入erl shell）
[img]
其實上面指令碼所提供的功能，rebar都提供了，而且更加強大完善(搜尋 erlang rebar)
Erlang單元測試
include eunit include eunit.hrl test 0,test test use exceptions to signal failures using assert macros eunit test module module test putting tests in ...
單元測試 單元測試文章收藏
前言 前段時間公司計畫做自動化測試，自己也打算圍繞幾個點做相關調研，現在想想呢？其實對自動化測試的概念都還不是十分清晰，當時主要還是圍繞 單元測試 向qa小夥伴學習了一段時間，現由於公司重組，學習中斷，這裡簡單記錄一些單元測試好文，留待後續參考.什麼叫自動化測試？自動化測試覆蓋率？覆蓋率如何做到的？...
單元測試之Django單元測試
每個應用，自帶tests.py 整合在django的專案檔案裡，更多是開發人員寫django自動的測試執行 3.1 前後置方法執行特點 django.test.testcase類主要由前 後置處理方法和test開頭的方法組成 特點 繼承於django.test.testcase 測試用例都是test...