Today's Dev Notes(2018-12-19)

안녕하세요, Brad입니다. 오늘 공부한 내용을 정리해볼게요.

 

• Domain내에서 private필드에 접근하여 처리하는 메서드의 경우 테스트를 어떻게 할 수 있을까요?

  • '테스트는 상태값을 확인하는데 초점을 맞추는 것이 아니라 행동(behavior)에 초점을 맞추어야 한다'는 글을 인터넷에서 봤는데요. 그럼 이렇게 테스트한다는 것 자체가 적절하지 않은걸까요? 왜냐하면 지금 하려는 테스트도 상태값을 확인하는 작업에 불가하거든요.
  • 일부러 그 메서드의 매개변수로 private 필드를 받으면 해결할 수 있지만 이건 좋은 생각은 아닌 것 같아요. 만약 이렇게 만든다면 Domain내에 위치할 필요가 따로 없잖아요.
  • 이런 private필드나 메서드에 접근하기 위해 Reflection을 사용할 수 있습니다. 근데 이게 좋은 아이디어 인지는 잘 모르겠습니다. 캡슐화를 통해 꼼꼼 숨겼다고 생각했는데 치트키를 써서 바로 접근하는 느낌이라서요.
  • 해당 논의는 여기 StackoverFlow에서 볼 수 있습니다.
  • 전 스프링에서 제공하는 ReflectionTestUtils 를 사용하여 아래와 같이 테스트 코드를 만들었습니다.

      @Test
      public void can_not_delete() {
          List<Answer> answersForTest = new ArrayList(Arrays.asList(ANSWER2, ANSWER3));
          ReflectionTestUtils.setField(QUESTION, "answers", answersForTest);  // private 필드 접근
          boolean result = ReflectionTestUtils.invokeMethod(QUESTION, "canDelete");  // private 메서드 접근
          softly.assertThat(result).isEqualTo(false);
      }
  

• 에러메시지를 받을 때 ResponseEntity<ErrorMessage> 가 아니라 ResponseEntity<String> 으로 받는 이유가 뭘까요?

  • 실제로 전자와 같이 사용할 경우 Json parsing과정에서 오류가 발생합니다.

  왜 그런 오류가 발생할까요? 그리고 어떻게 하면 오류를 해결할 수 있을까요?

 

오늘은 step4를 진행하면서 많은 테스트케이스를 작성해보았는데요. 테스트를 작성하는 작업들이 재미있다가도 지루하기도 했습니다. 재미있었던 것은 다양한 경우의 수를 수작업없이 테스트해보고 확인해볼 수 있어서 그랬구요. 지루하기도 한 것은 이러한 다양한 경우의 수가 제가 알고있던 기본적인 로직들에 불과해서 그랬던 것 같습니다. 물론 복잡해지면 그것으로 인한 스트레스도 받겠지만 그냥 그랬습니다. 물론 기본적인 로직들이더라도 어이없는 실수를 막기 위해선 필수적인 작업이 될 수 있겠죠!!

그래도 가장 신기했던 순간은 @Transactional 의 적용 결과를 직접확인 할 때였는데요. JPA는 기본적으로 예외발생시 트랙잭션 내 ROLLBACK를 하고 있습니다. 그렇기 때문에 '다른 유저가 접근할 경우', '로직에 맞지 않는 경우'에 예외가 발생하면 기존에 변화시켰던 것을 다시 되돌려놔야하는데요. 하지만 @Transactional 을 사용하면 그러한 작업을 알아서 다 돌려놓습니다. 아직 다양한 속성들을 적용해보진 못했지만 재미있는 경험이었습니다.