: 스터디 카페에 스터디룸에서 봤음. 스터디 룸에서 한시간 전부터 대기하고 있었고, 긴장은 우형 면접보다 덜 된것 같이 느꼈음. 그리고 나서 네이버는 신기하게 미리 줌에 초대해놓고 소회의실에 대기시키고, 대기시키기 전에 마이크나 지원자 카메라나 상태 체크 등을 했음
그리고 상태 체크가 다 된 시점에 15분 간 개인 시간이 주어졌는데 나는 상태체크가 스터디룸 와이파이로 잘 되었다고 생각했는데, 실제로 면접이 시작하니까 갑자기 와이파이가 끊겨서 엄청 당황했음. 들어가자마자 안녕히 계세요 ~~ 이런 느낌으로 나가져버리고, 다시 들어가서 식은땀이 살짝 났지만, 그래도 중간에도 그러면 말해달라고 하셔서 ok 하고 물 마시고 싶었는데 꾹 참았음 (화장실 마려울까봐)
이전 면접 때도 그렇고 옆에 필기할 수 있는 종이를 하나씩 두었는데, 그게 큰 도움이 되었음 면접 보신분은 이준호님과 또 다른 한분이 계셨는데 너무 긴장했어서 그런가다른 분 이름은 기억 안남. (종이에 적어둔 걸로 기억을 되짚어봄) 면접관님들 인사 먼저 듣고, 그 이후에 자기소개를 하라고 함. 그래서 자기소개 늘 하던대로 했고, 면접에서 우형 1차 면접 때랑 비슷하게 내가 주도적으로 면접을 이끌어간다는 느낌을 받았음. 자기소개에서 했던 내용들을 질문으로 전부 주셨음
첫번째로 테스트 코드에 대한 질문을 받았는데, 테스트 성능 개선 어떻게 했냐고 해서 계층간 책임이 맞는지 확인했고, 데이터 격리 방식이나 테스트 격리방식에 대한 고찰을 많이 했다고 말씀드렸음.
그랬더니 인수테스트와 통합테스트의 차이? 인수테스트는 왜 했냐고 물어보셔서 그런 부분에 대해서도 어떤 목적으로 테스트하는지에 따라서 다른 것 같다. 내가 작성한 테스트는 실제로 인수인계 할 때 클라이언트 입장에서 하는 행위에 대한 해피 케이스와 베드 케이스에 대한 검증을 주로 했다. 블랙박스 테스트로 이뤄졌고, 내부 협력 과는 상관없이 요구된 Input 이 주어졌을 때, 원하는 output 이 정상적으로 나오는지를 보고 해당 내용은 문서화 기능도 한다라고 말했고
통합테스트 같은 경우는 한개 이상의 객체들이 하는 협력에 대해서 잘 이뤄지고 있는지 혹은 외부 라이브러리와 협력이 잘 되고 있는지에 대해서 확인하는 용도로 진행했다 주로 SpringBootTest 가 통합테스트로 이뤄져서 간단한 예를 들면 스프링 컨테이너에서 빈이 잘 주입되는지 또한 통합 테스트에 일환이라고 말했다.
그러면 인수테스트랑 통합테스트랑 둘다 꼭 짜야하나요 ? 라고 말씀해주셔서 꼭은 아니라도, 될 수 있다면 짜는게 좋다고 생각한다. 라고 말했고, 둘 중 하나만 짜야한다면 통합테스트를 짜야한다고 말했던 것 같다. 왜냐하면 인수테스트는 내부로직에 대한 검증이 아니기 때문에 정확하게 어디서 병목이있는지 찾아보기 어렵다.
그리고 나서 데이터 격리 방식에 대해서 물어보셨는데, 더티즈 컨텍스트 말고 다른 방법으로 해결한게 있냐고해서 truncate 로 해결한 얘기를 하면서 원래는 수기로 sql 문을 작성했었는데, 그러다 보면 table 구조가 바뀔 때마다 sql 문도 함께 바꿔줘야하는 불편함이 생겨 어떻게 하면 자동화 할 수 있을까 고민하다가 entityManager 에 등록된 eneitity 를 통해서 table 을 생성한다는 점이 떠올라서 해당 방법으로 엔티티 이름을 얻어와 sql문을 자동으로 만드는 방법을 고민해봤다고 했다.
여기서 왜 delete 가 아닌 truncate 를 사용했는지도 설명했다. 처음엔 delete 로 했었는데 delete 는 rollback 이 가능한 DML 이라서 auto Increment 가 초기화 되지 않아서 문제가 있다고 설명했다. 그래서 auto Increment 까지 초기화가 되는 ddl 인 truncate 를 사용했다.
여기서 그럼 truncate 말고 데이터를 격리하는 방식은 없냐고 물어보시고 힌트로 transactional annotation 을 말씀해주셨다. 그래서 트랙잭셔널 어노테이션으로도 데이터를 격리해본 적이 있는데, 테스트 코드에서 transactional 로 격리를 하게 되면 실제 비지니스 로직에는 트랜잭셔널을 누락해서 정상 작동하지 않는 코드인데, 테스트 코드에서는 통과하게되는 문제가 야기 되고, jpa 에서 사용해주는 영속성 컨텍스트에서 더티채킹 또한 롤백 될 거라는 가정하에 진행되기 때문에 실제 쿼리가 나가지 않아서 쿼리가 나가는 것을 보려면 em.flush 를 해줘야했다. 그래서 이런 점들이 불편하게 다가왔고, 가장 큰 문제라고 생각했던건 비지니스에 문제가 있음에도 불구하고 해당 문제를 파악할 수 없다는 것이었다. 라고 말했음