8日目: ユニットテスト

最近の2日間の間に、アドベントカレンダの最初の5日の間に学んだ Jobeet の機能をカスタマイズして新しい機能を追加するために、すべての機能をレビューしました。このプロセスにおいて、symfony のより高度な機能にもふれてきました。

今日は、完全に異なる内容: 自動化されたテストを語ります。このトピックの内容はとても大きいので、すべての内容をカバーするのに2日まるごとかかります。

symfony のテスト

symfony にはまったく異なる2つの種類の自動テスト: ユニットテスト (unit test - もしくは単体テスト) と機能テスト (functional test)があります。

ユニットテストはそれぞれのメソッドと関数が適切に機能していることを検証します。それぞれのテストは可能な限りお互いから独立していなければなりません。

一方で、機能テストはアプリケーションの結果のふるまいが全体として正しいか検証します。

symfony のすべてのテストはプロジェクトの test/ ディレクトリに設置されます。ユニットテスト (test/unit/) と機能テスト (test/functional/) 用に2つのサブディレクトリが含まれます。

今日はユニットテストをカバーし、明日は機能テストに専念します。

ユニットテスト

ユニットテストを書くのは Web 開発のベストプラクティスの中で実行するのがもっとも難しいことです。Web 開発者は作品をテストすることに本当に慣れていないのと、たくさんの疑問がわき上がります: 機能を実装する前にテストを書かなければならないのか？何をテストする必要があるのか？テストはすべての単独のエッジケースをカバーする必要があるのか？すべてにおいてよいテストをできる方法は？しかし通常、最初のテストははるかに基本的です: どこで始めるのか？

私たちがテストを強く推奨しているとしても、symfony のアプローチは実践的です: テストを何もしないよりも何かをしたほうが常によいです。テストなしのコードがすでにたくさんありますか？問題ありません。テストの利点から恩恵を受けるためにフルテストスイートを用意する必要はありません。コードでバグを見つけたときにテストを追加することから始めます。時間が経過して、あなたのコードはよりよいものになり、コードカバレッジは上昇し、テストにより自信をもつようになります。実践的なアプローチを始めることで、 時間とともにテストがより快適になります。次のステップは新しい機能に対してテストを書くことです。すぐに、テストがやみつきになりますよ。

たいていのテストライブラリの問題は急激な学習曲線です。テストを書く作業を簡単にするために symfony がとてもシンプルなテストライブラリである lime を提供するのはそういうわけです。

lime テストフレームワーク

lime フレームワークで書かれたユニットテストは同じコードで始まります:

require_once dirname(__FILE__).'/../bootstrap/unit.php';
 
$t = new lime_test(1);

最初に、いくつかのことを初期化するために unit.php ブートストラップファイルがインクルードされます。それから、新しい lime_test オブジェクトが作られ、立ち上げを計画しているテストの数が引数として渡されます。

あらかじめ定義される入力のセットでメソッドもしくは関数を呼び出し、期待される出力で結果を比較することでテストは動作します。この比較はテストが通るもしくは通らないかどうかを決めます。

比較しやすくするために、lime_test オブジェクトはいくつかのメソッドを提供します:

lime_test オブジェクトは他の便利なテストメソッドも提供します:

最後に、comment($msg)メソッドはコメントを出力しますが、テストは実行しません。

ユニットテストを実行する

すべてのユニットテストは test/unit/ ディレクトリに保存されます。慣習では、テストの名前はテストするクラスの名前にサフィックスの Test をつけたものです。ともかく test/unit/ ディレクトリの下でファイルを編成できますが、lib/ ディレクトリの構造を複製することをお勧めします。

ユニットテストを説明するために、Jobeet クラスをテストします。

test/unit/JobeetTest.php ファイルを作り、次のコードを内部にコピーします:

// test/unit/JobeetTest.php
require_once dirname(__FILE__).'/../bootstrap/unit.php';
 
$t = new lime_test(1);
$t->pass('This test always passes.');

テストを起動するには、ファイルを直接実行できます:

$ php test/unit/JobeetTest.php

もしくは test:unit タスクを使います:

$ php symfony test:unit Jobeet

slugify をテストする

Jobeet::slugify() メソッドのテストを書くことでユニットテストの世界のすてきな旅を始めましょう。

URL に文字列を安全に含められるようにクリーンナップするために5日目に slugify() メソッドを作りました。ASCII ではないすべての文字列をダッシュ (-) に変換するもしくは文字列を小文字に変換するなどの基本的な変換で構成されます:

テストファイルの内容を次のコードで置き換えます:

