강의 수강 소감

• Practical Testing: 실용적인 테스트 가이드

  • 각 레이어별로 통합테스트방법을 알 수 있다.

  • 프레젠테이션 레이어은 MockMvc로 응답, 결과값을 검증한다.

  • 비즈니스 레이어의 경우 given 절에 데이터 삽입, when 절에 검증할 비즈니스 레이어의 함수를 사용하고 then 절에서 결과값을 검증한다.

  • 영속 레이어의 경우 DataJpaTest 혹은 프레젠테이션레이어처럼 SpringbootTest를 사용한다.

    • 다른 영속 인프라와의 통합테스트가 있을 경우를 대비해 SpringbootTest를 사용하는 것을 권장

    • 빈 구성이 다르므로 SpringbootTest와 별도로 한번더 띄워지기 때문에 주의
      
      

과제 회고

• 과정

  • 지뢰찾기의 각 클래스의 역할을 재정의했다.

    • TDD를 적용해보기 위해 강의에서 정의해준 역할이 아니라 의문이 들었던 내용에 대해 재분배했다.

      • 지뢰가 주변 지뢰를 알고 있는 것이 맞는가 -> Board에 해당 역할 할당.

        • 8칸 고정 수에 대한 연산이므로 O(1)이기 때문에 이를 아끼기 위해 선배정하는 것은 과한 최적화라고 생각했음.

    • 인수분해하듯이 지뢰 셀과 일반 셀의 같은 구현을 가진 역할을 생각했다.

       

      • 열고난 후에는 출력시 값을 보여주는 것

      • 열지않은 셀에 깃발을 꽂고 회수할 수 있는 것

    • 추상화된 역할은 있으나 다르게 구현해야하는 것은 리스코프 치환원칙을 준수해 구현했다.

      • 클리어 조건

      • 열렸을 때 주변 셀도 열어야하는지 여부

      • 지뢰인지 여부

    • toString 메소드가 문자열로 전환하는 역할을 가졌다고 생각해 display와 같은 별도 함수를 사용하지 않았다.

       

• 반성

  • 강의에서 언급된 리팩토링 테크닉을 최대한 활용하지 않았다.

    • 인터페이스에 의존하게 하는 것

       

    • 합성과 구현관계가 아닌 추상 클래스를 활용해 부모클래스를 알아야하도록 한 것

  • toString으로 인해 도메인 클래스가 단일책임을 지키지 못하는 것처럼 보였다.

  • 가로열 수를 알고 있는 Config이 가로열 수를 캡슐화하면 좋겠다는 생각으로 Config에 해당 문자열을 구하는 기능을 배정했으나 클래스의 단일 책임 원칙을 어기도록하는 과도한 캡슐화라고 생각된다.

    • toString으로 getter를 캡슐화한 것도 마찬가지

     

3주차 회고

• 요구사항을 먼저 정하고 테스트를 작성한 후 작업하다보니, 리팩토링이 아니라 새로 구현하는 느낌을 받았다. 도중에 역할을 몇번 재분배하여 테스트 코드도 많이 변경되었지만 내가 직접 산출한 요구사항을 지키는 코드를 작성하다보니 재미있었다.