greenjjh0515님의 Spring DB Part 1 - Core Principles...

Spring DB Part 1 - Core Principles of Data Access

노트 작성자

greenjjh0515

Course Introduction

00:16

단순하게 생각하면 웹 애플리케이션은 크게 3가지 기능을 수행한다. 컨트롤러, 서비스, 리포지토리

Understanding JDBC

H2 Database Config

00:23

H2는 최신 버전을 받으면 안 된다. 우리가 쓰는 버전이랑 맞춰야 한다.

build.gradle에 가 보면

runtimeOnly 'com.h2database:h2'

여기 있는 게 H2 데이터베이스에 접속하기 위한 클라이언트이다. 스프링 부트가 기본으로 잡아 준 거다. 버전을 봐야 한다.

External Libraries를 보면

h2:2.2.224

2.2.224 이거를 받아야 한다. 그래야 여기서 접근하는 클라이언트 라이브러리랑 서버랑 버전을 같은 걸 해야 문제가 안 생긴다. 버전이 좀 안 맞아도 될 때도 있지만 안 될 수도 있기 때문에 맞추는 게 좋다.

https://www.h2database.com/html/main.html

여기서 All Downloads 누르면 Archive Downloads라는 게 있다. 거기에 들어가면 내 버전 찾을 수 있다.

02:34

최초에 한 번은

JDBC URL에 jdbc:h2:~/test를 해야 한다.

파일로 바로 접근하는 방식인 듯

연결 누르면 창이 뜬다.

이렇게 접근을 최초로 하면 test.mv.db가 생긴다.

생겼다는 것을 확인해야 한다.

이후부터는 jdbc:h2:tcp://localhost/~/test 이렇게 접근해야 한다.

jdbc:h2:~/test 이건 파일에 내가 직접 접근하는 것이다. 그래서 이제 이렇게 하면 안 된다.

파일이 생성되고 나면

jdbc:h2:tcp://localhost/~/test로 연결해야 한다.

이렇게 해야 문제가 안 생기고 잘 작동한다.

04:48

이제 준비는 됐다.

이후에 애플리케이션에서 데이터베이스 member에 접근해서 이 데이터를 넣고 빼는 예제들을 할 것이다.

Understanding JDBC

01:29

옛날엔 각각의 데이터베이스마다 사용 방법이 많이 달랐다. 옛날 이야기이다.

03:35

애플리케이션 로직은 과거엔 MySQL이나 오라클이 제공하는(?) 거기에 직접 사용했었다면, 이제 그렇게 하지 않고, 지금은 JDBC가 이런 걸 표준으로 정해 놨다.

java.sql.Connection - 연결하는 것

java.sql.Statement - SQL을 전달하는 것

java.sql.ResultSet - SQL 결과에 대해 어떻게 응답하는지

이게 옛날엔 DB마다 방법이 다 달랐다.

그런데 JDBC 표준 인터페이스가 나오게 되고 위 세 가지를 표준 인터페이스로 정했다. 자바는 이렇게 표준 인터페이스를 정의해 두었다.

05:19

JDBC 드라이버는 JDBC 표준 인터페이스를 구현해서 만든 드라이버이다.

개발자 입장에선 애플리케이션 로직을 개발할 때 JDBC 표준 인터페이스에만 맞춰서 개발하면 된다. 그러면 내가 MySQL 드라이버를 쓸 거면 MySQL 드라이버를 인터페이스에 꽂아서 쓰면 된다.

오라클로 바꿀 거면, 애플리케이션 로직에선 JDBC 표준 인터페이스는 그대로 사용하고, 구현체로 드라이버만 바꾸면 된다.

JDBC and Latest Data Access Technologies

00:33

JDBC를 직접 사용해도 되기는 한다.

00:56

JDBC를 직접 사용하면 사용 방법이 복잡하다. Low 레벨로 제공하다 보니 기능이 다 쪼개져 있다.

01:44

JDBC는 SQL 응답 결과를 객체로 바꿀 때 되게 복잡하다.

