前回から時間が経ってしまいましたが、今回は「性能検証編」ということで、パーティションドテーブルに対して実際にデータを挿入・参照することでパーティショニングの性能面を検証してみようと思います。

性能検証環境

使用したマシンのスペックは以下の通りです。

OS

CentOS 5.3 32bit (on Windows XP Pro SP3 32bit via VMware Server 2.0.0)

CPU

Core2 Duo E8300 2.83GHz (VMには1CPUを割り当て)

Memory

3.25GB (VMには512MBを割り当て)

MySQL のバージョンおよび設定は以下の通りです。なお、MySQL サーバおよびクライアントは同一マシン上で動作させました。

MySQL

5.1.35-community (設定は my-medium.cnf をそのまま使用)

また、パーティションドテーブルのスキーマは以下の通りです。

CREATE TABLE logs (
    id INT NOT NULL AUTO_INCREMENT,
    client_name VARCHAR(255) NOT NULL,
    log_data VARCHAR(1024) NOT NULL,
    logged_at DATETIME NOT NULL,
    PRIMARY KEY(id, logged_at),
    INDEX(client_name)
) ENGINE=MyISAM
PARTITION BY RANGE( TO_DAYS(logged_at) ) (
    PARTITION p200901 VALUES LESS THAN ( TO_DAYS('2009-02-01') ),
    PARTITION p200902 VALUES LESS THAN ( TO_DAYS('2009-03-01') ),
    PARTITION p200903 VALUES LESS THAN ( TO_DAYS('2009-04-01') ),
    PARTITION p200904 VALUES LESS THAN ( TO_DAYS('2009-05-01') ),
    PARTITION p200905 VALUES LESS THAN ( TO_DAYS('2009-06-01') ),
    PARTITION p200906 VALUES LESS THAN ( TO_DAYS('2009-07-01') ),
    PARTITION p200907 VALUES LESS THAN ( TO_DAYS('2009-08-01') ),
    PARTITION p200908 VALUES LESS THAN ( TO_DAYS('2009-09-01') ),
    PARTITION p200909 VALUES LESS THAN ( TO_DAYS('2009-10-01') ),
    PARTITION p200910 VALUES LESS THAN ( TO_DAYS('2009-11-01') ),
    PARTITION p200911 VALUES LESS THAN ( TO_DAYS('2009-12-01') ),
    PARTITION p200912 VALUES LESS THAN ( TO_DAYS('2010-01-01') ),
    PARTITION pmax VALUES LESS THAN MAXVALUE
);

データ挿入の性能検証

検証内容

データ挿入の性能検証には下記 INSERT 文を1万回連続で発行し、それに要した時間を測定しました。INSERT 文の「?」の部分には ‘client_1′ ～ ‘client_1000′ がそれぞれ10回ずつ入ります。（実際には上記の処理を行なう Ruby スクリプトを作成し、その実行時間を time コマンドで測定しました）

INSERT INTO logs (client_name, log_data, logged_at) \
VALUES (?, 'test log data', '2009-11-01');

logs テーブルの事前条件として、以下の2パターンで測定しました。

条件1

1件もレコードが格納されていない状態

条件2

1～10月の各月に1000クライアント×1000件分のログデータ（計1000万件）が格納されている状態

• logged_at : 10通り (’2009-01-01′ ～ ‘2009-10-01′)
• client_name : 1000通り (’client_1′ ～ ‘client_1000′)
• 上記組み合わせをそれぞれ1000件ずつ

検証結果

結果は図1のようになりました。

図1 : データ挿入の性能検証結果 (MyISAM)

条件1を見ると、パーティションあり／なしで処理時間が殆ど変わっていません。これはデータ挿入時にパーティション振り分け処理のオーバーヘッドが殆どないことを示しています。今回振り分け処理に用いたパーティショニング表現は TO_DAYS(logged_at) であり、この程度の処理ではパーティション振り分けのオーバーヘッドを全く気にしなくてよいことが分かります。

逆に言えば、パーティショニング表現に時間のかかる処理を用いてしまうとそこがボトルネックになってしまいます。それが気になる場合は、以下のように BENCHMARK() 関数を用いて事前にパーティショニング表現の処理時間を確認しておくとよいと思います。

