2

会社のソフトウェア製品の新しいアーキテクチャを設計しています。私はユニットテストにかなり慣れていません。シングルトンと静的メソッドの使用に関するいくつかの恐ろしい話を読みましたが、それらを使用する際の問題を明確に理解していないため、いくつかの啓発をいただければ幸いです。

これが私がやっていることです：

私は多層アーキテクチャを持っています。サーバー側のレベルでは、「ハンドラー」と呼ばれる一連の再利用可能なオブジェクトを使用して、データベース テーブルを表しています。これらのハンドラーは、XMLObjects、XMLTables、さまざまなデータ構造などの他のオブジェクトを使用します。これらのほとんどは自家製であり、事前にパックされたオブジェクトではありません。とにかく、この層の上には疑似シングルトン層があります。これの主な目的は、より高いレベルのサーバー側コードを簡素化し、シームレスなクラス管理を作成することです。私は言うことができます：

$tablehandler = databasename::Handler('tablename')

...テーブルを取得します。これに固有の問題は見当たりません。ハンドラーのスタック (連想配列) を使用して、さまざまなオブジェクトのインスタンスを格納しています。私はグローバルを使用しておらず、すべての静的データメンバーは保護またはプライベートです。私の質問は、これが単体テストでどのように問題を引き起こす可能性があるかです。私は時流のレトリックを探しているのではなく、因果関係を探しています。また、これに関する他の洞察もいただければ幸いです。現時点では、非常に柔軟で効率的なアーキテクチャのように感じます。ここで何か助けていただければ幸いです。

4

1 に答える 1

4

マネージド インスタンスへのアクセスを提供するために静的メソッドを使用すること (シングルトン、プールされたオブジェクト、オンザフライ インスタンスのいずれであっても) は、テストが独自のモックを挿入する方法を提供する限り、テストの問題ではありません。必要に応じてスタブを作成し、完了したら削除します。あなたの説明から、その能力を妨げるものは何も見えません。必要なときにそれを構築するのはあなた次第です。

拡張ポイントやインスタンスを介さずに作業を行うメソッドを静的に呼び出すクラスがある場合、問題が発生します。たとえば、このような呼び出し

UserTable::findByEmail($email);

モック、メモリのみのテーブルなどをプラグインできないため、テストが困難になります。ただし、次のように変更します。

UserTable::get()->findByEmail($email);

UserTable::set($mock)テストがセットアップ コードを呼び出すことができるため、問題が解決されます。より詳細な例については、この回答を参照してください。

于 2012-10-04T04:29:52.273 に答える