VOYAGE GROUP　エンジニアブログ

voyagegroup_techのブログ
VOYAGE GROUPエンジニアブログです。

TDD

2014年09月24日14:15
カテゴリ
programming
testing

QUnit+PhantomJS+JenkinsでJavaScriptの品質を改善！

はじめまして！cosmiRelationshipSuiteの開発者であるマルィシェフ・ドミトリーと申します。
 
世の中で、Webベースシステムが増えており、管理画面の開発を担当している、エンジニアの視野から抜けがちであるJavaScriptのテストについてお話します。
最近の数年、TDD概念が非常に流行っており、Model(ビジネスロジック)をテストするJUnitやPHPUnitの利用は当たり前のようなことになりました。
それと同じく、JS(要するに、Front側のロジック)のテストがをしっかりできる環境として、QUnit+PhantomJS+Jenkinsの組み合わせを紹介したいと思います。

初めに
この度、localhostで開発・テスト・本番環境を設定し、開発→テスト→本番マシンへの展開を再現し、
JavaScriptのTDDを実践で試してみましょう。

利用するツールに関して 

Jenkins
CI（Continuous Integration→継続的インテグレーション）のツールです。
Jenkinsの詳しい資料は、http://jenkins-ci.org/にあります。

PhantomJS
PhantomJSはJavaScript APIで動くヘッドレスWebKitです。要するに、ブラウザーがなくてもJavaScriptが実行できる仕組みを提供していただいております。
PhantomJSについて、http://phantomjs.org/　をお読みください。

QUnit
QUnitはJavaScriptのUnit Testing Frameworkです。その大きなメリットは、
  • 非常にlightweightである
  • 学習コストが安い
  • 豊富なpluginが用意されている
  • synchronous/asynchronous callbackのテストが可能
  • モジュール定義により、htmlファイル毎にJSテストを分けることもできる
QUnitの利用に関して、詳しくはhttp://qunitjs.com/cookbook/#introductionをご覧ください。

早速、環境を用意しましょう。。。

前提条件
gitがマシンに既にインストールされていて、GitHubのアカウントを保有していること。

1. PhantomJSをインストール
ローカルフォルダーの下にgit cloneでPhantomJSを取得し、下記の手順に従い、ビルドしてください。
私の場合、/myprojects/phantomjsにgithubからcloneしました。
mkdir /myprojects
cd /myprojects
git clone git://github.com/ariya/phantomjs.git
そこからQUnitを実行するスクリプトを呼び出します。でも、それについて、後程。。。

そして、PhantomJSをインストールします。
sudo apt-get update 
sudo apt-get install phantomjs
ビルドに関して、http://phantomjs.org/build.html　に書いてあります。
※ ビルドは数時間かかる場合もございます。 

2. Jenkinsをインストール
wget -q -O - https://jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -
sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ >　/etc/apt/sources.list.d/jenkins.list'
sudo apt-get update
sudo apt-get install jenkins
今回は、Ubuntuでインストールしましたので、その他のシステムのJenkinsインストール手順に関して、
https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkinsをご覧ください。

デフォルトでJenkinsはhttp://127.0.0.1:8080で見れます。

3. JenkinsとGitHubを連携
必要となるpluginをインストールします。
「Jenkinsの管理」→「プラグイン管理」で、「利用可能」タブで、「Git Plugin」、「Parameterized trigger Plugin」、「GitHub pull request builder plugin」、「GitHub Plugin」を検索し、インストールしてください。

pluginインストールが完了したらJenkinsを再起動してください。
sudo service jenkins restart
JenkinsとGitHubを連携する際、必要となる鍵を生成しましょう。jenkinsユーザ（Jenkinsインストール時に自動的に作成されるユーザ）の権限で、鍵を生成しなければなりません。
sudo su -l jenkins
ssh-keygen -t rsa -C "jenkins@hogehoge.com"
鍵を生成する際、デフォルトのまま進めてください。
Generating public/private rsa key pair.
Enter file in which to save the key (/var/lib/jenkins/.ssh/id_rsa):
Created directory '/var/lib/jenkins/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /var/lib/jenkins/.ssh/id_rsa.
Your public key has been saved in /var/lib/jenkins/.ssh/id_rsa.pub.
The key fingerprint is:
09:b6:79:a6:b4:9d:5b:d0:ab:36:fb:93:ea:a4:62:7e jenkins@hogehoge.com
生成された鍵、Ubuntuの場合、デフォルトで/var/lib/jenkins/.sshに生成されます。
できた鍵をknown_hostsに追加します。
eval $(ssh-agent)
ssh-add /var/lib/jenkins/.ssh/id_rsa
その後、GitHubの「Settings」→「SSH keys」→「Add SSH Key」を開きます。
Titleに適当な名前を入力して、/var/lib/jenkins/.ssh/id_rsa.pub（生成されたJenkins公開鍵Jenkinsのデフォルト保存場所）の内容をコピーして、Keyに貼り付けます。