mysql> SELECT BENCHMARK(10000, TO_DAYS('20091101') );
+---------------------------------------+
| benchmark(10000, TO_DAYS('20091101')) |
+---------------------------------------+
|                                     0 |
+---------------------------------------+
1 row in set (0.00 sec)

また条件1、2での処理時間を比較すると、パーティションなしの場合は処理時間が増加しているのに対し、パーティションありの場合は処理時間が殆ど変わっていないことが分かります。これはインデックスデータがパーティション毎に独立して作成されることを示しています。今回のスキーマで作成されるインデックスは (id, logged_at) の複合インデックスと client_name ですが、このうち client_name はユニークなカラムではありません。そのため、事前に格納されているレコード数が多いほどインデックスデータ（BTREE 構造）の更新処理に時間がかかり、故にデータ挿入処理も遅くなります。

パーティションなしの場合に事前に0件と1000万件格納されている場合とで挿入時間に差が出ているのはそのためです。しかし、パーティションありの場合、条件2において p200911 （以降）には1件もレコードが格納されていない状態であるため、logged_at が ‘2009-11-01′ （以降）のデータを挿入する場合はテーブルが空の場合と同じ処理時間になるのです。つまり、ログ情報のような日毎に蓄積されるデータを格納する場合、月別にパーティションを設定しておくことで、レコード数増加に伴い累積的に遅くなるデータ挿入処理の影響を一ヶ月分に抑えられることが分かります。

なお、ストレージエンジンを InnoDB にして同じ検証を行なってみましたが、MyISAM の場合と同様の結果になりました。（図2）

図2 : データ挿入の性能検証結果 (InnoDB)

データ参照の性能検証

検証内容

データ参照の性能検証には、MySQL クライアントから下記2パターンの SELECT 文を1回発行し、それに要した時間を測定しました。

条件1

client_name 指定なしで11月分のログデータ参照する

SELECT * FROM logs WHERE logged_at >= '2009-11-01' \
AND logged_at < '2009-12-01';

条件2

client_name 指定ありで11月分のログデータ参照する

SELECT * FROM logs WHERE logged_at >= '2009-11-01' \
AND logged_at < '2009-12-01' AND client_name = 'client_1';

logs テーブルの事前条件は、データ挿入の性能検証（条件2）を行なったときの状態としました。つまり、1～10月の各月に1000クライアント×1000件分のログデータが、11月に1000クライアント×10件分のログデータが格納されている状態（計1001万件）です。

検証結果

結果は図3のようになりました。

図3 : データ参照の性能検証結果 (MyISAM)

条件1を見ると、パーティションありの方が処理時間が劇的に速いことが分かります。これはパーティションなしでは全レコード（1001万件）を参照しているのに対し、パーティションありでは p200911 のレコード（1万件）のみを参照しているためです。これはオプティマイザが SELECT 文中のクエリ logged_at >= ‘2009-11-01′ AND logged_at < ‘2009-12-01′ から判断した結果です。理論的には検索件数が1001万から1万に減るので処理時間も1/1000になって欲しいところですが、そうなっていないのはオプティマイザの判断処理等によるオーバーヘッドの影響かもしれません。

なお、SELECT 文の前に EXPLAIN PARTITIONS を付けることで、参照時にアクセスするパーティションを調べることができます。（これを見るとなぜか p200912 にもアクセスしていることが分かります。なぜそうなるのかは分かりませんが…）

mysql> EXPLAIN PARTITIONS SELECT * FROM logs
    -> WHERE logged_at >= '2009-11-01'
    -> AND logged_at < '2009-12-01'\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: logs
   partitions: p200911,p200912
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 10010000
        Extra: Using where

また、条件2を見ると、インデックス併用時にもパーティションありの方が処理時間が劇的に速いことが分かります。この場合、まずオプティマイザが参照に必要なパーティションを判断し、そこからさらに該当するパーティションのインデックス情報を使って参照するデータ数を絞り込んでいるようです。ここまでいくと、データ参照のコストがほぼゼロになりました。

なお、ストレージエンジンを InnoDB にして同じ検証を行なってみましたが、こちらも MyISAM の場合と同様の結果になりました。（図4）

図4 : データ参照の性能検証結果 (InnoDB)

まとめ

