他のクラスが渡されたクラス(依存関係注入)をテストしようとしていますが、これはクラスプロパティとして格納されています。 (たとえば、ファクトリの結果である設定クラス)。phpunitテストはどのような順序で実行されますか?
ので、擬似コードでは、これは私が取り扱っておりますものです:今
//Get settings for this user.
$settings = SettingsFactory::GetSettings();
//Create widget that uses settings
$widget = new Widget($settings);
、明らかに、我々はコードをリファクタリングしてSettingsFactory壊れた場合:: Getsettings()、ウィジェットのコンストラクタは失敗します。しかし、必ずしもウィジェットに何か問題があるためではありません。
したがって、「初期」テストが失敗したときに「後で」テストをスキップして、これらのコンポーネントを順番にテストします。
は、テストのために私の現在の構造を考えてみましょう:
tests\vendor\Settings\SettingsTest.php
tests\vendor\Widget\WidgetTest.php
PHPUnitのは意味があるだろうWidgetTest.phpを実行する前にSettingsTest.phpをテスト(すべてが合格してい)する必要があります。
私は@dependsを使う必要があると思いますが、それは単一のクラススコープに限られているようです。
This questionパズルの一部を保持しているようですが、実装する方法がわかりません。
これらのテストをどのように記述(構造化)しますか?
これは本当ですが、ここに私の問題だ:これはあなたの設定の実装の詳細を気にせず、ウィジェットの真のユニットテストを与えますまたはPHPUnit)...設定に依存する3つのクラスがある場合、それらのクラス/テストのそれぞれの設定を模擬しなければなりません。さて、設定を更新して機能を変更したら、すべてのテストに戻って変更する必要があります。私は1つの場所でそれを変更し、多くのテストでそれを有用にすることができるはずです。 – DrDamnit
ユニットテストは独立していなければなりませんので、ここでは悪いことを強制しようとしています。広く使われているクラス*のインタフェースを変更することは、そのインタフェースに依存するので、依存するクラスのテストに大きな影響を与えるはずです。広く再利用されている場合は、再利用可能なモック/スタブを作成したり、設定ファクトリをtry/catchでラップしたり、テストをスキップしたりすることができます。 – cmbuckley
OK、聞いています。つまり、あるテストから別のテストにコードをコピー/ペーストするのが一般的な方法です。コードの臭いかもしれないと思った...?実際のコードベースであれば、それがリファクタリングされるからです。ユニットテストではそうではありませんか? – DrDamnit