// test/unit/JobeetTest.php
require_once dirname(__FILE__).'/../bootstrap/unit.php';
 
$t = new lime_test(6);
 
$t->is(Jobeet::slugify('Sensio'), 'sensio');
$t->is(Jobeet::slugify('sensio labs'), 'sensio-labs');
$t->is(Jobeet::slugify('sensio   labs'), 'sensio-labs');
$t->is(Jobeet::slugify('paris,france'), 'paris-france');
$t->is(Jobeet::slugify('  sensio'), 'sensio');
$t->is(Jobeet::slugify('sensio  '), 'sensio');

書かれたテストをよく見ると、それぞれの行は1つのことしかテストしていないことがわかります。これはユニットテストを書く際に覚えておく必要があることです。一度に1つのことをテストします。

テストファイルを実行できます。すべてのテストが期待どおりに通る場合、「緑色のバー」を楽しめます。そうでなければ、悪名高い「赤いバー」が通らないテストを修正するように警告します。

テストが通らなければ、通らない理由に関する情報が出力されます。しかし1つのファイルで数百のテストがある場合、どれが通らないふるまいなのか素早く特定するのが困難になる可能性があります。

すべての lime テストメソッドは最後の引数としてテストの説明用の文字列を受け取ります。本当に何をテストしているのか説明することが強制されるので、重宝します。メソッドに期待されるふるまいに対してドキュメントの形式でも提供できます。メッセージを slugify テストファイルに追加してみましょう:

require_once dirname(__FILE__).'/../bootstrap/unit.php';
 
$t = new lime_test(6);
 
$t->comment('::slugify()');
$t->is(Jobeet::slugify('Sensio'), 'sensio', '::slugify() converts all characters to lower case');
$t->is(Jobeet::slugify('sensio labs'), 'sensio-labs', '::slugify() replaces a white space by a -');
$t->is(Jobeet::slugify('sensio   labs'), 'sensio-labs', '::slugify() replaces several white spaces by a single -');
$t->is(Jobeet::slugify('  sensio'), 'sensio', '::slugify() removes - at the beginning of a string');
$t->is(Jobeet::slugify('sensio  '), 'sensio', '::slugify() removes - at the end of a string');
$t->is(Jobeet::slugify('paris,france'), 'paris-france', '::slugify() replaces non-ASCII characters by a -');

テストの説明文字列は何をテストするのか理解しようとするときにも貴重なツールです。テストの文字列でパターンがわかります: これらはメソッドがどのようにふるまいテストするメソッドの名前でつねに始まることを記述しています。

$ php symfony test:coverage test/unit/JobeetTest.php lib/Jobeet.class.php

$ php symfony test:coverage --detailed test/unit/JobeetTest.php lib/Jobeet.class.php

新しい機能のためにテストを追加する

空の文字列用の slug は空の文字列です。これもテスト可能で、動作します。しかし URL に空文字列を含めるのはよいアイデアではありません。空の文字列の場合に「n-a」の文字列を返すように slugify() メソッドを変更してみましょう。

テストを最初に書き、メソッドを更新するもしくは逆のことができます。

本当に好みの問題ですが、最初にテストを書くことでコードが計画したものを本当に実装するものに自信を得られます:

$t->is(Jobeet::slugify(''), 'n-a', '::slugify() converts the empty string to n-a');

テストを最初に書いて機能を実装する、この開発の方法論はテスト駆動開発 (TDD) として知られます。

テストを立ち上げると、赤いバーが表示されなければなりません。そうでなければ、機能はすでに実装されたもしくはテストする予定であったものがテストされないことを意味します。Jobeet クラスを編集して、冒頭部分に次の条件を追加します:

// lib/Jobeet.class.php
static public function slugify($text)
{
  if (empty($text))
  {
    return 'n-a';
  }
 
  // ...
}

テストは期待どおりに通らなければならず、そして緑のバーを享受できますが、テスト計画を更新することを覚えている場合のみです。そうでなければ、6つのテストが計画され、追加の1つが実行されたことを伝えるメッセージが表示されます。テストの計画を最新に保つのは重要です。テストスクリプトが初期に止まる場合に情報の提供が続けられるからです。

バグが原因でテストを追加する

時間が経過しユーザーの1人がうっとおしいバグを報告する場合を考えてみましょう: 求人リンクが404エラーページを指し示します。調査の後で、これらの求人が空の会社、職、所在地のスラッグなどをもつなど理由を見つけます。

どのように可能なのか？

