PHPUnitテストを書く

各テストの開始時、自動的にリセットされて新しくインストールされた状態となります。

ネームスペース

• /testsディレクトリ以下のすべてはネームスペースを使用する場合にいくつかの簡単なルールに従う必要があります。これらはテストケース、フィクスチャ、ジェネレータ、そして、一般的にはこれらのディレクトリ内すべてのクラスに適用されます。ご覧ください! (要約 = **/classes ディレクトリに適用されるルールと100% 同じです)。

テストケースクラス

すべてのMoodle単体テストで使用できる3つの基本テストクラスがあります - basic_testcase、advanced_testcaseおよびprovider_testcaseです。各クラスファイルには1つのテストケースのみを置くことを強く推奨します。

basic_testcase

データベースおよびdataroot、そしてPHPのグローバルを変更しない非常にシンプルなテストです。例えば公式のPHPUnitチュートリアルにある例を試すときに使用します。

advanced_testcase

Moodleのコードを簡単にテストできるよう強化されたテストケースクラスです。

provider_testcase

プライバシープロバイダのテストを容易にするために拡張された拡張テストケースクラスです。4番目のテストケースクラスはMoodleデータベースレイヤのテスト用に特別に設計されているため、他の目的で使用しないでください。

アサーション Assertions

アサーションに関する完全なリストは以下で確認できます。

Moodle version	PHPUnit version	Links
Moodle 3.11	PHPUnit 9.5	ドキュメンテーション
Moodle 3.10	PHPUnit 8.5	ドキュメンテーション
Moodle 3.7 - 3.9	PHPUnit 7.5	ドキュメンテーション
Moodle 3.4 - 3.6	PHPUnit 6.5	ドキュメンテーション

サンプルプラグインテストケース