GitHubの鍵生成の詳しくは、https://help.github.com/articles/generating-ssh-keysを参照できます。

4. GitHubのリポジトリーを作成
GitHubでtestrepoリポジトリーを作成します。

5. 開発環境の用意
testrepoをローカルの作業フォルダーにcloneします。
mkdir /workdir
cd workdir/
git clone --recursive https://github.com/d-malyshev/testrepo.git 
apacheのconfファイルに作業フォルダーパスを追加<VirtualHost *:80>
    DocumentRoot /workdir/testrepo/public_html
    ServerName work.myserver.com

    ErrorLog "/var/log/apache2/work_server-error_log"
    CustomLog "/var/log/apache2/work_server-access" common
</VirtualHost>
/etc/hostsに開発用のサーバを追加

127.0.0.1 work.myserver.com

6. プロジェクトのソースコードを実装
開発フォルダーのtestrepoの下で、加算・引き算をする簡単なファイルを実装しましょう。
それより、先にGitHubのtest_branchのブランチを作成します。
cd /workdir/testrepo
git checkout -b test_branch
プロジェクトは以下のファイル構造になります。
/public_html
    /index.html -> indexファイル
    /add.html -> 足し算の処理
    /subtract.html -> 引き算の処理
    /js -> JavaScriptフォルダー
        /test -> ここでJavaScript用のUnit Testの.jsファイルを保存します
            /unit_test.js -> 実際のUnit Test
まずは、htmlページを実装します。

index.html
<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Calculation Page</title>
</head>
<body>
    <p>Welcome to calculation site!</p>
    <p><a href="add.html">Addition</a></p>
    <p><a href="subtract.html">Subtraction</a></p>
</body>
</html>
add.html
<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Calculation Page: addition</title>
</head>
<body>
    <script>
    function calculateAdd(a, b)
    {
        var result = a + b;
        return result;
    }
    </script>
    <script>
    var res = calculateAdd(1, 2);
    document.write("1 + 2 = " + res);
    </script>
</body>
</html>
subtract.html
<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Calculation Page: subtraction</title>
</head>
<body>
    <script>
    function calculateSubtract(a, b)
    {
        var result = a - b;
        return result;
    }
    </script>
    <script>
        var res = calculateSubtract(2, 1);
        document.write("2 - 1 = " + res);
    </script>
</body>
</html>
 
今回、テストしたいJavaScriptのロジックはadd.htmlとsubtract.htmlのページに実装していきます。
QUnitでテストできるには、ソースコードに数行を追加しなければいけません。

QUnitのライブラリjsとその表示用のcssをhtmlのheadに追加します。

<link rel="stylesheet" type="text/css" href="//code.jquery.com/qunit/qunit-1.15.0.css">
<script src="//code.jquery.com/qunit/qunit-1.15.0.js"></script>

QUnitのテスト結果が表示されるqunitとqunit-fixtureのidを持っているdivもhtmlのbody追加します。
<div id="qunit"></div>
<div id="qunit-fixture"></div>
そして、QUnitのUnit Testも実装します。
QUnit.test("calculateAdd test", function(assert) {
    var value = calculateAdd(1, 2);
    var expected = 3;
    assert.equal(value, expected, "We expect addition result to be " + expected);
});
すべてを組み合わせると、以下のようになります。
<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Calculation Page: addition</title>
  <link rel="stylesheet" type="text/css" href="//code.jquery.com/qunit/qunit-1.15.0.css">
  <script src="//code.jquery.com/qunit/qunit-1.15.0.js"></script>
