36일차(DI/스프링 컨테이너/테스트 케이스/싱글톤 컨테이너)

🍉DI

DI의 목적

결합도(의존성)를 낮춰 변경에 닫혀있고 확장에 열려있는 유연한 코드를 위해
일반적인 방법, 생성자 주입 방식

결합도를 낮추기 위해 특정 클래스 메서드 사용시 클래스 내부에
클래스 타입의 객체를 통해 사용하지 말고
(구현한)인터페이스 타입의 객체를 통해 사용할 것

DI 방법

필드 주입, setter() 주입, 생성자 주입(권장)

🍉스프링 컨테이너 적용

@AppConfigurer/@Bean

BeanFactory - 빈을 관리하는 최상위 인터페이스
ApplicationContext - BeanFactory의 하위 클래스(보다 부가 기능이 많다)

@Configuration 해당 클래스를 구성정보로 하는 컨테이너를 만든다
@Bean 으로 메서드를 등록한다
@Bean(name="설정이름")으로 별칭 등록 가능, 이름 중복시 오류

getBean("이름", 클래스명.class);또는 getBean(타입.class);로 메서드의 반환된 객체(Spring Bean)를 조회(호출)한다. 구성 정보를 class를 통해서 가져온다
타입에 객체가 여러개일 경우 오류(@Qualifier 또는 @Primary를 사용하여 우선순위를 지정)

실행 결과

관련 메서드

getBeanDefinitionNames() 컨테이너 내의 모든 빈을 배열값으로 리턴,

//각 Bean의 메타정보 조회
AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfigurer.class);			
			
String[] beanNames = applicationContext.getBeanDefinitionNames();
        
for (String beanDefinitionName : beanDefinitionNames) {
BeanDefinition beanDefinition = applicationContext.getBeanDefinition(beanDefinitionName);

if(beanDefinition.getRole() == BeanDefinition.ROLE_APPLICATION) {
   System.out.println("beanDefinitionName" + beanDefinitionName + " beanDefinition = " + beanDefinition);
            }

🍉테스트 케이스 작성

@Test

메서드에 @Test를 사용
@DisplayName를 사용하여 테스트 이름을 붙일 수 있다(출력 화면에 표시)

JUnit

단위 테스트를 위한 오픈 소스 테스트 프레임 워크
src/test 하위 디렉터리에 생성

given(입력) > when(작동) > then(결과 검증)
assertThat()
Assertions 메서드, 파라미터로 테스트 대상을 전달.
반환되는 ObjectAssert 타입 인스턴스를
isInstanceOf() isSameAs() isNotNull() isNotEmpty()를 사용하여 검증

테스트 실패의 예시

기대 값이 다를 때

Expecting actual:
  com.codestates.burgerqueenspring.Cart@63a5d002 //출력 값
to be an instance of:
  com.codestates.burgerqueenspring.Menu //예상 값
but was instance of:
  com.codestates.burgerqueenspring.Cart //결과 값
	at com.codestates.burgerqueenspring.MainTest.findBean(MainTest.java:18)
//코드 위치

빈 값이 없을 때

NoSuchBeanDefinitionException 출력

asserThrows()를 사용하여 Exception 테스트(람다식 사용)

org.assertj.core.api.Assertions;
org.junit.jupiter.api.Assertions;
패키지 구분 주의

🍉싱글톤 컨테이너

싱글톤 미적용

호출 시 마다 새로운 객체 사용 : 메모리 낭비

싱글톤 적용

첫 호출 이후로 기존 객체 반복 사용

스프링 컨테테이너는 기본적으로 인스턴스를 싱글톤으로 관리
기존 메서드의 리턴값이 return new ... 라도 getBean() 으로 불리는 객체는 이럴수가! 동일한 주소값으로 나온다.