PHPUnit テストはプラグインのtests/*_test.phpファイル (例: mod/myplugin/tests/sample_test.php) に配置されます。このファイルにはadvanced_testcaseを継承したクラスを1つだけ含む必要があります。

 namespace mod_myplugin;

 class sample_test extends \advanced_testcase {
     public function test_adding() {
         $this->assertEquals(2, 1+2);
     }
 }

詳細はPHPUnitインテグレーション#クラスおよびファイル命名規則をご覧ください。

Moodleライブラリファイルのインクルード

あなたがいくつかのMoodleライブラリファイルをインクルードしたい場合、常に「global $CFG」を宣言する必要があります。これはテストケースファイルが自動的にグローバル$CFGを利用できない非Moodleコードからインクルードされる可能性があることが理由です。

自動状態リセット

各テストの後、デフォルトではMoodleデータベースおよびdatarootは自動的にインストール直後の状態にリセットされます。データベースまたは標準グローバル変数の変更が予想される場合、$this->resetAfterTest()を使用してください

あなたが「Warning: unexpected database modification, resetting DB state」というエラーメッセージに遭遇した場合、テストが$this->resetAfterTest()を使用していないためだとお考えください。

 namespace mod_myplugin;

 class test_something extends \advanced_testcase {
     public function test_deleting() {
         global $DB;
         $this->resetAfterTest(true);
         $DB->delete_records('user');
         $this->assertEmpty($DB->get_records('user'));
     }
     public function test_user_table_was_reset() {
         global $DB;
         $this->assertEquals(2, $DB->count_records('user', array()));
     }
 }

ジェネレータ

デフォルトのインストールを修正する必要のあるテストでは新しいコースまたはユーザ等の作成にジェネレータを使用できます。このページのすべての例はadvanced_testcaseから派生したテストクラスのテストメソッドから使用する必要があります。

単体テストのパラメータにPHPUnit @dataProvider関数を使用している場合、あなたはデータプロバイダ関数でデータジェネレータを使用またはユーザ等を変更できないことに留意してください。データプロバイダでは「データのインスタンス化/生成」しないでください'。ただ、定義のみしてください。そして、テスト本体ではインスタンス化/生成を進めれます。

ユーザを作成する

それぞれのテスト開始時にはゲストおよび管理者の2種類のユーザのみ存在します。あなたがさらにテストアカウントを追加する必要がある場合、以下を使用してください:

 $user = $this->getDataGenerator()->create_user();

あなたはユーザアカウントのプロパティも指定できます。例えば以下のようになります:

 $user1 = $this->getDataGenerator()->create_user(array('email'=>'user1@example.com', 'username'=>'user1'));

デフォルトではユーザはログインしていないため、 現在の$USER値を変更するにはsetUser()メソッドを使用してください:

 $this->setUser($user1);

ゲストおよび管理者アカウントにはショートカットメソッドがあります:

 $this->setGuestUser();
 $this->setAdminUser();

現在のユーザをログインなしにするためにNullを使用できます:

 $this->setUser(null);

コースカテゴリを作成する

 $category1 = $this->getDataGenerator()->create_category();
 $category2 = $this->getDataGenerator()->create_category(array('name'=>'Some subcategory', 'parent'=>$category1->id));

コースを作成する

 $course1 = $this->getDataGenerator()->create_course();
 
 $category = $this->getDataGenerator()->create_category();
 $course2 = $this->getDataGenerator()->create_course(array('name'=>'Some course', 'category'=>$category->id));

活動を作成する

活動プラグインの中にはインスタンスジェネレータが含まれているものもあります。ジェネレータクラスはplugindirectory/tests/generator/lib.phpで定義されています。

以下、1ページのリソースで新しいコースを作成する例です:

 $course = $this->getDataGenerator()->create_course();
 $generator = $this->getDataGenerator()->get_plugin_generator('mod_page');
 $generator->create_instance(array('course'=>$course->id));

以下、機能的には同じですが、少し短くなります:

 $course = $this->getDataGenerator()->create_course();
 $page = $this->getDataGenerator()->create_module('page', array('course' => $course->id));

コーホートを作成する

Moodle 2.4以降、データジェネレータは新しいコホートの作成に対応しています。

 $cohort = $this->getDataGenerator()->create_cohort();

ユーザ登録の簡略化

標準の登録APIの代わりにデータジェネレータの簡易メソッドを使用できます。これは自己登録および手動登録プラグインと一緒に使用することを意図しています。

$this->getDataGenerator()->enrol_user($userid, $courseid);
$this->getDataGenerator()->enrol_user($userid, $courseid, $teacherroleid);
$this->getDataGenerator()->enrol_user($userid, $courseid, $teacherroleid, 'manual');

尺度を作成する

$this->getDataGenerator()->create_scale();
$this->getDataGenerator()->create_scale(array('name' => $name, 'scale' => $scale, 'courseid' => $courseid, 'userid' => $userid, 'description' => description, 'descriptionformat' => $descriptionformat));

ロールを作成する

$this->getDataGenerator()->create_role();
$this->getDataGenerator()->create_role(array('shortname' => $shortname, 'name' => $name, 'description' => description, 'archetype' => $archetype));

タグを作成する

$this->getDataGenerator()->create_tag();
$this->getDataGenerator()->create_tag(array(
    'userid' => $userid, 
    'rawname' => $rawname,
    'name' => $name, 
    'description' => $description, 
    'descriptionformat' => $descriptionformat,
    'flag' => $flag
));

グループ

グループを作成する

$this->getDataGenerator()->create_group(array('courseid' => $courseid));
$this->getDataGenerator()->create_group(array('courseid' => $courseid, 'name' => $name, 'description' => $description, 'descriptionformat' => $descriptionformat));

グループにユーザを追加する

$this->getDataGenerator()->create_group_member(array('userid' => $userid, 'groupid' => $groupid));
$this->getDataGenerator()->create_group_member(array('userid' => $userid, 'groupid' => $groupid, 'component' => $component, 'itemid' => $itemid));

グルーピングを作成する

$this->getDataGenerator()->create_grouping(array('courseid' => $courseid));
$this->getDataGenerator()->create_grouping(array('courseid' => $courseid, 'name' => $name, 'description' => $description, 'descriptionformat' => $descriptionformat));

グルーピングにグループを追加する

$this->getDataGenerator()->create_grouping_group(array('groupingid' => $groupingid, 'groupid' => $groupid));

リポジトリ

リポジトリインスタンスを作成する

一部のリポジトリプラグインにはインスタンスジェネレータを含むものがあります。ジェネレータクラスは plugindirectory/tests/generator/lib.phpで定義されています。

$this->getDataGenerator()->create_repository($type, $record, $options);

リポジトリタイプを作成する

一部のリポジトリプラグインにはタイプジェネレータを含むものがあります。ジェネレータクラスはplugindirectory/tests/generator/lib.phpで定義されています。

$this->getDataGenerator()->create_repository_type($type, $record, $options);

評定を作成する

評定カテゴリ

$this->getDataGenerator()->create_grade_category(array('courseid' => $courseid));
$this->getDataGenerator()->create_grade_category(array('courseid' => $courseid, 'fullname' => $fullname));

評定アイテム

$this->getDataGenerator()->create_grade_item();
$this->getDataGenerator()->create_grade_item(array('itemtype' => $itemtype, 'itemname' => $itemname, 'outcomeid' => $outcomeid, 'scaleid' => $scaleid, 'gradetype' => $gradetype));

アウトカム

$this->getDataGenerator()->create_grade_outcome();
$this->getDataGenerator()->create_grade_item(array('fullname' => $fullname));

他のタイプのプラグイン

他のどのようなタイプのプラグインでもジェネレータを持てます。ジェネレータクラスではcomponent_generator_baseを継承する必要があります。そして、あなたは $mygenerator = $this->getDataGenerator()->get_plugin_generator($frankenstylecomponentname)でインスタンスを取得できます。

いくつかのタイプのプラグインのために上で文書化されたmodのように拡張するcomponent_generator_baseよりも、さらに特定のクラス、例えばtesting_module_generatorのようなクラスがあるかもしれません、そのクラスでは使用すべきメソッド名の一貫したセットが与えてあることでしょう。そうでなければ、あなたが作業する必要のある別のものを作成するためにジェネレータ上でどのようなメソッドでも好きなように作成できます。

長いテスト

標準的なテストはすべて可能な限り高速に実行されるべきです。実行に時間を要するもの (10秒以上) または負荷のかかるもの (たとえば外部のサーバへの問い合わせに開発マシンが殺到してしまった場合等) はPHPUNIT_LONGTESTがtrueの場合のみ実行されるようにしなければなりません。この定数はphpunit.xmlあるいはconfig.phpで直接設定できます。

長いテストデータ

大きなテストデータセットをコード内の配列としてではなく、ファイルとして簡単に管理する方法に関して、advanced_testcase::createXMLDataSet()、advanced_testcase::createCsvDataSet()および関連関数を参照してください。詳細はPHPUnit_integration#Extra_methods]]を参照してください。

メッセージ送信テスト

あなたはmessage_send()で送信されたすべてのメッセージを一時的にメッセージシンクオブジェクトにリダイレクトできます。これにより開発者はテストしたコードが期待どおりのメッセージを送信しているかどうか確認できます。

メッセージングを使ったコードをテストする場合、まずトランザクションを無効にしてください。 メッセージングを新しいメッセージシンクにリダイレクトすることにより、 後で結果を確認できます。

$this->preventResetByRollback();
$sink = $this->redirectMessages();
//... メッセージを送信するコード
$messages = $sink->get_messages();
$this->assertEquals(3, count($messages));
//.. . テストメッセージが正しい順序および適切な内容で生成されました。

メール送信テスト

あなたはemail_to_user()で送信されたメールを一時的にメールメッセージシンクオブジェクトにリダイレクトできます。これにより、開発者はテストしたコードが期待とおりのメールを送信しているかどうかを確認できます。

メッセージングを使ったコードをテストする場合、まず「noemailever」の設定を解除してください。メールを新しいメッセージシンクにリダイレクトすることにより、 後で結果を確認できます。

unset_config('noemailever');
$sink = $this->redirectEmails();
//... code that is sending email
$messages = $sink->get_messages();
$this->assertEquals(1, count($messages));

ログストア

あなたはログストアに書き込まれたイベントをテストできますが、テスト実行の前にイベントがデータベースに書き込まれるようトランザクションを無効にして、少なくとも1つの有効なログストアを有効にした上で、ログストアのバッファリングを無効にする必要があります。

$this->preventResetByRollback();
set_config('enabled_stores', 'logstore_standard', 'tool_log');
set_config('buffersize', 0, 'logstore_standard');
get_log_manager(true);

あなたのカバレッジを確認する

PHPUnitには単体テストのコードカバレッジ情報を生成する機能があります。

Moodle 3.7以前、このカバレッジはすべてのファイルを読み込み、そのファイルが全くカバーできないかどうか、または意図的にカバーされているかどうかに関係なく、すべてに対してカバレッジを生成していました。

Moodle 3.7以降、「phpunit.xml」設定には各コンポーネントの生成されたカバレッジインクルードおよびエクスクルード情報が含まれています。

インクルードおよびエクスクルード設定を生成する

あなたが書いているテストと一緒にcoverage.phpファイルを作成することにより、どのファイルがカバレッジのためにチェックされるかプログラム的に記述できます。

Moodle 4.0以降、デフォルト設定がすべてのプラグインに適用されるため、あなたが追加ファイルをカバーしたい場合を除き、coverage.phpを提供する必要はありません。

coverage.phpファイルではテスト対象のコンポーネントに含まれるファイルおよびフォルダを一覧表示できます。指定されたすべてのパスはテストされるコンポーネントからの相対パスです。例えば「mod_forum」を扱う場合、あなたのコードは「mod_forum」に置かれます。また、単体テストは「mod/forum/tests/example_test.php」にあります。カバレッジファイルは「mod/forum/tests/coverage.php」にあります。指定されたすべてのパスは「mod/forum」からの相対パスとなります。

含まれるファイル、含まれるフォルダ、除外されるファイルおよび除外されるフォルダを組み合わせて指定できます。これにより、例えば「classes」ディレクトリ全体を含みながら、その中の特定のファイルまたはフォルダを除外できます。

以下「mod_forum」のcoverage.phpの例です:

メモ: Moodleバージョン3.7および3.10では使用される文法が少しだけ異なります。

return new class extends phpunit_coverage_info {
    /** @var array The list of folders relative to the plugin root to include in coverage generation. */
    protected $includelistfolders = [
        'classes',
        'externallib.php',
    ];

    /** @var array The list of files relative to the plugin root to include in coverage generation. */
    protected $includelistfiles = [];

    /** @var array The list of folders relative to the plugin root to exclude from coverage generation. */
    protected $excludelistfolders = [];

    /** @var array The list of files relative to the plugin root to exclude from coverage generation. */
    protected $excludelistfiles = [];
};