本エントリでは、パーティションドテーブルに対して実際にデータを挿入・参照することでパーティショニングの性能面を検証しました。その結果、今回検証した条件ではデータ挿入・参照のいずれにおいてもパーティショニングしない場合に比べて性能が向上することが分かりました。

このように、パーティショニングは上手に利用すればいいことずくめとなる機能です。本エントリがパーティショニング活用に役立てれば幸いです。

本エントリではデータベースに関する技術トピックとして、MySQL 5.1 から導入された機能であるパーティショニングについて書こうと思います。少し長くなりそうなので、「基本知識編」「性能検証編」の2回に分けて書くことにします。

今回は「基本知識編」として、パーティショニングの概要と基本的な使い方について紹介します。

パーティショニングの概要

パーティショニングとは、事前に設定されたルールに従ってデータをパーティションと呼ばれる部分的なテーブルに分割する仕組みです。

データ挿入時には、設定ルールに従ってデータが該当するパーティションに自動的に振り分けられます。データ参照時には、オプティマイザがクエリから必要なパーティションを判断し、該当するパーティションのみにアクセスします。これらは MySQL の内部で行なわれるため、データの操作においてパーティショニングを意識する必要はありません。

パーティショニングを利用することで、以下の利点が得られます。

• 大量のデータを処理することによる性能上のボトルネックの発生を抑えられる
• テーブルサイズに上限がある場合（MyISAMなど）でも、その上限を超える量のデータを格納できる

パーティションドテーブルの作成

それでは実際にパーティションドテーブル（パーティショニングされたテーブル）を作成してみます。パーティショニングにはいくつかの種類がありますが、ここでは RANGE パーティショニングについて説明します。

パーティションドテーブルの作成は簡単で、通常のテーブル作成文の後にパーティション設定ルールの記述を追加するだけです。以下の例は、複数クライアントのログ情報を月別に分けて格納するパーティションドテーブルの作成例です。

CREATE TABLE logs (
    id INT NOT NULL AUTO_INCREMENT,
    client_name VARCHAR(32) NOT NULL,
    log_data VARCHAR(1024) NOT NULL,
    logged_at DATETIME NOT NULL,
    PRIMARY KEY(id, logged_at),
    INDEX(client_name)
) ENGINE=MyISAM
PARTITION BY RANGE( TO_DAYS(logged_at) ) (
    PARTITION p200910 VALUES LESS THAN ( TO_DAYS('2009-11-01') ),
    PARTITION p200911 VALUES LESS THAN ( TO_DAYS('2009-12-01') ),
    PARTITION p200912 VALUES LESS THAN ( TO_DAYS('2010-01-01') ),
    PARTITION pmax VALUES LESS THAN MAXVALUE
);

PARTITION BY RANGE 以下がパーティション設定ルールです。上記の例では p200910、p200911、p200912、pmax という名前の4つのパーティションが作成され、TO_DAYS(logged_at) の値を基にデータが各パーティションに振り分けられる設定になっています。例えば、logged_at が ‘2009-11-01′ より小さいデータは p200910 に格納されるといった具合です。ここで、振り分けに利用される表現（上記例では TO_DAYS(logged_at) ）を「パーティショニング表現」と呼びます。

パーティション設定ルールの最後の行の “VALUES LESS THAN MAXVALUE” は「キャッチオール」節と呼ばれるものです。MAXVALUE は表現可能な最大整数値を表すので、logged_at が ‘2010-01-01′ 以上となるデータは全て pmax に格納されます。これが無いと、logged_at が ‘2010-01-01′ 以上となるデータを格納する場合にエラーが起こります。

なお、パーティションドテーブルの作成に際してはいくつかの制約があります。以下に代表的なものを挙げておきます。

• パーティショニング表現に用いられるカラムはテーブル内に存在するプライマリキー（またはユニークキー）の一部でなければならない
  • プライマリキー（またはユニークキー）が存在しない場合は例外
• パーティション表現は連続した整数値をとるものでなければならない
  • 日付データを利用する場合、TO_DAYS() 関数などを使って整数値に直す必要がある
• 作成できるパーティションの上限は1テーブルにつき1024個

パーティションの追加

既存のパーティションドテーブルから更にパーティションを追加する方法は2つあります。

