はい、プロダクションコードと同じようにアプリケーションコンテキストを読み込んだJUnitテストクラスを作成し、プロパティ値が注入されたことを検証するテストメソッドを実行できます。この例MyServiceBean.java
で
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = {AppConfig.class})
public class SpringApplicationTest {
@Autowired
private MyServiceBean serviceBean;
@Test
public void shouldExecuteServiceBean_andProduceExpectedOutcome() {
//TODO test setup
serviceBean.doSomething()
//TODO assert output
}
}
あなたは春の依存性の注入のすべてを含め、アプリケーションのエンド・ツー・エンドのロジックをテストしているように、あなたのMain
クラスから実行されますクラスです。それをあなたの「幸せな道」のテストシナリオと考えてください。私は春の注入のすべてが正しいことを確実にし、間違いなくロードするために、常にこのような少なくとも1つのテストを私のプロジェクトに含めます。コードをビルドしてデプロイする前に、エラーをキャッチすることはできません。
上記の例では、AppConfig.java
は、コードのデプロイ時に使用するのと同じSpring構成クラスです。おそらく、テスト専用にいくつかのプロパティー/ Beanをオーバーライドする別の構成クラスを追加することをお勧めします。テストクラスのみを使用して
@ContextConfiguration(classes = {AppConfig.class, TestConfig.class})
、あなたは(すなわちin-memory databaseを使用)検査を困難にする任意の依存関係をモック、またあなたが、むしろこれかもしれないまたは5月他のサービスよりも、「localhost」をに対してテストできるようにプロパティをオーバーライドすることができますテストセットアップで同等のlocalhostサービスを作成できる場合は、使用できません。
注:あまりにも多くの依存関係や外部の依存関係が簡単に取り除かれないためにアプリケーションをテストすることが困難な場合は、気分が痛くなります。テストの容易さをサポートするアーキテクチャ上記の概念を使用して、アプリケーションの一部だけをテストすることもできます。
'spring-boot-starter-test'を確認しましたか? – sfat
しかし、あなたはなぜあなたのbussinessロジックの春のフレームワークinsteedをunittestしたいと思いますか私には謎です – Antoniossss