また、@coversアノテーションの使用により、各テストがどのクラスまたは関数を効果的にカバーしているか、より明確に定義できることに留意してください。詳細はドキュメンテーションをご覧ください。

Moodle 4.0以降、以下のデフォルト設定が適用されます:

return new class extends phpunit_coverage_info {
    /** @var array The list of folders relative to the plugin root to include in coverage generation. */
    protected $includelistfolders = [
        'classes',
        'tests/generator',
    ];

    /** @var array The list of files relative to the plugin root to include in coverage generation. */
    protected $includelistfiles = [
        'externallib.php',
        'lib.php',
        'locallib.php',
        'renderer.php',
        'rsslib.php',
    ];

    /** @var array The list of folders relative to the plugin root to exclude from coverage generation. */
    protected $excludelistfolders = [];

    /** @var array The list of files relative to the plugin root to exclude from coverage generation. */
    protected $excludelistfiles = [];
};

すでにcoverage.phpファイルが存在する場合、定義済みの値にデフォルトが追加されます。

ベストプラクティス

あなたが単体テストを書く場合に考慮すべきいくつかのベストプラクティス、提案、そして避けるべき点があります。そのいくつかを以下に説明します。

コードカバレッジ

PHPUnitには単体テストのコードカバレッジ情報を生成する機能があり、Moodle 3.7からサポートされています。あなたがコードを書く場合、プラグインのカバレッジの確認を検討することをお勧めします。