データベースのレコードを調べますがカラムは完全に空ではありません。しばらく考え、当たりをつけて、原因を見つけます。文字列が ASCII ではない文字のみを含む場合、slugify() メソッドはこれを空の文字列に変換します。さいわいにして、原因を発見したら、Jobeet クラスを開き、問題をすぐに直します。しかしこれはわるいアイデアです。最初に、テストを追加しましょう:

$t->is(Jobeet::slugify(' - '), 'n-a', '::slugify() converts a string that only contains non-ASCII characters to n-a');

テストがパスしないことをチェックした後で、Jobeet クラスを編集して空の文字列のチェックをメソッドの末端に移動させます:

static public function slugify($text)
{
  // ...
 
  if (empty($text))
  {
    return 'n-a';
  }
 
  return $text;
}

これで、ほかのすべてのテストのように、新しいテストは通ります。100％のカバレッジにもかかわらず slugify() にはバグがありました。

テストを書く際にすべてのエッジケースを考えることはできませんが、それで十分です。しかしエッジケースが見つかったら、コードを修正する前にテストを書く必要があります。これは時間の経過と共にあなたのコードがよくなることも意味するので、これは常によいことです。

$t->is(Jobeet::slugify('Développeur Web'), 'developpeur-web', '::slugify() removes accents');

// http://php.vrana.cz/vytvoreni-pratelskeho-url.phpより派生
static public function slugify($text)
{
  // 文字ではないもしくは数値を - に置き換える
  $text = preg_replace('#[^\\pL\d]+#u', '-', $text);
 
  // トリムする
  $text = trim($text, '-');
 
  // 翻字する
  if (function_exists('iconv'))
  {
    $text = iconv('utf-8', 'us-ascii//TRANSLIT', $text);
  }
 
  // 小文字に変換する
  $text = strtolower($text);
 
  // 望まない文字を取り除く
  $text = preg_replace('#[^-\w]+#', '', $text);
 
  if (empty($text))
  {
    return 'n-a';
  }
 
  return $text;
}

if (function_exists('iconv'))
{
  $t->is(Jobeet::slugify('Développeur Web'), 'developpeur-web', '::slugify() removes accents');
}
else
{
  $t->skip('::slugify() removes accents - iconv not installed');
}

Doctrine ユニットテスト

データベース接続

Doctrine モデルクラスのユニットテストはデータベースの接続が必要なので少し複雑です。すでにデータベースの接続は開発環境にありますが、テスト専用のデータベースを作るのはよい習慣です。

1日目において、アプリケーションのコンフィギュレーションを変更する方法として環境 (environment) を紹介しました。デフォルトでは、symfony のすべてのテストは test 環境で実行されるので、test 環境用に異なるデータベースを設定しましょう:

$ php symfony configure:database --name=doctrine --class=sfDoctrineDatabase --env=test "mysql:host=localhost;dbname=jobeet_test" root mYsEcret

env オプションはデータベースのコンフィギュレーションが test 環境専用であることを タスクに伝えます。3日目でこのタスクを使ったときは、env オプションを渡しませんでした。コンフィギュレーションはすべての環境に適用されます。

データベースのコンフィギュレーションの変更が終わったので、doctrine:insert-sql タスクを使ってブートストラップします:

$ mysqladmin -uroot -pmYsEcret create jobeet_test
$ php symfony doctrine:insert-sql --env=test

# config/databases.yml
dev:
  doctrine:
    class: sfDoctrineDatabase
 
test:
  doctrine:
    class: sfDoctrineDatabase
    param:
      dsn: 'mysql:host=localhost;dbname=jobeet_test'
 
all:
  doctrine:
    class: sfDoctrineDatabase
    param:
      dsn: 'mysql:host=localhost;dbname=jobeet'
      username: root
      password: null

テストデータ

テスト用に専用のデータベースを用意したので、テストデータをロードする方法が必要です。3日目において、doctrine:data-load タスクの使い方を学んだとおり、テストに関しては、データベースを既知の状態するためにテストを実行するたびにデータをリロードする必要があります。

doctrine:data-load タスクはデータをロードするために、内部で Doctrine_Core::loadData() メソッドを使います:

Doctrine_Core::loadData(sfConfig::get('sf_test_dir').'/fixtures');

loadData() メソッドは最初の引数としてディレクトリもしくはファイルを受け取ります。このメソッドはディレクトリかつ/もしくはファイルの配列も受け取ることができます。

初期データはすでに data/fixtures/ ディレクトリで作りました。テストに関して、フィクスチャを test/fixtures/ ディレクトリに設置します。これらのフィクスチャは Doctrine のユニットテストと機能テストに使われます。