그런데 SQL Mapper를 사용하면 개발자가 SQL을 작성하면 나머지... SQL의 응답 결과를 객체로 바꿔 주거나 이런 것들을 좀 자동화해 준다. 그리고 JDBC의 반복 코드도 제거해 준다.

실무에서 SQL을 직접 쓸 때 JDBC를 직접 쓰는 경우는 없고, 최소한 JdbcTemplate이나 MyBatis 둘 중 하나를 선택해서 사용한다.

SQL Mapper의 단점은 개발자가 SQL을 직접 작성해야 한다는 것이다. ORM 기술과 비교했을 때의 단점이다.

02:54

ORM의 경우 애플리케이션 로직에선, 회원을 저장한다고 할 때 insert into 같은 SQL 쿼리를 전달하는 게 아니라, 회원 객체를 JPA에 전달한다. 그럼 여기서(구현체가 있기는 하다.) 객체의 매핑 정보가 있는데 그런 걸 보고 insert 쿼리를 직접 만든다.

개발자가 SQL을 작성하는 게 아니고, 개발자는 마치 자바의 컬렉션에 객체 넣을 때처럼 JPA에 넣어 주면 된다. 그러면 JPA가 알아서 SQL 다 만들어서 JDBC를 통해서 데이터베이스에 전달한다.

03:39

ORM은 객체를 관계형 데이터베이스 테이블과 매핑해 주는 기술이다. 객체랑 테이블이랑 어떻게 매핑되어 있는지 설정 정보를 주면 된다.

04:18

ORM은 각각의 데이터베이스마다 다른 SQL을 사용하는 문제도 중간에서 해결해 준다. 예를 들어 오라클이랑 MySQL은 페이징 쿼리가 다른데, 이런 부분들도 JPA가 제공하는 표준 페이징 인터페이스를 쓰면 오라클을 쓰면 오라클 DB에 맞춰서 오라클 페이징, MySQL을 쓰면 MySQL에 맞춰서 페이징 쿼리가 나간다.

05:00

JPA는 자바 진영의 ORM 표준 인터페이스이고, 이것을 구현한 것으로 하이버네이트와 이클립스 링크 등의 구현 기술이 있다.

실무에선 거의 하이버네이트를 쓰는 듯

Database Connection

02:51

java.sql.Connection이 JDBC 표준 인터페이스가 제공하는 커넥션이다.

03:13

F2 누르면 오류인 곳으로 이동한다.

04:45

@Slf4j
public class DBConnectionUtil {

    public static Connection getConnection() {
        try {
            Connection connection = DriverManager.getConnection(URL, USERNAME, PASSWORD);
            log.info("connection = {}, class = {}", connection, connection.getClass());

            return connection;

        } catch (SQLException e) {
            throw new IllegalStateException(e);
        }
    }
}

예외는 뒤에서 더 배운다.

지금은 체크 예외를 실행 예외로 바꿔서 던진다고만 알고 있으면 된다.

05:19

Connection connection = DriverManager.getConnection(URL, USERNAME, PASSWORD);

데이터베이스에 연결하려면 JDBC가 제공하는 DriverManager.getConnection(..)을 사용하면 된다. 이렇게 하면 라이브러리에 있는 데이터베이스 드라이버를 찾아서 해당 드라이버가 제공하는 커넥션을 반환해 준다.

우리는 H2 클라이언트가 필요하다.

이걸(Driver) 통해 DB에 들어간다.

DriverManager가 자기들의 규칙에 따라서 이걸 찾는다.

즉 H2에 있는 이 드라이버(구현체)를 통해서 실제 커넥션을 가져온다.

DriverManager.getConnection()은 JDBC가 제공하는 거다.

06:29

@Slf4j
class DBConnectionUtilTest {
    
}

테스트엔 앞에 public 없어도 된다.

07:36

@Slf4j
class DBConnectionUtilTest {
    @Test
    void connection() {
        Connection connection = DBConnectionUtil.getConnection();
        assertThat(connection).isNotNull();
    }
}

이 테스트를 실행할 때

h2.bat을 실행한 후, 이렇게 연결 버튼을 누르지 않고 이 창을 켜 놓기만 한 상태(혹은 왼쪽의 창은 끄고 오른쪽 검은 창만 켜 놓아도)에서 테스트를 해도