PHPUnitドキュメンテーションで説明されているように@coversアノテーションを明示的に設定することを推奨します。

resetAfterTestの使用を最小限に留める

上で説明した例の多くでは

resetAfterTest

という命名法を用いてテスト終了後にデータベースおよびファイルシステムをリセットしていますが、 必要がなければこれを使用しないのが理想的でしょう。

一般的に言えばモック可能で実際の修正を必要としないコードを書くことを目指すべきでしょう。resetAfterTestを使用した場合、テストの速度は低下してしまいます。

共有setUpおよびインスタンス変数の扱いに注意する

あなたはPHPUnit のテストで以下の主な2つの理由のためインスタンス変数の作成方法および使用方法に注意する必要があります:

1. あなたがsetUpでフィクスチャを作成またはresetAfterTest関数をコールした場合、 そのフィクスチャおよび条件はテストスイートのすべてのテストに適用されます。これら条件を満たさないテストをスイートに追加した場合、 その条件が満たされることはありません。これによりテストが遅くなる場合があります。
2. PHPUnitは起動時に各テストケースのインスタンスを作成して、 テストが実行される間はそれを破棄しません。テストケース内のデータをインスタンスデータとして保存する場合、_entire suite_が終了するまでメモリに保存されます。これはセットアップされて積極的に破棄されないフィクスチャはガベージコレクションされずにメモリの肥大化に繋がることを意味します。ひどい場合にはメモリの枯渇に繋がる可能性があります。