</head>
<body>
    <script>
    function calculateAdd(a, b)
    {
        var result = a + b;
        return result;
    }
    </script>
    <script>
        var res = calculateAdd(2, 1);
        document.write("1 + 2 = " + res);
    </script>
　  <script>
　　    QUnit.test("calculateAdd test", function(assert) {
        var value = calculateAdd(1, 2);
        var expected = 3;
        assert.equal(value, expected, "We expect addition result to be " + expected);
    });
    </script>
    <div id="qunit"></div>
    <div id="qunit-fixture"></div>
</body>
</html>
ブラウザで見ると、この感じになります。

jenkins35
CLIでもテストできます。
そのために、phantomjsから、QUnitを実行するrun-qunit.jsを呼び出します。
phantomjs /myprojects/phantomjs/examples/run-qunit.js http://work.myserver.com/add
.html
'waitFor()' finished in 220ms.
Tests completed in 20 milliseconds.
1 assertions of 1 passed, 0 failed.
※ run-qunit.jsのパスはPhantomJSのソースコードの保存先によって変わります。

QUnitテストのソースコードをテスト専用のjs/test/unit_test.jsに移行しましょう。または、各htmlファイルにQUnit用のcssやdiv.qunitとdiv.qunit-fixtureを追記しないように、それを動的に生成するようにしましょう。
さて、unit_test.jsは以下のようになります。
// Test環境のみで必要な結果表示用のdivやcssを追加
var d = document;
var qd = d.createElement('div');
qd.id = "qunit";
d.body.appendChild(qd);

var qfd = d.createElement('div');
qfd.id = "qunit-fixture";
d.body.appendChild(qfd);

//QUnitのstylesheetを追加
var head = d.getElementsByTagName('head')[0];
var css = d.createElement("link")
css.setAttribute("rel", "stylesheet")
css.setAttribute("type", "text/css")
css.setAttribute("href", "//code.jquery.com/qunit/qunit-1.15.0.css");
head.appendChild(css);

// 足し算Testを実行
QUnit.test("calculateAdd test", function(assert) {
    var value = calculateAdd(1, 2);
    var expected = 3;
    assert.equal(value, expected, "We expect addition result to be " + expected);
});
add.htmlも修正します。
<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <title>Calculation Page: addition</title>
    <script src="//code.jquery.com/qunit/qunit-1.15.0.js"></script>
</head>
<body>
    <script>
    function calculateAdd(a, b)
    {
        var result = a + b;
        return result;
    }
    </script>
    <script>
    var res = calculateAdd(1, 2);
    document.write("1 + 2 = " + res);
    </script>
    <script src="js/test/unit_test.js"></script>
</body>
</html>
ただし、subtract.htmlのQUnitのテストjs/test/unit_test.jsを追加すると...
<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <title>Calculation Page: subtraction</title>
    <script src="//code.jquery.com/qunit/qunit-1.15.0.js"></script>
</head>
<body>
    <script>
    function calculateSubtract(a, b)
    {
        var result = a - b;
        return result;
    }
    </script>
    <script>
        var res = calculateSubtract(2, 1);
        document.write("2 - 1 = " + res);
    </script>
    <script src="js/test/unit_test.js"></script>
</body>
</html>
...subtract.htmlのUnit Testは失敗します。
phantomjs /myprojects/phantomjs/examples/run-qunit.js http://work.myserver.com/subtract.html
'waitFor()' finished in 208ms.
Tests completed in 34 milliseconds.
0 assertions of 1 passed, 1 failed. 
失敗の理由は、subtract.htmlでテストしようとしているcalculateAddの関数がないからです。
もちろん、subtract.htmlの関数のみのUnit Testのjsを実装すれば、subtract.htmlのUnit Testは成功します。
しかし、各htmlファイル用のUnit Testのjsを用意するのが非常に面倒です。

そのために、QUnitでModuleという仕組みが設けられ、複数htmlページの関数テストを一つのjsファイルでまとめて、モジュール毎の呼び出しは可能です。

足し算処理のテストと引き算処理のテストをそれぞれ、add_testとsubtract_testに分けます。
// モジュールadd_testを作成(public_html/add.htmlページのJSテスト用)
QUnit.module("add_test");