이렇게 테스트 성공한다.

그런데 h2.bat을 아예 실행하지 않고(혹은 실행한 다음 웹 화면은 그대로 두고, 검은 창만 꺼도) 테스트를 진행하면

테스트 실패한다.

07:43

테스트할 땐 이걸 조심해야 한다.

위 사진에서 connection()을 클릭하면

@Test
void connection() {
    Connection connection = DBConnectionUtil.getConnection();
    assertThat(connection).isNotNull();
}

이 테스트를 실행할 때 나오는 로그만 나오고,

상위에 있는 Test Results를 클릭하면 실제 애플리케이션이 실행되는 전체 로그가 나온다.

08:03

테스트 로그를 보면

23:45:22.277 [Test worker] INFO hello.jdbc.connection.DBConnectionUtil -- connection = conn0: url=jdbc:h2:tcp://localhost/~/test user=SA, class = class org.h2.jdbc.JdbcConnection

이렇게 된다.

08:24

@Test
void connection() {
    Connection connection = DBConnectionUtil.getConnection();
    assertThat(connection).isNotNull();
}

이 테스트 실행할 때

Connection connection = DBConnectionUtil.getConnection();

여기서 getConnection()을 호출하면

@Slf4j
public class DBConnectionUtil {

    public static Connection getConnection() {
        try {
            Connection connection = DriverManager.getConnection(URL, USERNAME, PASSWORD);
            log.info("connection = {}, class = {}", connection, connection.getClass());

            return connection;

        } catch (SQLException e) {
            throw new IllegalStateException(e);
        }
    }
}

여기서

Connection connection = DriverManager.getConnection(URL, USERNAME, PASSWORD);

DriverManager.getConnection()을 통해 커넥션을 가져왔다. 가져온 커넥션을 보면

인터페이스이다. 구현체가 있을 것이다. 이 구현체가 바로

MySQL 드라이버는 MySQLConnection이라는 구현체를 가지고 있고,

오라클 드라이버는 OracleConnection을 제공한다.(이름은 다를 것이다.)

H2는 org.h2.jdbc.JdbcConnection을 제공한다.

External Libraries에 가 보면

이게 있다. 이 JdbcConnection을 반환해 준다.

왜냐하면 우리는 MySQL 드라이버나 Oracle 드라이버가 아니고 H2 드라이버를 쓰기 때문이다.

그래서 Connection 인터페이스의 구현체인, H2 데이터베이스가 구현한 그 구현체를 제공해 준다.

우리는 그냥

Connection connection = DriverManager.getConnection(URL, USERNAME, PASSWORD);

이 Connection 인터페이스 기반으로만 코딩하면 된다. DB가 바뀌어도 이걸(커넥션을 획득하는 방법) 바꿀 필요가 없다.

11:39

org.h2.jdbc.JdbcConnection 이게 있어야 H2 데이터베이스랑 통신이 된다.

12:41

External Libraries에 H2 드라이버뿐만 아니라 MySQL 드라이버까지 같이 들어왔다고 가정하자.

그러면 DriverManager가 호출할 수 있도록 이것들이 다 드라이버 목록에서 관리된다.

13:07

예를 들어

Connection connection = DriverManager.getConnection(URL, USERNAME, PASSWORD);

jdbc:h2:tcp://localhost/~/test 이 URL로 요청했다고 하자

이름, 비밀번호 같은 추가 정보도 보낸다.

그러면 DriverManager에선 라이브러리에 등록된 드라이버 목록에 다 던진다. 우선 H2 드라이버에 던진다고 하자.(순서는 바뀔 수 있다.)

여기서 각각의 드라이버는 URL 정보를 체크해서 본인이 처리할 수 있는 요청인지 확인한다. 예를 들어서 URL이 jdbc:h2로 시작하면 이것은 h2 데이터베이스에 접근하기 위한 규칙이다.

따라서 H2 드라이버는 본인이 처리할 수 있으므로 실제 데이터베이스에 연결해서 커넥션을 획득하고 이 H2 커넥션을 클라이언트에 반환한다. 물론 인터페이스는 java.sql.Connection이고, 구현체는 H2 드라이버가 제공하는 H2 Connection이다.