• ADD PARTITION を使って新規パーティションを追加する方法
• REORGANIZE PARTITION を使って既存のパーティションを再分割する方法

ただし、既存のパーティションドテーブルに「キャッチオール」節が存在する場合は後者の方法しか選択肢がありません。

以下にそれぞれの方法について説明します。

ADD PARTITION を使う方法

既存のパーティションドテーブルにパーティションを新規追加するには以下のようにします。

ALTER TABLE logs ADD PARTITION (
    PARTITION p201001 VALUES LESS THAN ( TO_DAYS('2010-02-01') )
);

注意点として、RANGE パーティショニングされているテーブルにおいて、ADD PARTITION は既存パーティションの「後」にしかパーティション追加ができません（「前」や「間」はNGです）。そのため、「キャッチオール」節（MAXVALUE）が既に存在する場合は（MAXVALUE より後の値は存在し得ないため）、この方法が使えません。

REORGANIZE PARTITION を使う方法

既存のパーティションを再分割するには以下のようにします。この例では、pmax を p201001 と、（新しい） pmax に再分割しています。

ALTER TABLE logs REORGANIZE PARTITION pmax INTO (
    PARTITION p201001 VALUES LESS THAN ( TO_DAYS('2010-02-01') ),
    PARTITION pmax VALUES LESS THAN MAXVALUE
);

REORGANIZE PARTITION を行なうと、既存のデータが再分割後のパーティションに適切に振り分けられます。例えば上記の例では、旧 pmax に格納されていたデータのうち logged_at が ‘2009-02-01′ より小さいものは p201001 に、’2009-02-01′ 以上のものは 新 pmax に格納されます。この再振り分け処理により、既存データが大量にある場合は REORGANIZE PARTITION の実行にそれなりの時間がかかります。

REORGANIZE PARTITION は、既存パーティションの結合にも利用できます。例えば、p200910 と p200911 を結合したい場合は以下のようにします。

ALTER TABLE logs REORGANIZE PARTITION p200910, p200911 INTO (
    PARTITION p200910_11 VALUES LESS THAN ( TO_DAYS('2009-12-01') )
);

さらに、既存の複数パーティションを新しい複数パーティションに再構成することもできます。

ALTER TABLE logs REORGANIZE PARTITION p200910, p200911, p200911, pmax INTO (
    PARTITION p200909_10 VALUES LESS THAN ( TO_DAYS('2009-11-01') ),
    PARTITION p200911_12 VALUES LESS THAN ( TO_DAYS('2010-01-01') ),
    PARTITION pmax VALUES LESS THAN MAXVALUE
);

パーティションの削除

パーティションドテーブルから特定のパーティションを削除するには、以下のようにしてパーティションごと DROP します。

ALTER TABLE logs DROP PARTITION p200912;

上記の例では、パーティション p200912 および p200912 に格納されているデータが全て削除されます。また、上記例の実行前に p200910、p200911、p200912、pmax のパーティションがあった場合、p200912 が削除されたことで logged_at が ‘2009-12-01′ 以上となるデータは全て pmax に格納されるようになります。

パーティションの削除は内部的にテーブルの DROP とほぼ同じであるため、（ストレージエンジンが MyISAM や InnoDB の場合であれば）格納されているデータ件数によらず一瞬で処理が完了します。

パーティショニングの解除

パーティションドテーブルからパーティションを取り除き、通常のテーブルにするには以下のようにします。

ALTER TABLE logs REMOVE PARTITIONING;

DROP PARTITION とは異なり、各パーティションに格納されているデータは削除されません。各パーティションのデータを一つのテーブルにマージするため、既存データが大量にある場合は REMOVE PARTITIONING の実行にそれなりの時間がかかります。

まとめ

本エントリでは、MySQL 5.1 から導入された機能であるパーティショニングについて概要を説明し、RANGE パーティショニングによるパーティションドテーブルの作成、パーティションの追加・削除、パーティショニングの解除方法について具体例を交えて説明しました。RANGE パーティショニング以外のパーティショニング方法などパーティショニングについてより深く知りたい方は、MySQL 5.1 リファレンスマニュアル :: 15 パーティショニング を一読されると良いと思います。

次回のエントリでは、パーティションドテーブルに対して実際にデータを挿入・参照することでパーティショニングの性能面を検証してみようと思います。お楽しみに！

