2016-06-27 32 views
1

他のクラスが渡されたクラス(依存関係注入)をテストしようとしていますが、これはクラスプロパティとして格納されています。 (たとえば、ファクトリの結果である設定クラス)。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パズルの一部を保持しているようですが、実装する方法がわかりません。

これらのテストをどのように記述(構造化)しますか?

答えて

1

DIの大きな利点の1つは、あなたが望むように動作するモック$settingsオブジェクトを注入することで、このような問題を回避できることです。コードの問題よりも、私は問題を考えていますどのように多くの可能性が高い(

$mockSettings = $this->createMock(Settings::class); 
$mockSettings->method('someMethod')->willReturn('something'); 
$widget = new Widget($mockSettings); 

// assertions here 
+0

これは本当ですが、ここに私の問題だ:これはあなたの設定の実装の詳細を気にせず、ウィジェットの真のユニットテストを与えますまたはPHPUnit)...設定に依存する3つのクラスがある場合、それらのクラス/テストのそれぞれの設定を模擬しなければなりません。さて、設定を更新して機能を変更したら、すべてのテストに戻って変更する必要があります。私は1つの場所でそれを変更し、多くのテストでそれを有用にすることができるはずです。 – DrDamnit

+0

ユニットテストは独立していなければなりませんので、ここでは悪いことを強制しようとしています。広く使われているクラス*のインタフェースを変更することは、そのインタフェースに依存するので、依存するクラスのテストに大きな影響を与えるはずです。広く再利用されている場合は、再利用可能なモック/スタブを作成したり、設定ファクトリをtry/catchでラップしたり、テストをスキップしたりすることができます。 – cmbuckley

+0

OK、聞いています。つまり、あるテストから別のテストにコードをコピー/ペーストするのが一般的な方法です。コードの臭いかもしれないと思った...?実際のコードベースであれば、それがリファクタリングされるからです。ユニットテストではそうではありませんか? – DrDamnit

関連する問題