반면에 URL이 jdbc:h2로 시작했는데 MySQL 드라이버가 먼저 실행되면 이 경우 본인이 처리할 수 없다는 결과를 반환하게 되고, 다음 드라이버에게 순서가 넘어간다. 만약 그래도 처리가 안 되면 커넥션을 획득할 수 없다고 오류가 날 것이다.

15:28

사실 우리가 H2 드라이버를 쓰는지, MySQL 드라이버를 쓰는지를 직접 어디에 등록 안 해도 된다. 라이브러리에 들어만 있으면, DriverManager에서 자동으로 다 인식할 수 있다.

JDBC Development - Registration

02:03

@Data
public class Member {
    private String memberId;
    private int money;

    public Member() {
    }

    public Member(String memberId, int money) {
        this.memberId = memberId;
        this.money = money;
    }
}

이전에 H2 데이터베이스에 만든

MEMBER_ID, MONEY와 매핑된다.

02:43

/**
 * JDBC - DriverManager 사용
 */
@Slf4j
public class MemberRepositoryV0 {
    
}

JDBC의 DriverManager를 사용해서 저장할 것이다.

매우 Low 레벨로 하는 것을 한 번쯤은 하는 게 좋다.

나중엔 이런 JDBC 코드를 사용할 일은 없다.

03:56

Connection이 있어야 연결을 한다.

PreparedStatement를 가지고 데이터베이스에 쿼리를 날린다.

pstmt = con.prepareStatement(sql);

이건 체크 예외가 올라와서 try ~ catch 구문으로 잡거나 밖으로 던져야 한다.

06:21

} catch (SQLException e) {
    log.error("db error", e);
    throw e;
}

throw e;를 통해 예외를 그냥 밖으로 던지겠다.

06:55

} finally {
    pstmt.close();
    con.close();
}

닫아야 한다.

외부 리소스를 쓰고 있다. 실제 TCP/IP 커넥션이 걸려서 쓰고 있는 거다. 이 커넥션을 안 닫으면 잘못하면 이게 연결이 안 끊어지고 유지될 수 있다. 그러므로 닫아야 한다.

그런데 여기서 끝이 아니다.

만약 pstmt.close()에서 예외가 터지면 밖으로 나가면서 con.close()가 호출이 안 되는 문제가 발생할 수 있다.

그러니 다음과 같이 수정해야 한다.

private void close(Connection con, Statement stmt, ResultSet rs) {
    if(rs != null) {
        try {
            rs.close();
        } catch (SQLException e) {
            log.error("error", e);
        }
    }
    
    if(stmt != null) {
        try {
            stmt.close();
        } catch (SQLException e) {
            log.error("error", e);
        }
    }

    if(con != null) {
        try {
            con.close();
        } catch (SQLException e) {
            log.error("error", e);
        }
    }

}

ResultSet은 뒤에 나온다. 지금은 ResultSet이 없으니 null로 하겠다.

Statement는 SQL을 그대로 넣는 거고, PreparedStatement는 파라미터를 바인딩 할 수 있다. 기능이 더 많다. Statement를 상속받았다. 그래서 이렇게 넘길 수 있다.

if(stmt != null) {
    try {
        stmt.close();
    } catch (SQLException e) {
        log.error("error", e);
    }
}

문제가 생겨도 여기서 크게 할 수 있는 건 없어서 그냥 로그로 에러만 남기겠다. 왜냐하면 이건 어떻게 처리할 수 있는 게 없다.

if(con != null) {
    try {
        con.close();
    } catch (SQLException e) {
        log.error("error", e);
    }
}

여기도 로그만 남기겠다. 이미 닫을 때 예외가 터진 거라서 특별히 할 수 있는 게 없다.

이런 식으로 하면 stmt.close()에서 SQLException 예외가 터져도 catch로 잡는다. 그래서 여기서 끝이 나기 때문에 뒤에 있는 if(con != null) {...}에 영향을 주진 않는다. 그래서 위에 SQLException이 터져도 con을 닫을 수 있다.