// 足し算Testを実行
QUnit.test("calculateAdd test", function(assert) {
    var value = calculateAdd(1, 2);
    var expected = 3;
    assert.equal(value, expected, "We expect addition result to be " + expected);
});

// モジュールsubtract_testを作成(public_html/subtract.htmlページのJSテスト用)
QUnit.module("subtract_test");

// 引き算Testを実行
QUnit.test("subtract_test calculateSubtract test", function(assert) {
    var value = calculateSubtract(2, 1);
    var expected = 1;
    assert.equal(value, expected, "We expect subtraction result to be " + expected);
});
できたモジュールをもう一度、呼び出してみます。モジュール毎のUnit Testは、http://yourdomain/filename?module=moduleName形式で呼び出されます。
足し算のテスト
phantomjs /myprojects/phantomjs/examples/run-qunit.js http://work.myserver.com/add.html?module=add_test
'waitFor()' finished in 216ms.
Tests completed in 17 milliseconds.
1 assertions of 1 passed, 0 failed.
引き算のテスト
phantomjs /myprojects/phantomjs/examples/run-qunit.js http://work.myserver.com/subtract.html?module=subtract_test
'waitFor()' finished in 207ms.
Tests completed in 19 milliseconds.
1 assertions of 1 passed, 0 failed.
最後には、unit_test.jsにもう少し手を加えましょう。

実は、その開発環境でも本番環境でもQUnitのJavaScriptは毎回呼ばれるのが困ります。
結局、テスト用のマシンのみQUnitを実行したいわけです。そのため、QUnit.config.autostartの設定項目が存在しています。そもそも、QUnit.config.autostartはtrueになっているから、ページがロードされる度にUnit Testは走ります。
そこで、テスト用のtest.myserver.comでのみ実行できるようにQUnit.config.autostartを工夫します。

QUnit.config.autostart = (window.location.href.indexOf("test.myserver.com") > -1) ? true : false;
 
最終的に、Unit Test用のjs/test/unit_test.jsファイルは下記の形をとります。
// テスト環境のみで実行
QUnit.config.autostart = (window.location.href.indexOf("test.myserver.com") > -1) ? true : false;

// Test環境のみで必要なdivやcssを追加
if (QUnit.config.autostart != false) {
    // 結果表示divを追加
    var d = document;
    var qd = d.createElement('div');
    qd.id = "qunit";
    d.body.appendChild(qd);

    var qfd = d.createElement('div');
    qfd.id = "qunit-fixture";
    d.body.appendChild(qfd);

    //QUnitのstylesheetを追加
    var head = d.getElementsByTagName('head')[0];
    var css = d.createElement("link")
    css.setAttribute("rel", "stylesheet")
    css.setAttribute("type", "text/css")
    css.setAttribute("href", "//code.jquery.com/qunit/qunit-1.15.0.css");
    head.appendChild(css);
}

// モジュールadd_testを作成(public_html/add.htmlページのJSテスト用)
QUnit.module("add_test");

// 足し算Testを実行
QUnit.test("calculateAdd test", function(assert) {
    var value = calculateAdd(1, 2);
    var expected = 3;
    assert.equal(value, expected, "We expect addition result to be " + expected);
});


// モジュールsubtract_testを作成(public_html/subtract.htmlページのJSテスト用)
QUnit.module("subtract_test");

// 引き算Testを実行
QUnit.test("subtract_test calculateSubtract test", function(assert) {
    var value = calculateSubtract(2, 1);
    var expected = 1;
    assert.equal(value, expected, "We expect subtraction result to be " + expected);
});
できたソースコードをGitHubのtest_branchにpushしましょう。
git add .
git commit -m "Initial commit"
git push origin test_branch
7. Jenkinsのjobを作成
こちらで、ソースコードをbuild/test/deployするjobを作成します。

status_update_job: build状態をGitHubに知らせるjobを作成

プロジェクトをビルドするjobはそれを参照するので、先に作ります。

「新規ジョブ作成」で
「フリースタイル・プロジェクトのビルド」にチェック
「プロジェクト名」→ status_update_job
「OK」で作成画面に入ります。