Android携帯

国内初のAndroid搭載端末HT-03Aが2009年7月にNTT docomoから発売されました。皆様ご存知でしょうか？

海外でもMotorola CLIQ、HTC Hero、LG-GW62等の端末が続々とリリースされていて、最近ではDellもAndroid搭載のスマートフォンを発売すると報道されています。Android端末が世界中で増えつつありますね。

実は私もHT-03Aの購入者の一人なのですが、携帯電話の変更連絡を友人や家族にしたときに、多くの人から「何それ？」と言われてしまいました。いやいや、これは今までに無い素晴らしい携帯電話なんです。

今回は、私が感じたAndroid携帯の魅力を3つに絞って皆様にお伝えできればと思います。

魅力1　携帯電話もリアルタイムの世界へ

まずAndroid携帯を使っていて驚かされる事はデータの同期および通知がリアルタイムであるということです。

一つ目のデータの同期とはGmail、アドレス帳、Google Calendar等のアプリケーションのローカルデータとGoogleのクラウド上にあるデータがリアルタイムに同期するということです。

今までの同期といえば、デバイスとPCをUSBでつないで・・・、という面倒な作業が頭をよぎりますが、何もしなくてもインターネット経由で勝手に同期してくれます。例えば、携帯電話で作成しているメールの内容をリアルタイムにPCで確認することができます。これなら携帯電話で作成した文書を途中からPCで編集！ってことも簡単です。他にもPCでアドレス帳を編集したり顔写真を追加したりしていると、気がついたときには携帯電話にデータ・画像が反映されています。データの同期がリアルタイムであるというメリットはおわかりいただけたでしょうか。

二つ目のデータの通知というのは、Gmail、GTalk、Twitter等の複数のアプリケーションからリアルタイムにデータが通知されるということです。

これはAndroidの特徴でもある「マルチタスク」が威力を発揮しています。例えば、Gmailでメールを作成しているときに、GTalkからのメッセージ受信通知、Twitterの発言通知、アプリケーションのアップデート通知等々、ありとあらゆる情報がどんどん通知されてきて、それが容易にタスクバーで把握可能です。

今までの携帯電話では考えられない世界だと思いませんか？Googleはリアルタイムな通信基盤を構築しようとしています。Androidはその一部です。この周辺技術を理解していくとリアルタイム通信というのが重要であることがわかるので、関連するChrome OSやGoogle Waveも紹介したいところですが、紙面の都合で次回以降に回します。

魅力2　オープンな携帯電話

次の魅力はAndroidがオープンソース、ロイヤリティーフリーであるということです。

Androidは携帯電話のためのものだけではありません。Androidはフルスタックソフトウェアであり、OS、ミドルウェア、アプリケーションフレームワークをモバイル機器（組み込み機器）向けに提供しているのです。メーカーは携帯電話をはじめとするモバイル機器を開発し、その上で動くアプリケーションを3rdパーティーが開発することが可能になるというわけです。

携帯電話だけでなく、情報家電、車載機器、セットトップボックス等がAndroidへの新しいプラットフォームへ移行することで、OSのロイヤリティがかからない上に機器による開発環境の違いも吸収できることになります。エミュレーターも充実しているので開発コストも低く抑えられることでしょう。そして言語はJava。私はJavaが好きなのでかなり魅力を感じています（笑）。

「How Android works: The big picture」の記事のAndroidのシステムアーキテクチャを見てみると、Web開発者であればご存知の「WebKit」や「SQLite」を初めとするライブラリとアプリケーションフレームワークがありとても魅力的です。携帯電話の開発といえばDoja、MIDP、starプロファイルが頭をよぎるのですが、自由度や機能面でいうと全然違います。「All application are created equal」というように、電話帳アプリケーションだって置きかえられるくらいの高い自由度を備えてます。もちろんユーザインタフェースはiPhoneにはまだまだ及びませんが、洗練されたUIを作る事も可能でしょう。

これはAndroidプラットフォームの魅力のほんの一部です。これからどんどん新しい端末がローコストで出てくるのが楽しみですね。

魅力3　強力なアプリケーション

AndroLib.comの統計によると2009年10月1日現在、約1万2000本のアプリケーションが登録されています。統計を見ると面白いですね。毎日約50もの新しいアプリケーションが生まれています。

