TDD를 부숴주마

유튜브나 인터넷에 TDD 자료를 보다가 열 받아서 만들었다TDD는 구리다, 왜 구린지 시리즈에서 설명하고 테스트의 목적TDD의 올바른 해석, 내가 생각하는 좋은 테스트 순서대로 연재하겠다.시리즈 초반엔 테스트와 관계 없어 보이는 내용이 포함되는데 인내심을 가지고 시리즈

원래는 차근차근 빌드업 쌓고 결론을 뒤에 박으려고 했다.근데 그냥 시작할 때 박아두고, 시리즈 내내 반복해서 때리기로 했다.테스트는 계약을 검증하는 살아있는 검증문서이다.이 한 줄만 제대로 이해하면, TDD가 왜 그렇게까지 신성시될 필요가 없는지 바로 보인다.테스트 작

무엇을 테스트 할 지 모르기 때문이다.무엇을 테스트 할 지 모르기 때문에 TDD가 유행했다고 생각한다.TDD는 레드-그린-리팩토링과 같은 잘못된 방법을 설파한다.Red (실패): 구현하고자 하는 기능의 테스트 코드를 먼저 작성한다. 테스트는 실패해야 한다.Green (

테스트는 “구현체”가 아니라 계약(인터페이스) 을 검증한다.그래서 계약만 잘 정의되어 있으면 구현체가 아직 없어도 테스트를 먼저 만들 수 있다.관계는 이렇다.인터페이스(계약) --- 테스트(검증서)인터페이스(계약) --- 구현체(실제 동작)즉, 테스트는 구현체가 아니라

벨로그에서 글을 쓰기 전에 인기글을 읽는 편이다. 근데 회고를 보는데 TDD 얘기가 있더라.개발 블로그 글 볼 때 TDD는 진짜 하루에 한 번씩은 보는 것 같다.그때마다 열 받는다. 오늘도 벨로그 글은 안 쓰려고 했는데 TDD 글을 봐서 열 받아서 쓴다.테스트 목적은

assert문을 제외한 부분은 단위 테스트에서 setup이다.이 부분은 구현 부산물이라서 의미론적으론 테스트에서 중요하지 않다.하지만 테스트를 작성 할 때 신경써야하는 부분이 setup 과정이다.흔히 말하는 flaky test의 경우 setup 과정의 문제이기 때문에