ジョブ作成画面で
「ビルドのパラメータ化」にチェック
「ビルドのパラメータ化」→「パラメータの追加」→「文字列」で３つのパラメータを作成し、それぞれの「名前」にCOMMIT_STATUS、UPDATE_COMMIT、REPOSITORY_NAMEを入力
「ソースコード管理」→「なし」にチェック
「ビルド」→「シェル実行」を選択します。
「ビルド」→「シェルスクリプト」にビルドされたcommitの状態(successまたは、failure)をGitHubに通知する処理
curl -i -H 'Authorization: token abcdef0123456789abcdef012345fc2b6142d8a7' \
    -d '{"state": "'${COMMIT_STATUS}'"}' \
    https://api.github.com/repos/${REPOSITORY_NAME}/statuses/${UPDATE_COMMIT}
tokenはOAuth用に生成してください。

GitHubの「Settings」→「Applications」→「Generate new token」でOAuthトークンを生成し、その文字列をどこかで保存してください。トークンを作成する際、repoにチェックが入っていることを、確認してください。

build_job: プロジェクトをビルドするjobを作成

「新規ジョブ作成」で
「フリースタイル・プロジェクトのビルド」にチェック
「プロジェクト名」→ build_job
「OK」で作成画面に入ります。

ジョブ作成画面で
「ソースコード管理」→「Git」にチェック
「Repositories」→「Repository URL」にgit@github.com:{githubのアカウント}/{あなたのリポジトリ―}（私の場合、git@github.com:d-malyshev/testrepo.gitです）
「Repositories」→「Credentials」で「なし」を選択
「Branches to build」に２つのbranchを「Add Branch」で追加してください。それぞれの「Branch Specifier」に「*/master」と「*/release」を入力してください。
「Additional Behaviors」で「Strategy for choosing what to build」を選択し、その中から「Inverse」にしてください。
「ビルド・トリガー」→「SCMをポーリング」にチェック
「ビルド・トリガー」→「スケジュール」に常に起動するように設定
 
* * * * *

「ビルド」→「シェル実行」を選択します。
「ビルド」→「シェルスクリプト」にPhantomJS+QUnitのモジュールテストを指定します
phantomjs /myprojects/phantomjs/examples/run-qunit.js http://test.myserver.com/add.html?module=add_test
phantomjs /myprojects/phantomjs/examples/run-qunit.js http://test.myserver.com/subtract.html?module=subtract_test
「ビルド後の処理」→「Trigger parametrized build on other projects」を選択
「Add trigger」で２つのBuild Triggersを追加
その二つは、以下のようになります

1番目
「Projects to build」→ status_update_job
「Trigger when build is」→「Stable or unstable but not failed」を選択
「Predefined parameters」に
COMMIT_STATUS=success
UPDATE_COMMIT=${GIT_COMMIT}
REPOSITORY_NAME=あなたのアカウント/あなたのリポジトリ―(私の場合、d-malyshev/testrepo)
2番目
「Projects to build」→ status_update_job
「Trigger when build is」→「Failed」を選択
「Predefined parameters」に
COMMIT_STATUS=failure
UPDATE_COMMIT=${GIT_COMMIT}
REPOSITORY_NAME=あなたのアカウント/あなたのリポジトリ―(私の場合、d-malyshev/testrepo)

mergeされたリポジトリ―を本番サーバにdeployするjobを作成

「新規ジョブ作成」で
「フリースタイル・プロジェクトのビルド」にチェック
「プロジェクト名」→ deploy_job
「OK」で作成画面に入ります。

ジョブ作成画面で
「ソースコード管理」→「なし」にチェック
「ビルド・トリガー」→「定期的に実行」にチェック
「ビルド・トリガー」→「スケジュール」に常に起動するように設定。5分毎にmergeされたプロジェクトを確認したい場合、以下のように記述
*/5 * * * *
「ビルド」→「シェル実行」を選択します。本番サーバに最新のソースコードをpullします
if [ -d /myserver/testrepo ]; then
    cd /myserver/testrepo
    git pull origin master
else
    cd /myserver
    git clone --recursive https://github.com/d-malyshev/testrepo.git
fi