そして、未完成の携帯電話をどんどん自分に最適な機能を持つアプリケーションをインストールしてカスタマイズしていくわけです。今までの携帯電話より愛着が湧きますよね。アプリケーションは新着やランキングを見て気に入ったアプリケーションをインストールするのが一番良いと思います。

最後に私の愛用しているアプリケーションの一部を紹介して終わりにしたいと思います。
Android携帯をお持ちの方はこのアプリをインストールしてみてください。

・OpenWnnフリック入力対応版
　フリック入力に対応しており、素早く文字入力が可能です。最近は絵文字入力に対応しています。（標準だと絵文字入力はできないんです）

・Any Cut、UltimateFaves　
　さまざまなショートカットを作成できます

・PicSay　
　画像編集ならこれが便利です

・e電話帳
　今までの携帯電話の検索に近い形になるので重宝しています

・QR我風　
　自分の連絡先のQRコードを作成できます

・路線ドロイド　
　乗り換え案内はこれを使っています

・WiFi OnOff　
　WiFiの切り替えを簡単にすることができます

みなさんテストは好きですか？私も含めて私の同僚は皆テストが大好きなので、しばしばテストの議論で白熱しすぎてしまいます。今日はそのテストの中から Mock（モック） と Stub（スタブ） について書いてみたいと思います。

Test Double

まずテストにおける Mock と Stub についてですが、これらは Test Double という概念の一部です。Double とは代役という意味で、テスト対象となるシステムが依存する外部のコンポーネントの代わりに、それらしく振舞ってくれるコンポーネントを代役として利用しようということです。

例えば Web アプリの Controller の単体テストがしたい場合に、Model の実装が完了するまでテストができないっていうのでは大変ですよね。そこで、Model の Mock や Stub を利用することにより、Model の影響を受けることなく、Controller の単体テストだけに専念することができます。

このように Test Double を利用することで、依存を排除し、テストを効率良く作成・実行することができます。

Test Double についての詳細は「xUnit Test Patterns(Gerard Meszaros, 2007)」という本や
http://xunitpatterns.com/Test%20Double.html
に書いてあります。なお、Mock と Stub 以外にも Spy, Fake, Dummy 等の Test Double もあるとのことです。

Mock と Stub の違い

さて、では Mock と Stub の違いはなんでしょうか。

先ほどの Test Double の定義では、Mock はテスト時の呼び出しの仕様をあらわしたもので、Stub はテスト時の呼び出しに対して決められた値を返すものです。

これを単に Mock は呼び出しの verification をして、Stub はそれをしないと認識してしまうと、どのようにして Mock と Stub を使い分けるかわからなくなってしまいます。さらにいえば、Mock と Stub が区別されている理由さえわからなくなります。

Mock と Stub の違いはテストの観点の違いです。相互作用（振る舞い）中心のテストに利用するのがMockで、状態中心のテストに利用するのがStubです。

相互作用中心のテストとはテスト対象のシステムと外部のコンポーネントとの間で正しいやり取りがされるかのテスト、いわばプロトコルのテストです。外部のコンポーネントは Mock により置き換えられ、システムから正しい呼び出しがなされているかを監視します。
したがって、例えばWebアプリの Controller の単体テストにおいて相互作用中心のテストが正しく行われてパスしているならば、Model が正しく実装された時に Controller が正しく動作するということが、Model が実装されなくても保障されます。

一方状態中心のテストとはテスト対象のシステムが正しい結果を返すかというテストです。したがって、最終的に返ってくる結果だけが重要なのですが、その過程において外部のシステムとの統合が面倒な時に Stub を利用してテストを簡単にします。なので、 Stub は信頼できる外部のコンポーネント（例えばDBとかLDAPとか）に対して適応するといいと思います。

相互作用中心のテストと状態中心のテスト

さて相互作用中心のテストと状態中心のテスト2種類の観点でのテストが出てきましたが、どちらのテストをやればよいのでしょうか？ 結論からいうと両方やるべきです。

