들어가며최근 회사에서 자진해서 욕심내어 했던 사례를 하나 소개합니다.테스트 컨테이너를 도입하여 실제 서비스 DB인 postgresql로 테스트를 할 수 있도록 하는 일이었습니다. 프로젝트의 테스트 DB가 h2 인메모리로 사용 중이었는데요. 도입하기 매우 가볍고 빠르다는 장점이 있었지만, 여러 단점들도 많았습니다.대표적으로 있었던 단점이 이런것들이 있었는데요.H2에서 테스트할 수 있는 쿼리만 사용할 수 있음.`ON CONFLICT` 등의 쿼리는 사용할 수 없음.`DISTINCT`을 사용할 때 H2에서는 동작하던 쿼리가 Postgresql에서는 오류를 일으키기도 함.Postgresql에서 사용하던 설정이나 컬럼 등을 사용할 수 없음.위의 이유 때문에 테스트를 신뢰할 수 없는 경우도 종종 생겼습니다.  매번 ..

들어가며 이 글은 최근 테스트 작성을 많이 하기 시작하며 염두하기 시작했던 부분들을 잊지 않기 위해 작성해보았습니다. 사실 작년까지는 테스트 코드 작성을 정말 최소한으로만 해왔었는데요. 짜고나서 동작을 확인할 때, 테스트하고 싶은 것만 테스트하고 (정말 로직만 확인하는 테스트) 그나마도 구현이 계속되어 테스트를 고쳐야할 때면 가끔 코드를 들어내기도 했습니다. TDD나 테스트가 좋다고는 하지만 오히려 구현에 발목을 잡히는 것이 아닌가 하는 생각도 들었고요. 최근 테스트를 열심히 짜보며 이런 생각을 고치게 되었습니다. "그동안 내가 테스트가 유효할 만큼의 테스트를 짜보지 않아서 잘모르고 있었다, 변경에 취약한 테스트를 짜고 있었다"는 생각이 들어 중간 소결차 글을 써봐야겠다는 생각이 들었습니다. 특히 회사에..