JDBC

H2 데이터베이스

MacOS는 H2 설치 뒤 권한을 주어야 제대로 실행된다.

  1. H2 다운 뒤 압축을 푼 폴더로 들어간다.

  2. h2/bin 으로 들어가면 h2.sh 가 있다.

  3. chmod 755 h2.sh 를 실행한다.

  4. ./h2.sh로 h2를 실행하면 아래와 같은 경로로 접속할 수 있다.

상황에 따라 IP가 잡히면서 안될 때가 있는데, 뒤는 그대로 두고(세션 키가 있어서 중요함) localhost로 바꿔서 접속하면 된다.

  • JDBC URL

    • 최초에는 데이터베이스 파일을 만드는데, 그 파일 경로를 의미한다.

    • 위 그림에서는 home에 있는 test 폴더를 의미한다.

  • 사용자 명과 비밀번호는 그대로 두고 연결하면 접속된다.

실제로 home에서 파일을 찾아보면 test.mv.db가 존재해야 한다. 이후부터는 파일로 접근하게 되면 웹 콘솔과 애플리케이션이 서로 충돌할 수 있다.

이때는 JDBC URL에 jdbc:h2:tcp://localhost/~/test로 접속해야 충돌이 나지 않는다. 소켓으로 접속하는 방식이므로 여러 곳에서 접속할 수 있게 된다.

테이블 생성

  • generated by default as identity

    • ID가 null 값일 때, DB가 자동으로 ID 값을 채워준다.

순수 JDBC

환경 설정

build.gradle 파일에 jdbc, h2 데이터베이스 관련 라이브러리를 추가한다.

스프링 부트 데이터베이스 연결 설정을 추가한다.

스프링부트 2.4부터는 spring.datasource.username=sa 를 꼭 추가해주어야 한다. 그렇지 않으면 Wrong user name or password 오류가 발생한다.

참고로 위와 같이 마지막에 공백이 들어가면 같은 오류가 발생한다. 공백은 모두 제거해야 한다.

JDBC 리파지토리 구현

참고로 이렇게 JDBC API로 직접 코딩하는 것은 20년 전 이야기다. 고대 개발자들이 이렇게 고생하고 살았구나 생각하고 정신 건강을 위해 참고만 하고 넘어가자.

SpringConfig만 손대면 기존 애플리케이션 관련 코드는 수정하지 않고 변경할 수 있다.

이런 방법을 개방-폐쇄 원칙(OCP)라고 한다. 확장에는 열려있고 수정, 변경에는 닫혀있는 것이다. 스프링의 DI를 사용하면 기존 코드를 전혀 손대지 않고 설정만으로 구현 클래스를 변경할 수 있다.

스프링 통합 테스트

DB를 직접 연결했으므로 스프링을 실행하고 DB를 연결해서 동작시키는 통합 테스트를 해보겠다.

기존의 MemberServiceTest는 JVM 내에서 실행되고 끝나기 때문에 빠르다. MemberServiceIntegrationTest는 로그를 보면 알 수 있듯 스프링을 온전히 띄우고 테스트를 실행하느라 상대적으로 느리다.

@SpringBootTest

스프링 컨테이너와 테스트를 함께 실행한다.

@Transactional

테스트 케이스에 이 애너테이션이 있으면 테스트 시작 전에 트랜잭션을 시작하고 테스트 완료 후에 항상 롤백한다. 이렇게 하면 DB에 데이터가 남지 않아 다음 테스트에 영향을 주지 않는다. 테스트 메서드마다 다 적용된다. 하나 시작하고 끝나면 롤백하고, 하나 시작하고 끝나면 롤백하는 식이다.

단위 테스트는 그럼 왜 필요할까?

가급적이면 순수한 자바 코드로 만든 단위 테스트가 훨씬 좋은 테스트일 확률이 높다. 컨테이너 없이 테스트할 수 있도록 훈련해야 한다. 컨테이너까지 올릴 정도면 테스트 설계가 잘못됐을 수 있다.

JDBC Template

  • 순수 JDBC와 환경 설정이 동일하다.

  • 스프링 JdbcTemplate과 MyBatis 같은 라이브러리는 JPBC API에서 봤던 반복 코드를 대부분 제거해준다. 하지만 SQL은 직접 작성해야 한다.

Last updated

Was this helpful?