rebar is an Erlang build tool that makes it easy to compile and
test Erlang applications, port drivers and releases.

rebar is a self-contained Erlang script, so it’s easy to distribute or even
embed directly in a project. Where possible, rebar uses standard Erlang/OTP
conventions for project structures, thus minimizing the amount of build
configuration work. rebar also provides dependency management, enabling
application writers to easily re-use common libraries from a variety of
locations (git, hg, etc).

common_test是Erlang強大的黑盒測試框架 參見這裡

Common Test is a portable application for automated testing. It is suitable for black-box testing of target systems of
any type (i.e. not necessarily implemented in Erlang), as well as for white-box testing of Erlang/OTP programs. Blackbox
testing is performed via standard O&M interfaces (such as SNMP, HTTP, Corba, Telnet, etc) and, if required, via
user specific interfaces (often called test ports). White-box testing of Erlang/OTP programs is easily accomplished by
calling the target API functions directly from the test case functions. Common Test also integrates usage of the OTP
cover tool for code coverage analysis of Erlang/OTP programs.
Common Test executes test suite programs automatically, without operator interaction. Test progress and results is
printed to logs on HTML format, easily browsed with a standard web browser. Common Test also sends notifications
about progress and results via an OTP event manager to event handlers plugged in to the system. This way users can
integrate their own programs for e.g. logging, database storing or supervision with Common Test.
Common Test provides libraries that contain useful support functions to fill various testing needs and requirements.
There is for example support for flexible test declarations by means of so called test specifications. There is also
support for central configuration and control of multiple independent test sessions (towards different target systems)
running in parallel.
Common Test is implemented as a framework based on the OTP Test Server application.

但是common_test由於太強大了，新手使用起來會比較麻煩，經常會碰到些問題，不好解決。

這時候rebar來救助了，它的ct功能把common_test使用的麻煩給解決掉了，讓你輕鬆做測試。
我們先來體驗下：

$ mkdir foo
$ cd foo/
$ touch rebar.config
$ rebar create-app appid=foo
==> foo (create-app)
Writing src/foo.app.src
Writing src/foo_app.erl
Writing src/foo_sup.erl
$ rebar  create template=ctsuite
==> foo (create)
Writing test/mymodule_SUITE.erl
$ rebar ct suite=mymodule
==> foo (ct)
DONE. Testing chuba.foo.mymodule_SUITE: TEST COMPLETE, 0 ok, 0 failed, 1 skipped of 1 test cases
$ cd logs
$ hostname -i
10.232.31.89
$ python -m SimpleHTTPServer 
Serving HTTP on 0.0.0.0 port 8000 ...

打卡瀏覽器 http://10.232.31.89:8000我們可以看到:

上面我們演示了rebar的ct功能使用的基本步驟，底下是進階資訊：
我們從rebar_ct.erl中可以看到：

%% Global options:
%% verbose=1 - show output from the common_test run as it goes
%% suite="foo"" - runs <test>/foo_SUITE
%% case="mycase" - runs individual test case foo_SUITE:mycase
...
get_ct_config_file(TestDir) ->
    Config = filename:join(TestDir, "test.config"),
    case filelib:is_regular(Config) of
        false ->        
            " ";
        true ->
            " -ct_config " ++ Config
    end.
...
get_config_file(TestDir) ->
    Config = filename:join(TestDir, "app.config"),
    case filelib:is_regular(Config) of
        false ->
            " ";
        true ->
            " -config " ++ Config
    end.

如果test目錄下有app.config 那麼會把它用-config app.config傳給vm, 這個app.config主要用於設定application的環境變數。

如果有test.config, 那麼會把它用 -ct_config test.config傳給vm, 這個test.config主要用於配置測試案例的變數。

test.config規格是類似這樣的，可以參見common_test userguide裡面配置的章節：
{key, value}.
{catalog, [{k1,v1}, {k2, v2}]}.

程式裡面要用方式獲取：
ct:get_config(key).
ct:get_config({catalog,key}).

獲取配置的方式有底下幾種，是很容易混淆的地方,我來解釋下：

test_mymodule(_Config) ->
    io:format("port ~p~n", [ct:get_config({foo, port})]),  
    io:format("priv_dir ~p~n", [?config(priv_dir, _Config)]),      
    io:format("priv_dir ~p~n", [proplists:get_value(priv_dir, Config)]),      
    ok.

?config(key, Config).只是用於讀取config變數裡面的值,和proplists:get_value(key, Config)是一樣的。
看程式碼:

-define(config,test_server:lookup_config).
lookup_config(Key,Config) ->
    case lists:keysearch(Key,1,Config) of
    {value,{Key,Val}} ->
            Val;
        _ ->
            io:format("Could not find element ~p in Config.~n",[Key]),
            undefined
    end.

現在我們來演示下test.config的使用：

$ pwd
/home/chuba/foo/test
$ cat test.config 
{foo, [{hostname, "127.0.0.1"},
       {port, 8000}
      ]}.
$ diff mymodule_SUITE.erl mymodule_SUITE.erl.orig
164c164
<     [{require, foo}, {userdata,[{doc,"Testing the mymodule module"}]}].
---
>     [{userdata,[{doc,"Testing the mymodule module"}]}].
167,168c167
<     io:format("port ~p~n", [ct:get_config({foo, port})]),  
<     ok.
---
>     {skip,"Not implemented."}.
$ rebar ct suite=mymodule
==> foo (ct)
DONE. Testing chuba.foo.mymodule_SUITE: TEST COMPLETE, 1 ok, 0 failed of 1 test cases

我們看下現在的執行結果：

當然也可以用ct_run來執行：

$ct_run -suite $PWD/mymodule_SUITE -pa $PWD/ebin -logdir $PWD/logs -config test/test.config 
Erlang R14B04 (erts-5.8.5)  [64-bit] [smp:16:16] [rq:16] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.8.5  (abort with ^G)

Common Test v1.5.5 starting (cwd is /home/chuba/foo)

([email protected])1> 
Common Test: Running make in test directories...

CWD set to: "/home/chuba/foo/logs/[email protected]_11.52.21"

TEST INFO: 1 test(s), 1 case(s) in 1 suite(s)

Testing chuba.foo.mymodule_SUITE: Starting test, 1 test cases
Testing chuba.foo.mymodule_SUITE: TEST COMPLETE, 1 ok, 0 failed of 1 test cases

Updating /home/chuba/foo/logs/index.html... done
Updating /home/chuba/foo/logs/all_runs.html... done

我們可以看到ct_run是通過-config foo.config 這樣來傳配置檔案的，這個地方和容易和erl -config app.config混淆。
實際上ct_run是個程式，我們看下他的程式碼：

//ct_run.c
...
else if (cnt < erl_args) {
            if (strcmp(argv[1], "-config") == 0)
                PUSH("-ct_config");
            else if (strcmp(argv[1], "-decrypt_key") == 0)
                PUSH("-ct_decrypt_key");
            else if (strcmp(argv[1], "-decrypt_file") == 0)
                PUSH("-ct_decrypt_file");
            else
                PUSH(argv[1]);
        }
...

-config選項會被轉化成-ct_config來傳遞給vm,所以和-config app.config就能分開，但是理解起來確實很惱人。

小結： rebar和common_test配合起來用的很爽。
祝玩得開心。

Post Footer automatically generated by wp-posturl plugin for wordpress.