일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- springboot
- Kafka
- spring-cloud-stream
- reactive
- aws
- scala
- spring-kafka
- Logstash
- statestore
- kafkastreams
- confluent
- 카프카
- avo
- play framework
- gradle
- kafka streams
- Elk
- coursera
- kafkastream
- 플레이 프레임워크
- kafka interactive query
- scala 2.10
- RabbitMQ
- Slick
- Elasticsearch
- Spring
- schema registry
- 한빛미디어
- enablekafkastreams
- spring-batch
- Today
- Total
b
springboot 2.0 에서 ApplicationContextRunner 테스트 본문
https://spring.io/blog/2018/03/07/testing-auto-configurations-with-spring-boot-2-0 지지난주 spring.io 에 올라온 글이다.
스프링부트 2.0에 ApplicationContextRunner 가 추가 되었고 이에 대한 사용법을 설명하는 내용인데, 실제로 활용해보니 기존의 static class 로 Spring 설정을 slicing 하는 것보다 가독성도 좋고, 사용도 편하다.
1. SolMailAutoConfiguration 빈을 생성할때 JSR380에 의해 validate한지 확인하는 테스트
new ApplicationContextRunner()
.withConfiguration(of(SolMailAutoConfiguration.class))
.run((context) -> {
assertThat(context.getStartupFailure())
.isNotNull();
assertThat(context.getStartupFailure())
.isInstanceOf(UnsatisfiedDependencyException.class);
});
2. SolMailAutoConfiguration 빈을 생성 할 때 제대로 값이 주입되는지 확인하는 테스트
new ApplicationContextRunner()
.withConfiguration(of(SolMailAutoConfiguration.class))
.withPropertyValues(
"app.sol.mail.connection-timeout:10000",
"app.sol.mail.api-url:http://localhost/api/v1/sol/"
).run((context) -> {
SolMailProperties properties = context.getBean(SolMailProperties.class);
assertThat(properties.getApiUrl()).isEqualTo("http://localhost/api/v1/sol/");
assertThat(properties.getConnectionTimeout()).isEqualTo(10000);
});
3. 커맨드라인이나, 프로퍼티로 값을 받을때 원하는 Bean이 로드 되는지 확인하는 테스트
new ApplicationContextRunner()
.withInitializer(new ConfigFileApplicationContextInitializer())
.withConfiguration(of(FakeMailClient.class, SolMailAutoConfiguration.class))
.withPropertyValues("mail.type=fake")
.run((context) ->
assertThat(context).hasSingleBean(FakeMailClient.class));
legacy 에서는 initializers = ConfigFileApplicationContextInitializer 라고 initializers 를 정의해서 썻지만 이렇게 코드 레벨에서 사용할 수 있다.
ApplicationContextRunner 를 before로 올려서 DRY를 준수할 수도 있지만, 그렇게 올려서 얻는 중복 코드의 제거보다, 지금 처럼 각각 초기화 하는게 더 나은 가독성과 사용성을 주는 것 같아서, 위처럼 작성함 이게 대한 좋은 글로
https://stackoverflow.com/questions/6453235/what-does-damp-not-dry-mean-when-talking-about-unit-tests