사용한 자원들을 다 닫아야 한다. 그래서 JDBC 코드가 지저분하다.

11:55

pstmt.executeUpdate();

이걸 하면 준비된 쿼리가 실제 데이터베이스에 실행된다.

12:53

리소스 정리는 finally에서 정리해야 한다. 왜냐하면 close()를 try에서 한다고 하면, 위의 다른 코드에서 예외가 터지면 바로 catch로 가 버려서 close()가 호출되지 않는다. 그러므로 항상 호출되는 게 보장되도록 finally에서 해야 한다.

이런 순서는 옛날엔 중요했지만 지금은 SQL Mapper나 JPA가 다 해 주기 때문에 이제 우리가 크게 고민 안 해도 된다.

13:44

con = getConnection();
pstmt = con.prepareStatement(sql);

Connection을 먼저 획득하고 Connection을 통해 PreparedStatement를 만들었기 때문에 리소스를 반환할 때는 PreparedStatement를 먼저 종료하고, 그다음에 Connection을 종료하면 된다.

14:49

PreparedStatement는 Statement의 자식 타입인데, ?를 통한 파라미터 바인딩을 가능하게 해 준다.

참고로 SQL Injection 공격을 예방하려면 PreparedStatement를 통한 파라미터 바인딩 방식을 사용해야 한다.

이걸 만약 안 쓰면 어떻게 되냐 하면(이 강의 범위를 넘어서는 거라 대략적으로만 설명)

String sql = "insert into member(member_id, money) values(?, ?)";

이건 이전에 작성한 코드이다. ?라고 하면 파라미터 바인딩이라는 게 명확하다. 그런데 이렇게 할 수도 있다.

String memberId = "select * from ...";
String money = "...";
String sql = "insert into member(member_id, money) values("+ memberId +", "+ money +")";

SQL Injection이라는 건 회원 가입할 때, 회원 가입 창에 이런 식으로 적는 거다.

String memberId = "select * from ..." 같은 쿼리가 들어오는 거다.

그럼 memberId 부분이 SQL로 치환된다. 지금 쓴 쿼리에선 문제가 없을 수도 있는데 select 쿼리 같은 경우 이게 프로그램 로직에 들어올 수 있다. 즉, 문제가 되는 다른 걸 호출할 수도 있다. 그러면서 DB가 털린다.

그런데 이걸 파라미터 바인딩 방식을 쓰면

String sql = "insert into member(member_id, money) values(?, ?)";

이 안엔 단순히 데이터로만 취급이 되기 때문에 그럴 염려가 없다.

즉, 단순히 문자 더하기를 하면

insert into member(member_id, money) values(insert into ..., ...)

SQL의 일부가 된다. insert into가 추가로 들어올 수 있다.

그런데 파라미터 바인딩을 하면 단순하게 데이터로 취급된다. 그래서 SQL Injection 공격이 안 된다.

결론은 PreparedStatement를 쓰면 된다.

18:19

class MemberRepositoryV0Test {

    MemberRepositoryV0 repository = new MemberRepositoryV0();

    @Test
    void crud() throws SQLException {
        Member member = new Member("memberV0", 10000);
        repository.save(member);
    }
}

throws SQLException을 하는 이유는 MemberRepositoryV0의 save() 코드를 보면

} catch (SQLException e) {
    log.error("db error", e);
    throw e;
} finally {

체크 예외 SQLException이 올라오기 때문이다. 그래서 예외를 던졌다.

18:43

테스트를 실행하고 성공했다면 이제 H2 데이터베이스에서 확인해 보겠다.

select * from member;를 실행하면

내가 저장했던 데이터가 들어 있다.

애플리케이션을 통해서 Member 데이터를 save()에 집어넣고 호출하면, save() 코드에서 insert 쿼리에 데이터들이 다 바인딩이 되어서, executeUpdate()로 실제 insert SQL이 데이터베이스에 전달되고, 결과가 반영된다.

19:11

그런데

@Test
void crud() throws SQLException {
    Member member = new Member("memberV0", 10000);
    repository.save(member);
}

이걸 한 번 더 실행하면 예외가 터진다.

org.h2.jdbc.JdbcSQLIntegrityConstraintViolationException: Unique index or primary key violation: "PUBLIC.PRIMARY_KEY_8 ON PUBLIC.MEMBER(MEMBER_ID) VALUES ( /* 1 */ 'memberV0' )"; SQL statement:

insert into member(member_id, money) values(?, ?) [23505-224]

왜냐하면 primary key가 MEMBER_ID인데 같은 값이 들어와서 문제가 된다. 다른 값으로 바꾸고 실행하면 제대로 된다.

반복해서 테스트할 수 있는 기법들은 뒤에서 배운다.

19:36

추가적으로 테스트)

