💪 Practice

보호되어 있는 글입니다.

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

정상 종료란 무엇일까요?OS로부터 종료 시그널을 받으면 새로운 요청을 받지 않고 처리되고 있던 요청이 모두 끝난 후 모든 자원을 릴리즈한 뒤 프로세스를 종료하는 것입니다.다른 말로는 그레이스풀 셧다운 Graceful shutdown이라고 하기도 합니다.Shutdown gracefully shuts down the server without interrupting any active connections. Shutdown works by first closing all open listeners, then closing all idle connections, and then waiting indefinitely for connections to return to idle and then shut down...

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