TDD는 직관적이고 이상적인 사이클을 따른다.RED: 실패하는 테스트를 먼저 작성한다.GREEN: 테스트를 통과할 최소한의 프로덕션 코드를 작성한다.REFACTOR: 코드를 리팩토링하여 개선한다. 먼저 확실히 짚고 넘어가자면, 테스트는 중요하다. 나는 테스트를 사랑한다.테스트는 리팩토링할 때 자신감을 주고, 프로그램의 신뢰성을 확보하는 핵심 수단이다. 또한 코드의 동작을 명확히 전달하는 문서 역할도 한다. 테스트 작성에 최선을 다해야 하는 것은 분명 옳다. 그러나 TDD(Test-Driven Development) 방식에 대해서는 신중한 입장이다.작은 단위에 지나치게 집중할 가능성 TDD는 작은 단위에 집중하게 만든다. 하나의 테스트를 먼저 작성하고, 이를 통과하도록 만드는 최소한의 프로덕션 코드를 추가..

프리코스 2주 차, 테스트로 시작해 테스트로 마쳤다. 테스트 코드는 백엔드 개발자로서 필수적인 요소라고 익히 알고 있었지만, 실제로는 몇 번의 프로젝트를 진행하면서 테스트를 적극적으로 진행해 본 경험이 없었다. 부끄럽다. 그 이유를 나열하기엔 모두 변명일 뿐, 이번 기회에 TDD를 통해서 내 코드의 퀄리티를 검증하는 방법을 제대로 경험하고 싶었다. 리뷰가 간절했고...  TDD Test Driven Development 테스트를 먼저 작성하고, 테스트를 통과시키는 프로덕션 코드를 작성한 뒤 리팩토링하는 과정.Red-Green-Blue 단계로 이루어져, 기능 개발과 리팩토링을 반복적으로 수행하며 코드 품질과 안정성을 높이는 개발 방식.   경험 테스트를 먼저 작성해야한다 테스트를 먼저 작성하라고 권장하는..

1주 차 피드백을 바탕으로 TDD를 적용하려고 하니, 생각지도 못한 큰 난관에 부딪혔다. 바로 테스트 툴에 대한 이해가 부족하다는 것...그렇게나 공부하고 많은 예시를 봤음에도 직접 경험하지 않는다면 무용지물이다. 추상적으로만 생각했을 때, 단순히 실패하는 테스트 케이스를 작성하고, 그 테스트가 통과하도록 코드를 작성한 후, 리팩토링하면 된다고 생각했다. 하지만 실제로는 그 과정이 훨씬 더 복잡했다. 테스트 케이스를 어떻게 작성해야 할지도 감이 잘 오지 않았고, 무엇보다 테스트가 서로 의존적이지 않게 구성하는 방법에 대해서도 막막했다. 특히 이번 과제는 표준 입력을 다루는 특성상, 이를 테스트하는 방법이 쉽지 않았다. 이전에 사용해 본 Mockito 같은 라이브러리를 사용한다면 해결할 수 있을까 싶었지만..