15주차 - 7.41 테스트로 코딩하기

[DaehunGwak]

진도

• 7.41 테스트로 코딩하기

일시

• 2023.03.26.(일) 21:00

[DaehunGwak]

• 테스트는 버그를 찾기 위한 것이 아니다?!!

  • 테스트의 주요 이점은 테스트에 대해 생각하고 테스트를 작성할 때 생긴다!?
  • 테스트가 코딩을 주도한다
    • 테스트가 코드의 첫번째 사용자다 → 사용자의 관점으로 테스트할 메소드를 검토하게 됨
    • 테스트 편하게 짜다보니 결합도를 낮게지게 됨
    • 코딩 시작전 경계조건과 예외 조건에 대해 생각해보게 된다

• 테스트 주도 개발 (TDD)

  • TDD 노예… 테스트 커버리지 100%… 중복테스트… 밑에서부터 시작하여 위로 올라가는 방식 설계로 진행
  • 기본적으로는 TDD 를 실천하되, 큰 그림을 살피는 것을 잊지 말기
  • 전체 문제 파악하기 힘들 때 작은단계를 밟는 테스트를 할 수 있지만, 코딩하는 진짜이유를 무시한 채 계속해서 쉬운 문제들만 만지작거리도록 유도할 수 있음 ㅠ
  • 상향식이나 하향식에 매몰되지 말고 결국 종착지를 생각하고 코딩하라

• 임시 테스트로 넘어가지 말고 이를 단위 테스트 코드로 남기도록 하자

• 소프트웨어를 테스트하지 않으면 사용자가 테스트하게 된다

• 테스트 문화

  • 테스트 먼저: TDD 도 포함되는 전략, 하지만 테스트를 먼저 쓰기가 어렵거나 의미가 없을 수 있음
  • 코드와 테스트를 함께: 코드를 조금 작성하고 이리저리 만지작 거리다 테스트 작성
  • 나중에 테스트: = 테스트 하지 않음..

• 45년의 업력과 30년 테스트하고나니 자동적인 테스트 사고방식 ㄷㄷ (3년은 구석에서 조용히 테스트 짜야겠다)

[minkukjo]

느낀 점

• 테스트 작성할 때 이름 보고 적당한 컬럼 찾아서 요구사항에 만족하는 코드를 작성하는 이야기가 꽤나 공감됐다 (ㅋㅋㅋㅋ)
• 한 때 유행했던 TDD... 그러나 TDD가 중요하다기 보다는, 테스트를 작성하는 것이 중요한게 아닐까?
• TDD를 하다보면 불필요한 것 까지 테스트하게 된다. 그것이 정말 테스트로써의 의미가 있을까?
• 저자 또한 무조건적으로 TDD가 옳다고 말하지 않는 점이 좋았다.
• 나중에 테스트? 이건 진짜 환상이 맞다. 최소한 코드와 테스트를 같이 가져가려고 노력하자.
• "여러분의 소프트웨어를 테스트하라. 그렇지 않으면 사용자가 테스트한다" 라는 구절이 특히 마음에 들었다.

[donghoon-song]

테스트의 이득은 테스트를 실행할 때가 아니라 작성할 때 생긴다.

테스트가 코드의 첫 번째 사용자다.

테스트하기 좋게 만들면 결합도도 낮아진다.

테스트, 설계, 코딩 전체가 프로그래밍이다.

여러분의 소프트웨어를 테스트하라. 그러지 않으면 사용자가 테스트하게 된다.

작은것부터 테스트하자. 일단 쓰자. 든든함.

테스트 경험 30년…ㄷㄷ

유닛 테스트로 충분히 할 수 있는걸 e2e로 넘기지 말 것.

테스트를 진짜 써봐야 아는 거 같다. 아주 쉬운 컴포넌트라도, 유틸 함수라도 쓰는 편이 훨씬 도움이 많이 된다. 써보면 얼마나 많은 것들에 의존하고 있는지 깨닫게 된다.

[Edwin222]

• 테스트의 이점은 버그를 찾기 위한 것이 아니라, 테스트를 고민하고 생각할때 생긴다

• 예시가 좋았다. 진정한 테스트 드리븐이란 이런게 아닐까?

• TDD발상의 핵심은 반복 주기가 짧아야 한다는 것

• 테스트 커버리지 100%의 노예가 되지 말 것

• 상향식 or 하향식이 아니라 end to end로 만들기

• 단위 테스트는 계약을 지키는지 보는 테스트

• 임시 테스트를 했으면 단위 테스트에 합류 시켜라