タグ付けされた質問 「integration-test」

これまでのところ、Magento 2のテストニーズに合わせて、PHPユニットを（多少なりとも）受け入れテスターとして使用してきました。サーバーの結果をテストし、モジュールがインストールされたシステムにHTMLリクエストを送信しました。独自の統合テストを作成できるようにします。Magento 2に同梱されているテストツールを使用すると、サードパーティの開発者は、Magentoのテストフレームワークコードを活用する独自の統合テストを作成できますか？それとも、私たち全員が独自のブートストラップを展開しますか？ あれは 私はMagentoの開発者です 統合テストを作成したい 統合テストでは、Magento環境を完全にブートストラップして再生します（使用するオブジェクトマネージャーや依存関係の注入など）。 統合テストでテストを拡張しMagento\TestFramework\TestCase\AbstractControllerて、Magentoテストと同じヘルパーを使用したい テストを他のテストスイートから分離して実行できるようにしたい（つまり、15秒のテストを実行するのに2時間待つ必要がない） Magentoのテストとは別にテストを保存したい dev docsサイトにはテストに関するいくつかのスターター記事がありますが、Magentoに同梱されているテストを実行することを目的としており、独自のテストを作成して実行することはしていません。古いサンプルモジュールがありますが、それらはすべてPHPUnit_Framework_TestCaseクラスを拡張し、単体テスト（つまり、Magentoフレームワークに依存しないコードのテスト）のようです。 これを行うMagento提供の方法はありますか？ そうでない場合、Magento開発者コミュニティのテストがそれを標準として採用できるように、誰かが独自のセットアップを展開しましたか？

27 php  magento2  phpunit  integration-test 

構成セクションの統合テストを作成しているときに、デフォルトのテストケースで次のエラーが発生しました。 My\Module\ConfigTest::testAclNoAccess Failed asserting that 302 is identical to 403 私の知る限り、すべてが正常に機能しますが、Magentoは、構成セクションでアクセスが拒否されたときに、「禁止」ではなくリダイレ​​クト応答を送信します。 テストを変更して302ステータスコードを期待するのは理にかなっていますか？このテストケースは、間違ったリソース識別子をキャッチするのに既に役立っているので、削除しないほうがよいでしょう。 これは関連するコードです： namespace My\Module; use Magento\TestFramework\TestCase\AbstractBackendController; class ConfigTest extends AbstractBackendController { protected function setUp() { parent::setUp(); $this->uri = 'backend/admin/system_config/edit'; $this->resource = 'My_Module::config_my_module'; $this->getRequest()->setParam('section', 'my_module'); } // [other tests] }

10 magento2  testing  acl  magento-2.0.2  integration-test 

コアモジュール用に作成された統合テストを見ると、@magentoDbIsolation enabledテスト関数の上に注釈のインスタンスが多数表示されています。 MTFのドキュメントのどこにもこれについての言及はありません。また、調べMagento\TestFramework\Annotation\DbIsolationても、その目的についてはまだはっきりしていません。 誰かが洞察を提供できますか？ありがとう。

9 magento2  integration-test 

Magento 2の統合テストをたくさん書いています。これは私のローカル開発に役立ち、CIの作業方法にうまく適合します。 ただし、Magentoの統合テストスイートにはいくつかの奇妙な点があります。例えば： デフォルトですべてのモジュールを有効にしますが、これを無効にする方法はありません。クライアントプロジェクトでは、Vertexモジュールなどの不要なモジュールを無効にする可能性が高いため、これには望ましくない副作用が生じる可能性があります。ただし、このモジュールは顧客モデルに必須フィールドを追加するため、統合テストで顧客を作成すると、このテストは失敗します。 Magentoテストモジュールをコードベースに追加します。したがって、統合テストスイートを実行するたびに、app/code/Magento名前空間に3つの追加モジュールが存在することになります。 これらの問題により、統合テストをローカルプロジェクトで使用することが困難になっています。誰かがかつて、統合テストは拡張モジュールの開発者がモジュールを市場に出すための基準を満たしているかどうかをテストするためにのみ作成されると私に言った。これは本当ですか？もしそうなら：あなたのクライアントのウェブショップのための統合テストを書くための適切な方法は何ですか？Magentoの注釈などが好きです。これは本当にイライラします。

8 magento2  testing  integration-test 

次のシナリオを想定します。 外部サービスを呼び出すクラスがあります クラスはインターフェースを実装し、このインターフェースの優先実装として di.xml ブロックは、コンストラクター・パラメーターとしてこのインターフェースを受け取ります このブロックを使用する統合テストでMagentoリクエストをテストしたい 私は実際に外部サービスを呼び出したくないので、そのクラスをモックして、それを行うための最良の方法は何だろうと思います。 私はあなたがオンザフライでDI設定を定義できることを知っています $objectManager->configure( ['preferences' => [TheInterface::class => MockClass::class]] ); しかし、これにはMockClass自分でモッククラスを定義する必要があります。PHPUnitモックオブジェクトを使用できません。 実際のモックオブジェクトを作成するモックファクトリを作成できるため、注入されたクラスがファクトリの場合、これは問題なく動作します。 しかし、これが唯一の方法ですか、それとも私は何かを逃していますか？ 更新： 提案された方法 $objectManager->addSharedInstance($mock, TheInterface::class); 最初は見栄えが良かったが、設定が定義されていない場合にのみ機能した。これらは共有インスタンスよりも優先されます。 私は動的に設定を削除しようとしました： $this->objectManager->configure( ['preferences' => [TheInterface::class => null]] ); しかし、残念ながらMagentoはltrim($to, '\\')引数を呼び出し、それが空の文字列に変換します。これは結果として： ReflectionException：クラスが存在しない

8 magento2  testing  dependency-injection  integration-test