Spring の @Autowired 機能を使用して、テスト クラスまたはフィクスチャで SUT (System Under Test) または CUT (Class Under Test) のインスタンス化と注入を Spring フレームワークに任せる開発者を見てきました。以下は、テスト フィクスチャで使用されている @Autowired を示すスニペットです。
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.annotation.ExpectedException;
import org.springframework.test.context.testng.AbstractTestNGSpringContextTests;
import org.springframework.test.context.ContextConfiguration;
interface BackingStore
{
//Some methods
}
class Logger
{
public Logger(BackingStore backingStore)
{
//Capture input parameter into member variables
}
public void Log(String message)
{
//Some logic
}
}
@ContextConfiguration(locations = { "classpath:someconfig.xml" })
public class LoggerTests extends AbstractTestNGSpringContextTests
{
@Autowired
private Logger _logger;
@Test
@ExpectedException(NullPointerException)
public void Log_WhenPassedNull_ShouldThrowException()
{
_logger.Log(null);
}
}
SUT が (再帰的に) 必要とするすべての依存関係は、Spring 構成 XML ファイルの一部として指定されます。私はこのアプローチが好きではありません。私はすべてのテスト (ユニットまたは統合) を物語のように読むのが好きです (Kent Beck が同じことを言っているのを聞きました :))。たとえそれが複雑であっても、テストケース自体で SUT/CUT をインスタンス化するのが好きです。これにより、テスト ケースの全体像が明確になります。
テスト フィクスチャに SUT を挿入するために使用されている @Autowired または自動挿入メカニズムについては、ほとんど懸念がありません。
テストコードの可読性が低下します。@Autowire は魔法のように見えます。AAA (Arrange-Act-Assert) のアレンジは、テストコードから XML ファイルに移動します。
テスト コードの保守性が低下します。これは#2のためです。
例外的なケースで例外をスローする SUT/CUT のコンストラクターを効果的に検証できませんでした。これについては 100% 確信が持てません。Spring フレームワークがこれに対する答えを持っているかどうかはわかりません。
単体テストまたは統合テストにはやり過ぎのようです。
この件について専門家に 2 セントを請求します。
ありがとう。