8. 本番環境の用意
GitHubでbranchがmasterにmergeされた後、本番環境にソースコードをdeployします。
今回、開発環境や本番環境は同じマシンになっていますので、本番環境は別のマシンになる場合、rsyncなどをご利用ください。
/myserverフォルダーを作成してください。
apacheのconfファイルに作業フォルダーパスを追加
<VirtualHost *:80>
    DocumentRoot /myserver/testrepo/public_html
    ServerName prod.myserver.com

    ErrorLog "/var/log/apache2/prod_server-error_log"
    CustomLog "/var/log/apache2/prod_server-access" common
</VirtualHost>
/etc/hostsに開発用のサーバを追加
 
127.0.0.1 prod.myserver.com 

9. Jenkinsでのテスト環境の用意
PhantomJSはQUnitをテスト用のサーバで実行するので、先ほど作成されたJenkinsのbuild_jobはtest.myserver.comテストサーバのDocumentRootになるように、apacheのconfファイルに下記を追記します。
<VirtualHost *:80>
    DocumentRoot "/var/lib/jenkins/jobs/build_job/workspace/public_html"
    ServerName test.myserver.com

    ErrorLog "/var/log/apache2/test_server-error_log"
    CustomLog "/var/log/apache2/test_server-access" common
</VirtualHost>
/etc/hostsにも開発用のサーバを追加
 
127.0.0.1 test.myserver.com


10. PhantomJS+QUnit+Jenkinsの実践
これで、やっと開発・テスト・本番環境が揃いました。

本番環境にはまだ何もdeployされていないので、本番サーバはこの感じです。

とりあえず、add.htmlを修正し、bugを仕込みましょう。

bugを入れる前
function calculateAdd(a, b)
{
    var result = a + b;
    return result;
}
bugを入れた後
function calculateAdd(a, b)
{
    var result = a + b;
    // Unit Testを通らないようにbug
    return result+1;
}
そして、そのソースコードを、先作成してきたtest_branchに pushします。
git add .
git commit -m "Created bug"
git push origin test_branch
GitHubでtest_branchのPull Requestを作成してみます。
それをやってみると、最近の当ブランチにpushされたcommitのbuild_jobが失敗したことが分かります。

jenkins16

ブランチをクリックすると、ビルドが失敗したcommitを見れます。

jenkins17

Jenkinsのjob一覧画面を見ると、build_jobの#8が失敗したことが分かります。
そのbuild_jobをクリックし、job結果一覧画面に移動します。

jenkins22

失敗した#8の詳細ページに行って、Console Outputでbuildの失敗した原因を調べることもできます。
 
jenkins23
jenkins21

build_jobの次に、status_update_jobが起動し、GitHubでcommitの状態をfailureに設定しました。

jenkins39


では、仕込んできたbugを修正し、またtest_branchにpushしましょう。

bugを修正した後
function calculateAdd(a, b)
{
    var result = a + b;
    return result;
}
そして、test_branchにpushします。
git add .
git commit -m "Fixed bug"
git push origin test_branch
今度、build_jobは成功し、GitHub上の結果はこのとおりとなります。

jenkins19

test_branchを「Merge pull request」→「Confirm merge」でmasterにmergeし、最後に「Delete branch」でtest_branchを削除します。その後、deploy_jobは起動し、masterから最新版のソースコードを本番サーバにpullします。
 
そして、先ほど設定した本番サーバのhttp://prod.myserver.comにアクセスし、ソースコードは問題なく表示されていることをご確認ください。

まとめ
「使いやすさと良き見映えは成功の８割」と言われるWeb画面ですが、
そのJavaScriptのバグは、ユーザーエクスペリエンスを低下させ、お客様からの多くのクレームの原因にもなります。 
そこで、QUnit+PhantomJS+Jenkinsを利用したら、Front側JSの品質向上に充分貢献できるかと思います。
 


タグ ：
#TDD
#jenkins
#github
#PhantomJS
#QUnit
2013年11月12日16:19
カテゴリ
programming

プライベートメソッドのテストは必要ない！！

こんにちは、RPAの関口です。

最近週に一度、来年の新卒達と一緒にTDDをやりながらワイワイガヤガヤしております。そのなかで「プライベートメソッドのテストはどうすれば良いのか？」 という話題がありました。プライベートメソッドのテストについては
プライベートメソッドのユニットテストは書かないもの？
がよくまとまっていると思います。プライベートメソッドのテスト方法について考える中で「TDDの手順に従えばプライベートメソッドのテストがしたくなることは無い」のではないか？と思うようになりました。