データを生成およびresetAfterTestを設定するsetUpを含む既存のテストケースは段階的に廃止して、新しいケースを導入しないでください。

dataProvider関数を活用する

PHPUnitのdataProvider機能は非常に強力で便利であり、 あなたは様々な条件で関数を素早く簡単に検証できます。 しかし、dataProvidersを使用する場合、以下のルールに従ってください:

• resetAfterTestを必要とするリセット可能なデータの追加を最小限に抑えてください。
• データプロバイダではデータをインスタンス化/生成しないでください。データを定義するのみにしてください。そして、テスト本体はインスタンス化/作成に進めます。データプロバイダはtestSuiteがインスタンス化された後、どのテストが実行される前にもコールされます。各テストは完全なsetUpおよびtearDownを実行して、作成されたデータはすべて破棄されます。

/**
 * Test function accepts parameters passed from the specified data provider.
 *
 * @dataProvider foobar_provider
 * @param int $foor
 * @param int $bar
 */
public function test_foobar(int $foo, int $bar) {
    // Perform the tests here.
}

/**
 * Data provider for {@see self::test_foobar()}.
 *
 * @return array List of data sets - (string) data set name => (array) data
 */
public function foobar_provider(): array {
    return [
        'Same numbers' => [
            'foo' => 42,
            'bar' => 42,
        ],
        'Different numbers' => [
            'foo' => 21,
            'bar' => 84,
        ],
    ];
}

追加テスト設定

通常、テストは外部システムとは連動せずに、どのシステムでも同じように動作する必要があります。しかし、時にはあなたは外部システムとの接続またはシステム構成のために何らかのオプションを指定する必要があります。config.phpから$CFG設定を使用することは意図的に不可能です。 カスタム設定を追加するには以下のようにいくつかの方法があります:

• phpunit.xmlファイルでテスト設定定数を定義する。
• config.phpでテスト設定定数を定義する。

これらの定数はテストまたはプラグインのコードで使用できます。