h2.bat 실행해서

이 상태로만 두고, 연결 버튼은 안 누른 상태에서

@Test
void crud() throws SQLException {
    Member member = new Member("memberV3", 10000);
    repository.save(member);
}

이 테스트 실행해도 정상적으로 등록된다.

JDBC Development - Query

01:23

회원 하나를 조회하는 기능을 개발해 보자.

01:31

Connection con = null;
PreparedStatement pstmt = null;

이런 걸 밖에 선언하는 이유가 try ~ catch 이후에 finally에서 이걸 호출해야 하기 때문에 밖에 선언해야 한다.

04:22

if(rs.next()) {
    Member member = new Member();
    member.setMemberId(rs.getString("member_id"));
    member.setMoney(rs.getInt("money"));

    return member;
} else {
    throw new NoSuchElementException("member not found memberId = " + memberId);
}

데이터가 없어서 rs.next()가 false를 반환하면 else로 가서 예외를 던지겠다.

예외를 던질 땐 메시지를 잘 정의하는 게 좋다. 만약 memberId를 안 넣어 놓는다면 서비스 운영할 때 어떤 멤버에서 문제가 생겼는지 찾기 힘들 수 있다.

07:23

테스트 실행하기 전에 기존에 등록했던 데이터들은 H2 데이터베이스에서 다 삭제해 두겠다.

09:12

@Test
void crud() throws SQLException {

    // save
    Member member = new Member("memberV3", 10000);
    repository.save(member);

    // findById
    Member findMember = repository.findById(member.getMemberId());
    log.info("findMember = {}", findMember);
    log.info("member == findMember {}", member == findMember);

    assertThat(findMember).isEqualTo(member);
}

member와 findMember는 다른 객체이다.

member는 위 코드에서 생성해 주고,

findMember는

findById() 내부 코드를 보면

