1. 성공 테스트 테스트할 코드가 성공해야하는 경우, 제대로 로직이 실행되는지 확인하기 위해서 Assertions.assertThat() 을 활용한다. 1) assertThat(actual).isEqualTo(expected): 실제값(actual)이 기대값(expected)와 같은 값인지 검증 2) assertThat(actual).isInstatceOf(expected): 실제값(actual)이 기대값(expected)와 같은 객체 타입인지 검증 2. 실패 테스트 테스트할 코드가 실패해야 경우, 예외가 제대로 발생하는지 확인하기 위해서 Assertions.assertThrows() 을 활용한다. 1) assertThrows(예외 타입, 람다식): 오른쪽 람다식을 수행했을 때, 해당 예외 타입의 예외가..
(인프런) 김영한님의 스프링 핵심 원리-기본편을 공부하고 리뷰한 글입니다. 5. 스프링 빈 조회(상속 관계) 부모 타입도 조회하면 자식 타입도 함께 조회된다! 모든 자바 객체의 최상위 클래스인 Object 타입으로 조회하면 모든 스프링 빈을 조회한다. 1. ApplicationContextExtendsFindTest 예제 코드 package hello.core.beanfind; import hello.core.discount.DiscountPolicy; import hello.core.discount.FixDiscountPolicy; import hello.core.discount.RateDiscountPolicy; import org.junit.jupiter.api.DisplayName; import ..
(인프런) 김영한님의 스프링 핵심 원리-기본편을 공부하고 리뷰한 글입니다. 4. 스프링 빈 조회(동일한 타입이 둘 이상) ac.get(타입)으로 조회할 때, 같은 타입의 스프링 빈이 둘 이상이면 NoUniqueBeanDefinitionException 예외가 발생한다. 이럴 경우, 1) ac.get(빈 이름, 타입) 으로 1개의 빈을 조회한다. 2) ac.getBeansOfType() 으로 해당 타입의 모든 빈을 조회한다. 1. ApplicationContextSameBeanFindTest 예제 코드 package hello.core.beanfind; import hello.core.member.MemberRepository; import hello.core.member.MemoryMemberReposi..
(인프런) 김영한님의 스프링 핵심 원리-기본편을 공부하고 리뷰한 글입니다. 3. 스프링 빈 조회(기본) 1) ac.getBean(빈 이름, 타입): 빈 이름&타입으로 빈 조회 2) ac.getBean(타입): 타입으로만 빈 조회 조회 대상 스프링 빈이 없으면 NoSuchBeanDefinitionException 예외 발생! 1. ApplicationContextBasicFindTest 예제 코드 package hello.core.beanfind; import hello.core.AppConfig; import hello.core.member.MemberService; import hello.core.member.MemberServiceImpl; import org.junit.jupiter.api.Disp..
(인프런) 김영한님의 스프링 핵심 원리-기본편을 공부하고 리뷰한 글입니다. 1. 스프링 컨테이너 생성 ● ApplicationContext = 스프링 컨테이너 1) XML 기반으로 생성 2) 애노테이션 기반의 자바 설정 클래스로 생성 - AppConfig를 사용한 방식 -> 주로 사용하는 방식 // 스프링 컨테이너 생성 ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class); ApplicaionContext = 인터페이스 AnnotationConfigApplicaionContext 클래스 = ApplicationContext 인터페이스의 구현체 (참고) 스프링 컨테이너는 1) BeanFac..
[백준] 7579번 - 앱 (한줄평) 전에 풀었던 냅색 문제를 잘 이해했다면 어렵지 않게 해결핧 수 있었던 문제. 하지만 더 좋은 풀이를 생각해봐야할 문제로 다음에 다시 한번 풀어보면 좋을 것 같다. 유사 문제: 12865 https://hseungyeon.tistory.com/search/%EB%83%85%EC%83%89 공부 hseungyeon.tistory.com 앱의 개수가 N, 필요한 메모리가 M일 때, 둘째 줄의 N개의 정수는 현재 활성화 되어 있는 앱 A1, ..., AN이 사용 중인 메모리의 바이트 수인 m1, ..., mN을 의미하며, 셋째 줄의 정수는 각 앱을 비활성화 했을 경우의 비용 c1, ..., cN을 의미한다 (단, 1 ≤ N ≤ 100, 1 ≤ M ≤ 10,000,000이며,..
(인프런) 김영한님의 스프링 핵심 원리-기본편을 공부하고 리뷰한 글입니다. 8. Ioc, DI, 그리고 컨테이너 1. 제어의 역전: Ioc(Inversion of Control) 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전(IoC)라 한다. 1) 기존 프로그램 기존 프로그램은 구현 객체가 프로그램 제어 흐름을 스스로 제어했다. - 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성, 연결, 실행 했다. 2) AppConfig 등장 AppConfig의 등장 후, 구현 객체는 자신의 로직을 실행하는 역할만 담당하고 프로그램의 제어 흐름은 AppConfig가 가져간다. - OrderServiceImpl은 필요한 인터페이스를 호출하지만 어떤 구현 객체들이 실행될..
(인프런) 김영한님의 스프링 핵심 원리-기본편을 공부하고 리뷰한 글입니다. 5. 새로운 구조와 할인 정책 적용 정액 할인 정책을 정률 할인 정책으로 변경한다. FixDiscountPolicy → RateDiscountPolicy AppConfig의 등장으로 애플리케이션이 크게 사용 영역 & 객체를 생성하고 구성하는 영역으로 분리되었다! 1. 그림 - 사용, 구성의 분리 2. 그림 - 할인 정책의 변경(중요!) FixDiscountPolicy → RateDiscountPolicy 로 변경해도 구성 영역만 영향O, 사용 영역은 영향X 3. 할인 정책 변경 구성 코드 public class AppConfig { // MemberService 역할(생성자 주입) public MemberService member..