プライベートメソッドはリファクタリングの結果現れる！

数値の配列を渡すと平均を計算して返してくれる機能を持ったクラス、AverageCalculatorを作りたいとします。平均計算の手順をまとめると以下のようになります。
  1. 配列の合計値を計算する
  2. 合計値を配列の要素数で割って返す
ここで「よし！まずは配列の合計値を計算する機能をつけよう！」と思って次のようなテストを書くと

calcSumメソッドの可視性について
  • 途中計算でしか使わない合計値の計算は、プライベートメソッドにしたい
  • でもプライベートメソッドだとテストのためにReflectionを使う必要があって面倒
という悩みが発生してしまいます。最初「平均値を返すメソッドを追加」しようと思っていたのに「合計値を返すメソッドを追加」しようとしたためです。平均値計算の手順はあくまで手順、初心に帰って平均値を返すテストを書きましょう。
そして合計値計算のメソッドは分離したいなぁと思ってリファクタリングする際に、calcSumという名のプライベートメソッドが自然と現れます。 このプライベートなcalcSumメソッドのためにテストを追加する必要はありません。中身がどのような実装になっていようと外部から呼び出されるcalcAverageメソッドが期待通りの結果を返してくれれば良いのです。またcalcSumメソッドはパブリックなcalcAverageメソッドを通じてテストされている、とも言えます。
 
パブリックメソッド経由でテストする
多くの場合、そのクラスのパブリックメソッド経由でプライベートメソッドのテストも同時に行えます。テストできているか不安があるならカバレッジを測定しましょう。

もしcalcSumの代わりに大変複雑な処理だった時はどうするの？

そのような場合、いきなりcalcAverage相当のメソッドを作るの事は難しいでしょう。一旦calcSumのメソッドの追加を行う必要が出てくるかと思います。もちろんテスト付きで。 でもそのcalcSumはAverageCalculatorクラスがやるべき事なのでしょうか？実はSumCalculatorという名の新しいクラスを作って、その中にパブリックメソッドとして書くのが正しいのではないでしょうか？
別クラスのパブリックメソッドとする
プライベートなメソッドのテストを書きたいということは、実はテスト対象の責務が多すぎることを示唆している場合があります。テストがどうしても書きたい場合は、その責務はテスト対象のプライベートな振る舞いでは無く、誰かのパブリックな振る舞いなのでしょう。テスト対象のプライベートメソッドを「クラスの抽出」や「メソッドの移動」を使って、テスト対象のコラボレータのパブリックメソッドとして抽出し、普通にパブリックメソッドとしてテストしましょう。

他の方法

ここまで書いておいてなんですが
  1. calcSumのテストと実装をパブリックで書く
  2. calcAverageのテストと実装をパブリックで書く
  3. リファクタリングでcalcSumメソッドの可視性をプライベートにして、calcSumのテストは削除
という手もあるかと思います。というかこちらのほうが自然ですね。せっかく書いたテストを捨ててしまうのは勿体無い気がしますが、実装中に書いたテストと最後に残すテストを同じにしなければならないというルールはありません。calcSumはcalcAverageを通してテストされているので良しとしましょう。

そんなこんなでプライベートメソッドのテストは必要ない！！・・・のではないかと最近思い始めました。
タグ ：
#TDD
#testing
2011年10月07日14:43
カテゴリ
勉強会

TDDワークショップを開催しました

株式会社adingo所属かつアジャイル戦略室（勝手メンバー）の@katzchangです。先日、VOYAGE GROUP社内勉強会としてTDDワークショップを開催してみましたので、そのご報告です。

まずは「TDDってなに？」っていうお話をさせていただいたあと、ペアプロでTDDを体験して、最後にどんなコードができたかレビューするという、いわゆるTDD Boot Campスタイルをとりました。課題は「ECナビ会員のグレード（http://ecnavi.jp/mypage/guide/condition/）を判定しよう」。

TDD workshop at AJITO, VOYAGE GROUP
View more presentations from katzchang
TDDWSの様子 ペアプロの様子

ふりかえり