例えば BDD(Behavior Driven Development) では、その名前から振る舞いすなわち相互作用中心のテストだけをやればいいと錯覚してしまいます。たしかに Mock を利用して振る舞いの仕様を作成するのが BDD での spec 作成の大半を占めます。しかし、仕様書の観点からすると、振る舞いすなわちアルゴリズムだけの記述だけでは不十分で、入出力の例が書いてある必要があります。その入出力例を記述するのが状態中心のテストなので、両方やるべきなのです。

もちろん、コンポーネント毎に相互作用中心のテストと状態中心のテストのどちらに比重をおくべきかを考えることが重要になるわけですが。

RR(Double Ruby)

さて Mock を使った RSpec のテストを実際に書いてみようと思います。RSpec には標準で Mock が用意されているのですが、今回は RR(Double Ruby) というライブラリを利用してSinatraで作る blog のテストを書いてみようと思います。（記事の都合上基本的な Sinatra, RSpec, DataMapper の説明は省略しています）

まず RSpec の Mock を RR の Mock で置き換える設定をします。これで rspec の Mock が RRの Mock に置き換えられます。また、Sinatra のテストをするため、Rack::Test::Methods を include しています。

Spec::Runner.configure do |config|
  config.include Rack::Test::Methods
  config.mock_with :rr
end

次に、’/posts/1′ にアクセスすると、DataMapper により ID が 1 の記事が読み込まれ、その article が表示されるという仕様を書いてみます。

describe '/posts/:id' do
  it 'should load Posts with id' do
    mock(Post).get!('1') { mock(Post.new).article { 'article of 1' } }
    get('/posts/1')
    last_response.body.should == 'article of 1'
  end
end

Post は DataMapper で作成した Model です。その Post の Mock に対して get! が呼ばれることを verification しています。中括弧の中は article が呼ばれた時の返り値を指定しています。では、このテストが落ちることを確認したら実装をします。

def '/posts/:id' do
  post = Post.get!(params[:id])
  post.article
end

実装後テストをしてみると、実際にDBに値を入れなくても（DBの状態にかかわらず）テストが通ります。前述したように外部への依存がなく効率の良いテストができる ことが実感できます。

ちなみに RSpec の Mock を利用する場合はこのようにかけます。

Post.should_receive(:get!).with('1')\
  .and_return mock(:article => 'article of 1')

RR の方が実際のコードに近く、かつ短く書けるので素敵です。さらにいえば mock(Post.new) の部分を Machinist を利用して

Post.make_unsaved(:article => 'article of 1')

と書くとさらに素敵なのですが、Machinist については次回以降ということにします。

また、私の同僚が RR は RSpec に比べて matcher の機能が足りない部分があるので、既存の rspec での Mock を RR に置き換える時に困ることがあると言っていました。そこで RSpec と RR(0.10.2) の matcher を見比べたところ例えば hash_including という matcher で差異が見られました。

RSpec の matcher では hash_including は

Foo.should_receive(:color).with(:red, :blue => false)

のように Hash の key の存在確認と key value の組み合わせの両方が指定できます。
一方、RR では

mock(Foo).color(:red => true, :blue => false)

のように key value の組み合わせでしか指定できません。

これの解決には例えば satisfy という matcher を利用するか、RR::WildcardMatchers::HashIncluding.wildcard_match? を書き換えるかすればいいと思います。ここでは、satisfy を利用する例を紹介しておこうと思います。

def hash_has_keys(*args)
  satisfy do |hash|
    args.all? do |arg|
      arg.is_a?(Hash) ? arg.all? {|k, v| hash[k] == v } : hash.has_key?(arg)
    end
  end
end

これを以下のような感じで hash_including という matcherの代わりに利用すれば、

mock(Foo).color(hash_has_keys(:red, {:blue => false, :yellow => false}))

RSpec の hash_including と同様に使えます。

ただし、こうすると matcher が失敗した場合に、

unexpected method invocation:
  color({:red=>true, :green=>false, :blue=>false})
expected invocations:
- color(satisfy {block}) 

と表示されてエラーメッセージがいまいちわかりにくくなってしまうので注意してください。

長くなりましたので、最後にまとめますと、本エントリでは

• Test Doubleの定義に基づく Mock と Stub の違い
• Mock を利用する相互作用中心のテストと Stub を利用することができる状態中心のテストの使い分け
• 相互作用中心のテストを RR の Mock を使って書く例および RR の tips

について説明しました。