2016-08-14 4 views
1

すべてここでは、検索で少しの洞察が得られていないという問題があります。私はこれが大きなデータフレームワークに対して開発しているすべての人にとってかなり一般的な問題であるべきだと思うが、100%のテストカバレッジも求めている。だから、ここで質問を投稿して、最高のコミュニティ応答&アイデアを集めようとします。Scala/Sparkでの静的メソッドとコンストラクタの傍受

我々は100%のテストカバレッジを取得するには、外部APIオブジェクト

class SolrClientWrapper { 
    def doWork() = { 
     val cli = new CloudSolrClient("zkHost1") 
     ??? 
    } 
} 

をインスタンス化するクラスをモックする必要があるシナリオを検討して、実際にユニット中にすべての回でアップするのSolrサーバに依存せずテストの場合、new CloudSolrClientへの呼び出しを傍受する方法があります。私の知る限りでは、利用可能な唯一のライブラリはここでPowerMock

あるツイスト PowerMockおよびその他のモックライブラリは、依存関係としてasmが必要ですが、複雑なフレームワークスパークプロジェクトもasmを必要としています。バージョンの競合があり、したがって(テスト)ランタイム・ヘルがあります。

この状況で最も優れたデザインリファクタ/ライブラリは何ですか?

答えて

1

SolrClientWrapperクラス内に新しいCloudSolrClientオブジェクトを作成する代わりに、依存関係として渡す必要があります。あなたのテストでは、実際のオブジェクトの代わりにモックを渡すことができます。依存関係を簡単に管理できるような依存性注入フレームワークとメカニズムが多数あることに注意してください(例えば、それらを自動的にインスタンス化してコンストラクタに渡すなど)。

asmはわかりませんが、あなたが掲示したコードは、クラス本体内のものをインスタンス化するコードの一部を削除すると、そのような依存関係なしで簡単にテスト可能でなければなりません(したがって、何かを傍受する必要があります)。

+0

私は依存性注入が正しいパターンであることに絶対に同意します。しかし、どのようにスパーク・ジョブのコンテキストでそれをお勧めしますか?例えば、伝統的にスパークジョブは、スパークコンテキストなどをメインから作成する必要があります。 – echen

+0

実際のコンテキストを使用すると何が問題になりますか? 「前」ブロックにスパークコンテキストを作成し、テストで使用します。あなたが何かを傍受する必要がないので、これは大丈夫です。 [this](http://mkuthan.github.io/blog/2015/03/01/spark-unit-testing/)または[this](http://blog.cloudera.com/blog/2015/09)を参照してください。/make-apache-spark-testing-easy-with-spark-testing-base /)を実行します。しかし、あなたの 'CloudSolrClient'には依存関係として使うべきです。 – slouc

+0

それは良い点ですが、私はこれらをもう少し詳しく調べなければなりません。フレームワークの概念/アプリケーションロジックとサードパーティのソース/シンクプロバイダのアーキテクチャと依存関係のグラフについて若干の再考をもたらします。 – echen

関連する問題