Keep

  • ペアプロがよかった、安心できてかつ慎重になる（というのが6票）
  • ECナビネタの課題がFizzBuzzよりも実務に近く感じて勉強になった
  • 進み具合に応じて追加の課題がでてくることがすごくよい
  • 課題の要求があいまいだったので思考できてよかった
  • 数人が教える側に立った
  • テストの価値説明が最初にあるので理解しやすい
  • テストコードは書いた方がいい

Problem

  • OSSだとテストコードがなければ無視されるような話を是非
  • 言語はもっとバラエティに富んでた方がよい
  • 全員ペアプロだったので、ペアプロじゃない人と比較したかった
  • （PHPで）Shift_JISでは日本語メソッドは構文エラーになる
  • パソコンは一人一台あるとよい
  • もう少し時間が長くてもよい
  • 仕様が不明な時に、もっと積極的に出題者に質問できればよかった
  • （コードレビューのとき）ThinkPadがプロジェクターに映らなかった
  • Eclipseよくわからなかった
  • お腹すいた

Try

  • パラメタライズド・テストでテストを書いてみたい
  • ペアプロ大会したい
  • 今日参加できなかったエンジニアのためにまた開催してほしい
  • ピザでも食べながらコードレビュー

これを受けて

ペアプロがとても好評だったのは、想定通りでした(ﾄﾞﾔｯ

ペアプロとTDDの相性の良さについては、書籍「ペアプログラミング」（ピアソン・エデュケーション）の中でも触れられています（私の席に置いているので、読みたい方は声をかけてみてください）。

テスト駆動開発を活用してください。（中略）

テストファーストプログラミングと組み合わせると、ペアプログラミングの価値が本当にわかると言った人たちがいます。その人たちは、最初にテストを作成することで、ペアが2人とも、取り組んでいる問題を正確に把握すると述べています。

ペアプログラミング 第11章 ペアプログラミング実践の秘訣 p101

TDDを使わずに作業の結果を確認するためには、ドライバーは黒目を動かして広大なブラウザ画面のどこかの文字列を網膜に写し、それがドライバーの脳内にある意図に沿っているかを検査することなります。当然、横で見ているパートナーには伝わるはずがありません。ドライバーが「ここがゴールド会員だから、このメニューがこうなって…」みたいな独り言を言いながら進めるのはとても良いことですが、なかなか限界があるでしょう。目標（テストコード）を明確にして実装を進めるTDDは、ペア同士のコミュニケーションも促進するということだと思います。

これからのこと

現在、VOYAGE GROUPエンジニアのためのTDD Boot Campを企画中です。社内向けの研修ではあるのですが、外部の方にも参加していただけるような形で開催したいと私個人としては思っていて、おそらく、そのようにできると信じています。

時期は年明けくらい、12月くらいには何かお知らせできればば、順調に進んでると安心していただけるはずです。とりあえずあと2回程度ワークショップを開催してみて、そこから先の「使える武器」をどう増やしていくにフォーカスするという方向もアリかもしれないと思いながら、まーどうしましょうかねぇ。

現状、プロダクトによってはレガシーコードとの熾烈な戦いがあったり、自分も含めてまだまだ経験が足りていない――言い方を変えれば、挑戦すべき多くのことが目の前に転がっています。これはとても恥ずかしい話ではありますが、ただ、それらを一つ一つ片付けながら進むという、泥臭く、かつ人間臭い仕事ができるエンジニアは、プロフェッショナルと呼ばれるにふさわしいのではないかと思うわけです。

というわけで、最速最強の開発を目指して、今の開発を加速していきましょう。

タグ ：
#TDD
記事検索
最新記事
Blog移行のお知らせ
MySQL InnoDBのinsertとlockの話
様々な角度からデータ分析ができるTableau
Redshiftの操作権限の設定とその方法
BigQueryで使えるクエリをまとめてみた
今、クライアントサイドのJavaScriptを書く前に知っておきたいこと ~ 2014年トレンド総まとめ
知らなきゃ損するVOYAGE GROUPエンジニアが薦めるブログ、ウェブサイト
M1・THE MANZAIの結果で学ぶawk入門
2014年 個人的ハイライト
海外ニュースサイトで振り返る2014年
タグクラウド
QRコード
QRコード