if(rs.next()) {
    Member member = new Member();
    member.setMemberId(rs.getString("member_id"));
    member.setMoney(rs.getInt("money"));

여기서 new Member()로 생성한 거다.

즉 다른 객체이다.

log.info("member == findMember {}", member == findMember);

이 로그의 결과도

23:38:29.204 [Test worker] INFO hello.jdbc.repository.MemberRepositoryV0Test -- member == findMember false

이렇게 false가 나온다.

하지만

assertThat(findMember).isEqualTo(member);

이건 테스트 성공한다.

@Test
void crud() throws SQLException {

    // save
    Member member = new Member("memberV4", 10000);
    repository.save(member);

    // findById
    Member findMember = repository.findById(member.getMemberId());
    log.info("findMember = {}", findMember);
    log.info("member == findMember {}", member == findMember);
    log.info("member equals findMember {}", member.equals(findMember));

    assertThat(findMember).isEqualTo(member);
}

이렇게 실행해 보면

equals는 true이다.

@Data를 쓰면 equals()와 hashCode()를 자동으로 만들어 준다.

assertThat(findMember).isEqualTo(member);

이것도 내부에서 equals()를 써서 비교한다. 그래서 참이다.

11:51

ResultSet도 이런 식으로 생겼다.

14:16

findById()에서는 회원 하나를 조회하는 것이 목적이다. 따라서 조회 결과가 항상 1건이므로 while 대신에 if를 사용한다. 다음 SQL을 보면 PK인 member_id를 항상 지정하는 것을 확인할 수 있다.

-> 우리는 PK를 찍어서 데이터를 하나만 조회했으므로, 0개 아니면 1개이기 때문에 if를 사용했다.

JDBC Development - Update, Delete

02:28

int resultSize = pstmt.executeUpdate();

이건 0이나 1이 나와야 한다.

왜냐하면

String sql = "update member set money = ? where member_id = ?";

where 문에서 PK로 찍었다.

03:04

executeUpdate()는 쿼리를 실행하고 영향받은 row 수를 반환한다. 여기서는 하나의 데이터만 변경하기 때문에 결과로 1이 반환된다. 물론 없으면 0이 반환된다.

07:11

지금까지 작성한 save(), findById(), update(), delete()를 보면 비슷한 코드들이 많다. 그래서 SQL Mapper 이런 게 나왔다.

쿼리도 비슷하다. 그래서 JPA도 나왔다.

뒤에서 다 해 보겠다.

08:00

delete()는 검증을 어떻게 해야 할까?

@Slf4j
class MemberRepositoryV0Test {

    MemberRepositoryV0 repository = new MemberRepositoryV0();

    @Test
    void crud() throws SQLException {

        // save
        Member member = new Member("memberV100", 10000);
        repository.save(member);

        // findById
        Member findMember = repository.findById(member.getMemberId());
        log.info("findMember = {}", findMember);
        log.info("member == findMember {}", member == findMember);
        log.info("member equals findMember {}", member.equals(findMember));

        assertThat(findMember).isEqualTo(member);

        // update: money: 10000 -> 20000
        repository.update(member.getMemberId(), 20000);
        Member updatedMember = repository.findById(member.getMemberId());
        assertThat(updatedMember.getMoney()).isEqualTo(20000);

        // delete
        repository.delete(member.getMemberId());
        Member deletedMember = repository.findById(member.getMemberId());
    }
}

이걸 테스트하면 테스트 실패한다.

NoSuchElementException 예외가 터진다. 이건

} else {
    throw new NoSuchElementException("member not found memberId = " + memberId);
}

우리가 만든 이거다.

그렇다면 검증은 어떻게 해야 할까? 삭제를 하면 데이터가 사라진다. 그러면 NoSuchElementException을 던지도록 해 놨다. 이 예외가 터지면, 이건 데이터가 없으니 삭제가 성공했다고 보면 된다.

// delete
repository.delete(member.getMemberId());
assertThatThrownBy(() -> repository.findById(member.getMemberId()))
        .isInstanceOf(NoSuchElementException.class);

findById()를 호출하면 NoSuchElementException 예외가 터져야 한다.

11:20

마지막에 회원을 삭제하기 때문에 테스트가 정상 수행되면, 이제부터는 같은 테스트를 반복해서 실행할 수 있다.

물론 테스트 중간에 오류가 발생해서 삭제 로직을 수행할 수 없다면 테스트를 반복해서 실행할 수 없다.

예를 들어

// update: money: 10000 -> 20000
repository.update(member.getMemberId(), 20000);
Member updatedMember = repository.findById(member.getMemberId());
assertThat(updatedMember.getMoney()).isEqualTo(20000);

if(true) {
    throw new IllegalStateException("...");
}

// delete
repository.delete(member.getMemberId());
assertThatThrownBy(() -> repository.findById(member.getMemberId()))
        .isInstanceOf(NoSuchElementException.class);

이런 식으로 delete() 전에 예외가 터지면 delete()가 호출되지 않는다.

그러면 DB에도

memberV100이 저장되어 있다.

그러면 다음에 위 코드를 수정해서 예외를 발생하지 않도록 하더라도, 테스트 다시 실행하면 그래도 안 된다. 왜냐하면 memberV100은 이미 DB에 들어가 있기 때문이다.

그렇기 때문에 이 경우엔 어쩔 수 없이 DB에서 delete를 따로 해 줘야 한다. 그다음에 다시 테스트 실행하면 성공한다.

아무튼 이와 같은 이유로 지금처럼 테스트 마지막에 delete()를 넣어서 삭제하는 게 궁극적인 방법은 아니다.

트랜잭션을 활용하면 이 문제를 깔끔하게 해결할 수 있는데, 자세한 내용은 뒤에서 설명한다.

Summary