では、data/fixtures/ から test/fixtures/ ディレクトリにファイルをコピーします。

JobeetJob をテストする

JobeetJob モデルクラス用にユニットテストを作りましょう。

Doctrine ユニットテストは同じコードで始まるので、bootstrap/ テストディレクトリで次の内容をもつ Doctrine.php ファイルを作ります:

// test/bootstrap/Doctrine.php
include(dirname(__FILE__).'/unit.php');
 
$configuration = ProjectConfiguration::getApplicationConfiguration( 'frontend', 'test', true);
 
new sfDatabaseManager($configuration);
 
Doctrine_Core::loadData(sfConfig::get('sf_test_dir').'/fixtures');

スクリプトは自分自身をよく説明しています:

• フロントコントローラに関しては、test 環境用にコンフィギュレーションオブジェクトを初期化します:

  $configuration = ProjectConfiguration::getApplicationConfiguration( 'frontend', 'test', true);

• データベースマネージャを作ります。databases.yml 設定ファイルをロードしてこれは Doctrine 接続を初期化します。

  new sfDatabaseManager($configuration);

• Doctrine_Core::loadData() を使ってテストデータをロードします:

  Doctrine_Core::loadData(sfConfig::get('sf_test_dir').'/fixtures');

すべての準備ができたので、JobeetJob クラスのテストを始めることができます。

最初に、test/unit/model の JobeetJobTest.php ファイルを作る必要があります:

// test/unit/model/JobeetJobTest.php
include(dirname(__FILE__).'/../../bootstrap/Doctrine.php');
 
$t = new lime_test(1);

それから、getCompanySlug() メソッドでテストを追加して始めましょう:

$t->comment('->getCompanySlug()');
$job = Doctrine_Core::getTable('JobeetJob')->createQuery()->fetchOne();
$t->is($job->getCompanySlug(), Jobeet::slugify($job->getCompany()), '->getCompanySlug() return the slug for the company');

任意の場所ですでにテストしているので、スラッグが正しくなければ、getCompanySlug() メソッドのみをテストします。

save() メソッドのテストを書くことは微妙に難しいです:

$t->comment('->save()');
$job = create_job();
$job->save();
$expiresAt = date('Y-m-d', time() + 86400 * sfConfig::get('app_active_days'));
$t->is($job->getDateTimeObject('expires_at')->format('Y-m-d'), $expiresAt, '->save() updates expires_at if not set');
 
$job = create_job(array('expires_at' => '2008-08-08'));
$job->save();
$t->is($job->getDateTimeObject('expires_at')->format('Y-m-d'), '2008-08-08', '->save() does not update expires_at if set');
 
function create_job($defaults = array())
{
  static $category = null;
 
  if (is_null($category))
  {
    $category = Doctrine_Core::getTable('JobeetCategory')
      ->createQuery()
      ->limit(1)
      ->fetchOne();
  }
 
  $job = new JobeetJob();
  $job->fromArray(array_merge(array(
    'category_id'  => $category->getId(),
    'company'      => 'Sensio Labs',
    'position'     => 'Senior Tester',
    'location'     => 'Paris, France',
    'description'  => 'Testing is fun',
    'how_to_apply' => 'Send e-Mail',
    'email'        => 'job@example.com',
    'token'        => rand(1111, 9999),
    'is_activated' => true,
  ), $defaults));
 
  return $job;
}

ほかの Doctrine クラスをテストする

ほかのすべての Doctrine クラス用のテストを追加できます。ユニットテストの過程に慣れつつあるので、とても簡単です。

ユニットテストハーネス

test:unit タスクはプロジェクトのすべてのユニットテストを起動するためにも使うことができます:

$ php symfony test:unit

タスクはそれぞれのテストファイルがパスするか失敗するかを出力します:

また明日

アプリケーションのテストが簡単でなくても、今日のチュートリアルをスキップしたい方がいらっしゃるのはわかります。取り組んでいただけば幸いです。

symfony を受け入れることは symfony が提供するすばらしい機能すべてを学ぶことだけでなく、これは symfony が提唱する開発の哲学とベストプラクティスでもあります。テストはそれらの1つです。遅かれ早かれ、ユニットテストは時間の節約になります。これらはコードへの確固たる信頼と恐れずにリファクタリングできる自由を与えてくれます。ユニットテストは何かが壊れているときに警告してくれる安全な護衛です。symfony フレームワーク自身には9000以上のテストがあります。

明日は job と category モジュールの機能テストを書きます。それまでは、Jobeet モデルクラスのユニットテストをさらに書くための時間をとってください。