シングルトンをクラスに置き換える際に潜在的な問題はありますか？

Question

私は現在、Scalaプロジェクトに取り組んでおり、シングルトンオブジェクトを広範囲に使用するコードのテストが困難になっています。

私はこのようなシングルトンいます

object SomeSingleton { 
    def someFunction(s: String): String = s + "b" 
} 

そしてどこかに私はそれがテストに私が欲しいの方法での使用だ持っているプロジェクトで：

val s = SomeSingleton.someFunction("a") 

私は新しい機能を開発し、私はSomeSingleton.someFunctionをしたいです実際のメソッドコールを使わずにテストで特定の値を返すと、私はPowermockを使ってJavaでこれを行いましたが、Scalaでこれを行う方法を見つけることに失敗しました。 私はまだこれを行うことができますどのようにアイデアを持っているが、それはこれに元のコードを変更すること意味します

object SomeSingleton extends SomeSingletonClass{} 

class SomeSingletonClass { 
    // Whole logic from SomeSingleton moves here 
    def someFunction(s: String): String = s + "b" 
} 

は今、私はSomeSingletonClassでSomeSingletonの使用を置き換えることができますし、それを適切に模擬します。だからここに私の懸念がありますが、プロジェクトは小さくはない、それは100％テストの対象ではなく、私はScalaにとって比較的新しいので、私はそれがもたらす可能性のある悪影響があるかどうかはわかりません。それは実行可能な解決策ですか？私はこれのために、私のレガシーコードがいくつかのランダムな場所で壊れないようにします。

Answer 1

あなたが持っているもの（シングルトンがたくさんあるレガシーコード）を考えれば、あなたの解決策はおそらく大丈夫だと思います。私はここで私の思考のいくつかを共有したいと思います。

1. はい、SomeSingletonClassクラスをモックを支援するクラスが、それの欠点を導入することは、もはやシングルトンだということではありません。私は簡単にval newSingleton = new SomeSingletonClass()をやることができますし、私は新しいオブジェクトを作成しました。シングルトンをテストする最良の方法は、シングルトンを直接テストすることです。私はあなたのシングルトンがもっと多くの他のシングルトンを呼び出すだろうと思うし、これらの副作用のすべてを実行したくない。しかし、問題を適切に解決するには、コードを大幅にリファクタリングする必要があります。

2. PowerMockは、Javaの非常に強力なモッキングツールです（多すぎるパワー）。静的メソッド/シングルトンをモックする方法は、バイトコードを変更することです。それはほとんどの場合に機能しますが、そうでない場合は、どうやって修正するか分かりません。 Amazonでの私の以前の仕事では、PowerMockを広範囲に使用していましたが、ブラックボックスの魔法のためにゆっくりと離れています。依存性注入を使用することを達成するのに役立つ方法の1つで、テストにモックオブジェクトを簡単に注入することができます。

3. 従来のコードを扱っていることがわかります。たとえば、依存性注入や、ここで試している新しいSomeSingletonClassなど、すべてを書き直すのは簡単ではありません。私の提案は、おそらくレガシーコードのテストを書くのにあまりにも多くの時間を費やすべきではないということです。代わりに、新しいコードを書くときには、それをテスト可能にし、レガシーコードをリファクタリングするようにしてください。