[Spring] 0714 정리

## 테스트

• DataSource 인터페이스의 getConnection() 메서드로 DB 커넥션을 불러올 수 잇음.
• 단위테스트 -> 기능 단위로 테스트. 단위가 작을수록 좋음
• 테스트 주도 개발 (TDD) -> 테스트 우선 작성 후 코드를 작성하는 개발 방식. 이렇게 하게 되면 코드 작성 후 테스트가 빨라지고 테스트 코드를 먼저 작성하기 때문에 모든 코드들이 테스트됨.
• JUnit -> @Test 가 붙은 메서드가 실행될때마다 새로운 오브젝트를 생성하고 메서드가 종료되면 소멸시킴.
• Fixture -> 테스트를 수행하는데 필요한 정보나 오브젝트
• @BeforeClass -> 테스트 클래스 전체에 걸쳐 한번만 실행되는 스태틱 메서드
• SpringTestContextFramework -> 동일한 ApplicationContext를 테스트 메서드 심지어 클래스간에도 공유하게 해줌.
• @RunWith(SpringJUnit4ClassRunner.class) -> SpringTestContextFramework의 JUnit 확장 기능을 지정하는 어노테이션
• @ContextConfiguration -> TestContextFramework가 자동으로 만들어줄 애플리케이션 컨텍스트의 위치를 지정
• ApplicationContext는 초기화될때 자기 자신도 bean으로 등록함
• @Autowired -> 타입에 맞는 빈을 찾고 만약 해당 타입의 빈이 여러개 잇다면
  변수명에 맞는 빈을 DI함. 그마저도 없다면 에러 던짐
• 인터페이스를 두고 DI를 적용해야 하는 이유
  개발에서 절대 바뀌지 않는 것은 없음.
  다른 차원의 서비스 기능 도입 가능
  효율적인 테스트를 손쉽게 만들기 위함
• @DirtiesContext -> 테스트 메서드에서 애플리케이션 구성 혹은 상태를 변경한다는 것을 TestContextFramework에게 알려줌.
  이 어노테이션이 붙은 클래스에는 ApplicationContext의 공유를 허용하지 않음
  메서드에도 붙힐 수 잇음.
• 테스트를 위한 applicationContext.xml 을 별도로 만드는게 좋음
• 침투적 기술 -> 애플리케이션이 기술에 종속됨
• 비침투적 기술 -> 애플리케이션 로직을 담은 코드에 아무런 영향을 주지 않고 적용 가능 (대표적으로 스프링 프레임워크)
• 테스트하기 좋은 코드가 좋은 코드다.

템플릿

• Connection 과 PreparedStatement 는 Pool 방식으로 운영됨
  서버환경에서 pool에 미리 만들어둔 리소스를 돌려가며 사용
  close() 로 리소스를 반환해줘야함. 안그럼 리소스가 소진됨

• 중첩클래스
  Static Class 안에 Inner Class 가 잇음
  InnerClass 는 필드처럼 선언되는 member inner,
  메소드 안에 선언되는 local calss,
  또 익명 내부 클래스가 잇다.

• 콜백 -> 실행되는 것을 목적으로 다른 오브젝트의 메소드에 전달되는 오브젝트

• 전략 패턴을 적용해야 할때 -> 일정한 흐름이 반복되면서 그 중 일부 기능만 바뀌는 코드가 있을때

• 템플릿/콜백 ->
  출처 : https://vvhiteboard.github.io/web/2017/09/25/toby-spring-chapter3_3/

  ---

  예외

• 자바의 예외 종류
  
  출처 : https://www.manishsanger.com/java-exception-hierarchy/

• Error -> 주로 JVM에서 발생시키는 시스템 에러.

• RuntimeException -> 프로그램의 오류가 있을때 발생.

• Exception(checked) -> 컴파일시 처리

• JdbcTemplate -> SQLException 을 DataAccessException 으로 포장후 의미에 따라 서브클래스인 BadSqlGrammarException, DuplicatedKeyExceptiom 등으로 처리해줌

• 예외 정리

1. 예외로 잡아서 아무런 조치도 취하지 않거나 의미없는 throws를 남발하는것은 위험하다.
2. 예외는 복구하거나 예외 처리 오브젝트로 의도적으로 전달하거나 적절히 전환해줘야함.
   (좀더 의미 있는 예외로 전환하거나 try catch를 피하기 위해 런타임 예외로 전환)
3. 복구할 수 없는 예외(ex SQLException) 은 가능한 한 빨리 런타임 예외로 전환해주자.
   4.애플리케이션의 로직을 담기위한 예외는 체크 예외로
4. SQLException의 에러코드는 DB에 종속되기 때문에 DB에 독립적인 예외로 전환될 필요가 있음.
5. 스프링은 DataAccessException을 통해 DB에 독립적인 추상화된 런타임 예외 계층을 제공한다.