Moodle 3.11およびそれ以上で動作するよう単体テストをアップグレードする (PHPUnit 9.5)

Moodle 3.11はPHPUnitは9.5にアップグレードされました (以前のバージョンでは8.5が使用されていました)。これはMoodle 3.11でサポートされるPHPのバージョン (7.3、7.4、8.0) にテスト環境を合わせるためです (詳細はMDL-71036および関連する報告をご覧ください)。

既存のテストの多くはPHPUnit 9.5でもそのまま動作しますが、かなりの数の非推奨の警告 (テストの出力では「W」) が表示されるはずです。これらの警告は次のPHPUnitのアップグレードですべてエラーになるため、可能な限り早く新しい対応するものに置き換えるべきでしょう。

PHPUnit 9.5での変更点については以下の資料をご覧ください:

• 良記事 リリースの主要な変更点が説明されています。
• PHPUnit 9リリースアナウンスメント
• 詳細変更履歴 (いずれも変更を必要とする修正を含んでいるため): 9.0, 9.1, 9.3, 9.5
• 公式PHPUnitマニュアル

すべての実行すべき変更および置換の要約はlib/upgrade.txtファイルにあります。主なポイントは以下のとおりです:

• PHPUnit 8.5で非推奨となった変更点 (以下のセクションを参照) はすべて削除されたため、エラーが発生するようになりました。
• assertContains()はより厳しく比較するようになりました (assertSame() のように)。新しいassertContainsEquals()が作成され、以前の挙動を提供します。
• phpunit.xmlスキーマへの変更 (ほとんどが内部的なものです)。あなたがカスタムphpunit.xmlファイルを使用している場合のみ、これらが影響します。
  • 前の<filter>セクションは現在 (良い意味で) <coverage>と呼ばれています。そして、その中では:
    • <whitelist>は<include>に置換されました。
    • <exclude>は<whitelist>の子ではなくなりました。代わりに<coverage>の子になりました。
  • しかし、coverage.phpファイルで使用されていた$whitelistxxxプロパティが非推奨となったため、 カバレッジ情報を定義する際には代わりにincludelistfoldersおよびincludelistfiles (xmlの要素をより適切にマッピングするため) を使用するという意味があります。
• 警告: 個別のテストファイルは実行できないようになりました。実行したいテストを指定するには別の実行方法 (filter、suite、config) のいずれかを使用してください。これは最善の方法が合意された場合にMDL-71049で修正されることを期待しています。
• よく使われるアサーション: ファイルアサーション、正規表現アサーション、例外期待値等 ... これらはすべて次のPHPUnitのアップデートでエラーになることに注意してください。そのため、早急に更新することをお勧めします。

最後に問題に関連する変更を点確認するのも良いアイデアです。可能であればコミットメッセージに有用で十分な説明を添えてください。

Moodle 3.10以降で動作するようにユニットテストをアップグレードする (PHPUnit 8.5)

Moodle 3.10ではPHPUnitが8.5にアップグレードされました (旧バージョンでは7.5が使用されていました)。これはMoodle 3.10でサポートされるPHPのバージョン (7.2、7.3および7.4) およびテスト環境の整合性を高めるため、およびMoodle 3.11 (php バージョン 7.3、7.4および 8.0) で必要となるPHPUnit 9.xへの移行を容易にして、多くの非推奨要素を事前に削除するために実施されました (MDL-67673およびMDL-64600を参照してください)。(詳細はMDL-67673およびMDL-64600を参照してください)。

既存のテストの99%はPHPUnit 8.5でそのまま動作しますが、かなりの数の非推奨の警告 ("W" が出力されます) が表示されます。これらの警告は次のPHPUnitアップグレードですべてエラーになるため、可能な限り早く解消すべきです。

PHPUnit 8.5での変更点に関して、以下のリソースをご覧ください:

