メソッドがあるとしましょう：
someMethod(X anObject)
ここで、X は非常に複雑なタイプのオブジェクトです。これは、その場で簡単にインスタンス化できるものではないことを意味します。何らかの方法で単体テストを行う必要がありますが、パラメーターとして入れる X オブジェクトを単純に作成することはできません。
だから私は最初にオブジェクトをモックしようと思いますが、私が遭遇する問題は someMethod 関数が anObject の多くのメソッドを呼び出すことです。モック期待する必要があります。さらに悪いことに、呼び出されたこれらの X オブジェクト メソッドは、より多くの X オブジェクトを返します。つまり、オブジェクトをモックする必要があり、モック メソッド呼び出しを期待して、より多くのモック オブジェクトを返す必要があります。
このシナリオに関して、私は単体テストの概念が初めてなので、いくつか質問があります。
- 長い単体テスト メソッドはさておき、私の単体テストは、メソッドが機能するかどうかをテストするだけでなく、実装を指定することでもあることがわかりました (基本的に、メソッド自体で呼び出されるほとんどのコードを指定しているため)。モック期待で）。これは問題ですか (ほとんどの場合、ユニット テスト自体の概念に問題があります)。
- これを回避する方法はありますか? 単体テスト メソッドの冗長性を大幅に軽減し、保守性を高めるためだけでも、何か方法はありますか?
- 別の場所からシリアル化された X オブジェクトを取得して保存し、単体テスト メソッドを呼び出すたびに、X オブジェクトのシリアル化を解除して、それをパラメーターとして実行することを考えました。これは、私が頭のてっぺんに思いついたランダムなアイデアです。誰かが実際にこれを行いますか？
私が正確に何をしているのか疑問に思っている人のために、IDebugContextListenerインターフェイスを使用して、Java デバッガーの特定のステップでスタックフレームのデータに関するデバッグ情報を取得しています。ここで言及している「X」は、IValue、IVariable、IStackframe などのオブジェクトを含む、ここでインターフェイスによって定義されるオブジェクトです。これらの変数はすべて、実行時に Java デバッガーによって提供されます。