📑 스프레드시트

TDD 의 핵심 철학

<aside> 💡 켄트 백 아저씨가 말씀하시길.. 실패하는 테스트를 먼저 만들고, 그 테스트를 통과하기 위해 코드를 짜는 개발 방법

</aside>

• 사고 방식을 강조
  • 여기서 사고방식이란, 제대로 동작하는지 빠르게 “피드백” 을 받기 위한 사고 방식
    • 결정과 피드백 사이의 갭에 대한 인식
    • 더 나아가 결정과 피드백 사이의 갭을 조절하기 위한 테크닉
  • 결국, 나의 결정이 잘 동작하는지 빠르게 피드백을 얻는 것이 중요한 사고 방식
  • 테스트 코드는 의도치 않은 유용한 부산물
    • 우리가 작성한 코드가 한달 뒤에 나 또는 팀원이 기능을 리팩토링할 경우, 수정한 내용이 기존 기능을 만족하면서 개선된 코드인지 확인하고 싶다면 ?
    • 테스트 코드가 그 지표가 될 것이다.

[TDD] 계산기를 이렇게 구현해볼 수 있지 않을까?

• 내가 해결할 수 있는 가장 작은 영역의 문제부터 풀어 나가고 피드백 받기
  • 단, 핵심은 포함하게
    • 계산기의 가장 기본적인 핵심은 ? ⇒ 사칙연산
• TDD를 체화하게 된다면
  • 단순하게 시작하고
  • 자동화된 테스트를 만들고
  • 새로운 설계 결정을 한 번에 하나씩 도입하기 위해 리팩터링을 할 준비가 된다.
• 베스트 프레틱스에 대한 오해
  • 베스트 프레틱스가 중요한게 아니다.
  • 베스트 프레틱스로 가는 과정을 경험하는 것이 중요하다.

테스트 코드 질문

• 기능구현보다 테스트 코드 짜는게 더 어려울때 어떻게 하는게 좋은가 ?
  • 특정 이벤트 페이지 같이 1주일간 열리는 페이지다.
    • 상황에 따라 테스트 코드가 없는 경우가 많다.
  • 만약, 결제 관련된 페이지라면 ?
    • “돈” 이 걸려있는 로직이잖아요.. ㅎㅎ
    • 테스트 커버리지를 최대한 100% 에 맞추려고 하는 것 같아요. ****