• 良記事 リリースの主要変更点すべてが説明されています。
• PHPUnit 8リリースアナウンスメント
• リリースの詳細変更ログ
• 公式PHPUnitマニュアル
• すべての実行すべき変更および置換に関する分かりやすい要約はlib/upgrade.txtファイルにあります。主なポイントは以下のとおりです:
  • すべてのテンプレートメソッド (setUp()、tearDown()) がvoidを返す必要があるようになったため、PHP 7.0のサポートは廃止されました。これはPHP 7.0をサポートするMoodleの古いブランチに対して同じテストを実行していたサードパーティプラグインのほとんどに影響が生じます。

• • PHPUnit/DBUnitは削除されて、軽い代替システムと置換されました。
  • 多くはアサーション (assertContains(), assertEquals()...) および@expectedExceptionXXXアノテーションで使用されます。再度、これらすべてはPHPUnit 9でエラーとなることに留意してください。
• 最後に課題に関連する変更点の閲覧も良いアイデアです。可能であればコミットメッセージに有用で十分な説明を添えてください。

Moodle 3.7およびそれ以上で動作するよう単体テストをアップグレードする (PHPUnit 7.5)

Moodle 3.7ではPHPUnitが7.5にアップグレードされました (旧バージョンでは6.xが使用されていました)。これはMoodle 3.7 (7.1、7.2および7.3) でサポートされるPHPバージョンとテスト環境の整合性を高めるために実施されました (詳細はMDL-65204およびリンクされた問題をご覧ください)。内部的にはPHPUnit 7で多くのことが変わりました (PHP 7.1らしさ、型付きシグネチャ、 voidリターン、assertEquals()の変更) が我々の wrapping layer (基本および拡張テストケース ...) によって既存のユニットテストへの影響は少なく、アップグレードも簡単になると予想されます。

PHPUnit 7での変更点に関して、以下のリソースをお読みください:

• PHPUnit 7リリースアナウンスメント
• リリースの詳細変更記録です。特に追加、廃止、変更および削除セクションに注意を払ってください。
• 公式PHPUnitマニュアル
• コアに実施された修正点です。主に次のとおりです: new, stricter, signatures (26218b7) および　assertEquals() に関する変更。特にストリングの比較時に重要です。現在、厳格な等号 (===) を使用して実行されます (85f47ba)。

Moodle 3.4およびそれ以上で動作するよう単体テストをアップグレードする (PHPUnit 6)

Moodle 3.4ではPHPUnitが6.4にアップグレードされました (旧バージョンでは5.5が使用されていました)。これはMoodle 3.4でサポートされるPHPのバージョン (7.0、7.1および7.2) およびテスト環境の整合性を高めるためです (詳細はMDL-60611およびリンクされた報告をご覧ください)。内部的には PHPUnit 6で多くが変わりましたが (名前空間付きのクラスはより顕著です) 私たちのラッピングレイヤのおかげで (基本および高度なテストケース ...) 古い既存の単体テストへの影響は少なくなり、簡単にアップグレードもできるようになると思われます。

しかし、特にphpuni のクラスを直接使用している場合、古い (3.4 以前) テストと新しいテスト間で互換性を維持できない場合があります。幸いなことにtravisおよびCIの両テストがこの状況を検出してくれるため、コアでサポートされているすべてのブランチを問題なく通過させるのは難しいことではないでしょう。プラグインの場合、同じブランチが複数のコアブランチに対して動作しようとしていて、それらがphpunitクラスを直接使用している場合、よりやっかいになるかもしれません。

PHPUnit 6での変更点に関して、以下のリソースをご覧ください:

• 良記事 リリースの主要変更点すべてが説明されています。
• PHPUnit 6リリースアナウンスメント
• [https://github.com/sebastianbergmann/phpunit/blob/9d0c024d2099531442d862b66b0ad7cf35ed8e78/ChangeLog-6.0.md

リリースの詳細変更記録]です。特に変更および削除セクションに注意を払ってください。

• コアに実施された修正点です。主に次のとおり: ネームスペースクラスのリネーム (801a372) および廃止予定 (796e48a)

関連情報

• PHPUnitインテグレーション
• PHPUnit