repository 에 대한 단위 테스트를 작성하다가 repository 를 stub 클래스로 만들고 @MockBean을 이용해서 지정한 값으로 전달해서 만들었는데, 어차피 단위 테스트만으로 끝날 게 아니라 구현을 해야 한다면 @MockBean이 아니라 stub 클래스 내부에 stub 메소드까지 구현해서 만들고 진행하는 것이 더 낫다.
그렇다면 @MockBean 은 이렇게 최저 단계에서는 사용하지 않고 어느 정도 의존성을 가지는 단계, 즉 service 단계 정도에서나 의미를 가지는 것일까?
Entity 오브젝트라면 Id 프로퍼티 값은 있지만 이 프로퍼티의 setter 도 없고 생성자에서도 초기화 하지 않는데 id 값으로 검증하기 위해서는 MockEntity 등의 이름으로 새롭게 만든 클래스로 검증을 해야하나? 하지만 이건 이미 검증 대상인 클래스가 아니기 때문에 테스트에 의미가 사라진다. 그러면 테스트에서 id 값이 아닌 setter 로 값을 지정할 수 있는 값들로만 검증을 해야하는 것인가?
id 에 대한 setter 를 만드는 것은 테스트를 위해 코드에 영향을 미치는 것이라 보고 논외로 친다.
순차적으로 테스트를 검증하면서 코드를 작성하는 경우, 삭제 요청에 대해서는 이미 개발자는 persistance layer를 인지하고 있으며 삭제와 관련한 테스트 통과를 위해 할 수 있는 방법은 단일 결과값이 아닌 collection 형태의 결과값을 보내주어야만 한다. 이것은 억지로 테스트를 static한 값으로 통과시키기 위한 방법이며 당연히 단일 결과값으로 검증하는 것이 맞다. 하지만 이 경우 static 한 값으로 보내주는 것이 그려지지 않는다. 결국 당연스럽게 persistance layer 를 사용해서 코드를 구현하게 되는데, 이것은 당연한 과정인가.
application.properties 에는 저장소에 공개되서는 안되는 값들을 올리는 곳인데 .gitignore 에 추가하고 따로 관리해야 하는가?
delete 요청 삭제 때는 repository 를 호출하지만 특별히 return 하는 값이 없는데 이 경우에 controller 테스트에 의미가 있나 싶다. noContent 응답이 아니라 다른 응답을 보내주어야 하는건가?
이 질문은 비단 삭제 요청 뿐만 아니라 컨트롤러가 어떤 값을 response 로 전달해주지 않고 상태 메시지만 전달하는 경우는 전부 해당하는 것 같다. 즉 create 요청에서도 마찬가지라는 이야기