✅ 한 일

💻 수행한 것들

• 2주차 미션: 페어 프로그래밍 with Shine
  2주차 미션은 페어 프로그래밍으로 진행하였습니다. 처음에는 좀 어색했지만 TDD 과제를 하면서 한결 자연스럽게 진행할 수 있었습니다. Shine이 우연찮게 TDD 방식으로 해보자고 하셔서 진행했는데, 미션 외 학습 거리에도 TDD 과제가 있어서 신기했습니다.
  처음으로 TDD에 입문했는데, 처음에는 뭔가 의미없는 행동을 한다고 생각했는데, 과제를 해보면서 점점 코드의 규모가 커지니까 테스트 통과하기가 점점 어려워지면서 코드 구조를 생각하게 되었습니다. 또한, 리팩토링을 한 사이클마다 거치기 때문에 상당히 좋은 코드를 작성할 수 있었습니다.
  저녁에도 같이 설계를 고민하며 TDD로 미션을 수행하면서 테스트 코드 작성이나 객체지향적 설계에 대해서 많이 고민할 수 있었습니다.

• 운영체제 강의 수강

📝 배운 것들

TDD의 기본 사이클

TDD는 기본적으로 RED(실패) - GREEN(통과) - YELLOW(리팩토링)의 사이클을 거친다.

1. 빨강 - 실패하는 작은 테스트를 작성한다. 처음에는 컴파일조차 되지 않을 수 있다.
2. 초록 - 빨리 테스트가 통과하게끔 만든다. 이를 위해 어떤 죄악을 저질러도 좋다.
3. 리팩토링 - 2단계에서 생겨난 모든 중복을 제거한다.

RED(실패)

TDD를 하기 위해선 먼저 테스트가 실패해야 한다. 처음엔 왜 이렇게 하지?라는 생각이 들었다. 하지만 핵심은 실패하는 테스트 코드를 작성할 때까지 프로덕션 코드를 작성하지 않는 데 있다. 그러면서 자연스럽게 요구사항이나 코드로부터 기대하는 바를 명확히 할 수 있다는 점이다.

처음에 생각나는 대로 코드를 짜다가, 테스트가 어렵다거나 요구사항에 대해 잘못 접근하게 되는 경우가 많다. 먼저 실패하는 테스트 코드를 작성하는 과정에서 이 클래스의 메서드가 어떻게 동작해야 하고 기대 결과는 무엇인지를 정리하게 된다. 그래서 테스트 통과를 위해 메서드를 작성할 때도 훨씬 수월해지는 원리로 이해했다.

또한 초기에 설계를 수정하기 쉬워진다. 보통은 모든 프로덕션 코드를 짜고 마지막에 테스트 코드를 작성하는 경우가 많은데, 테스트 결과 잘못된 것이 있다면 그 때 코드를 다 뜯어고쳐야 할 수 있다. 하지만 테스트 코드로 검증하면서 그 과정에서 잘못된 설계를 발견하거나 리팩토링할 여지가 있기 때문에 좀 더 안정적으로 개발해나갈 수 있다.

GREEN(통과)

테스트를 통과할 수 있는 실제 코드를 작성한다. 실제로는 정말 지엽적이더라도 통과만 하게 만들고 자연스럽게 다른 케이스를 추가하면서 실패하는 케이스를 발견하고, 다시 보완하는 식으로 코드를 완성해나간다고 한다.
가령, 2+3=5를 수행하는 메서드를 테스트한다고 하면, 처음에는 터무니없게도 return 5와 같이 당연히 성공하도록 만든다. 그리고 테스트 케이스를 넓혀 다양한 경우의 수를 검증하는 과정에서 로직을 구체화해나가는 것이다.

그럼 자연스럽게 넓은 범위의 테스트를 거치게 되고 오류 발생 가능성이 줄어들게 될 것이다.

YELLOW(리팩토링)

위 과정에서는 테스트를 통과하게만 만들기 위해 깔끔한 코드를 짜려고 노력하지 않는다. 그리고 테스트가 모두 통과하면 그 과정에서 발생한 중복 코드나 안좋은 코드를 리팩토링해나간다. 실제로 이 과정을 몇 번 거치니 군더더기없이 깔끔한 부분만 남은 코드가 되었다. 게다가 필요한 테스트도 추가하기 쉬워진다.

TDD vs BDD

카카오 if - "Kotest가 있다면 TDD 묻고 BDD로 가!"를 보고 작성하였습니다.

TDD (Test-Driven Development)

요구 사항에 맞게 테스트 케이스를 작성하고, 테스트가 통과할 때까지 실제 코드를 작성하는 방법

TDD vs !TDD

테스트 케이스를 작성한다고 모두 TDD인 것은 아니다. 코드가 우선하고 검증을 위해 테스트 코드를 작성하는 방법은 일반적으로 TDD로 볼 수 없다.

TDD의 특징

• 자연스럽게 테스트를 기반으로 작성된 코드이므로 Testable 해진다.
  • 각 모듈을 테스트할 수 있도록 모듈의 크기가 자연스럽게 줄어든다.
  • 객체간의 Coupling도 줄어들어 유지/보수가 수월하게 된다.

왜 TDD를 안할까?

• 시간적인 비용으로 인한 기술 부채의 악순환
  • TC 창작의 고통
  • 일정 지연 압박
  • Test 포기한 개발/배포

BDD (Behavior-Driven Development)

• 개발자와 비개발자간의 협업 과정을 녹여낸 방법
• BDD로 테스트 코드를 작성함에 따라 설계 역시 행위의 중심이 되는 도메인 기반 설계가 됨
• Given/When/Then에 따라 테스트 코드를 작성한다.
  • Given: 주어진 환경
  • When: 행위
  • Then: 기대 결과
• ~일 때, ~인 상황에서 -> ~하면 -> ~한다
• 기획서의 양식과 동일하게 코드를 작성해나갈 수 있다.

TDD와 BDD의 차이

• TDD : add(1,1)이 2인지 확인
• BDD : 사용자가 "="를 눌렀을 때, 1+1의 값 2가 화면에 표시되는지 확인

-> BDD는 유저 동작의 시나리오를 커버하는 테스트 영역이고, TDD는 유저 동작에 관여하는 모듈들의 검증을 맡는다. 즉, 어느 하나만으로는 모두 커버할 수 없기 때문에 BDD 사이클에 TDD 사이클이 결합된 상태로 사용한다.

기획이 누락되는 경우에, 다시 기획과 설계를 거쳐 코드를 작성해야 하는 리스크가 있다. BDD를 통한다면 기획이 검토되는 과정에서 시나리오의 빈틈을 발견하여 실제 코드 작성 전에 수정할 수 있는 장점이 있다.

💪 좋은 점

• 페어 프로그래밍을 하면서 좀 더 협업능력을 기를 수 있었다.
• TDD와 BDD에 대해 알아보면서 예전에 작성하던 단위테스트가 BDD스럽게 작성되었다는 것을 알게 됐다.
• TDD를 직접 진행해보며 어떤 관점에서 개발하는 방식인지 체감해보았다.

👀 아쉬운 점

• 아침에 조금 일정이 겹쳐서 스크럼에 적극적으로 참여하지 못했다.

🗒 개선 방향

• 되도록 스크럼 시간에는 일정을 잡지 말아야겠다 ㅠㅠ