TDD 의 장점들은 역시 많지만 그 중에서도 제일 좋은 점은 작동하지 않는 코드를 미리 막을 수 있다는 점인데, 그걸 나만의 언어로 말하자면 TDD 한테 즉각 피드백을 받을 수 있다는 것이다. 그것도 기능별로, 코드 한 줄 한 줄 피드백을 받을 수 있다. 그리고 홀맨님이 말씀하셨듯 테스트 코드는 인수인계서 같은 것이기 때문에 남들이 내 코드를 보든, 내가 나중에 시간이 지나서 다시 보든 과거의 히스토리나 개발 과정들을 쉽게 상기할 수 있다.
물론 이런 장점들을 더 와닿는 상태로 만들기 위해서는 내가 TDD 에 익숙해져야 가능한 일이다. 아직은 쉬운 알고리즘 문제에 테스트 코드를 적용하는 것만 겨우 적응한 상황이지만, 어제 til 에 올렸던 것처럼 이 작업 사이클을 반복하다 보면 점점 큰 단위로도 해낼 수 있을 것이라고 생각한다.
그리고 처음에는 테스트 코드를 작성하면서, '굳이' 실패하는 코드를 테스트로 작성해야하나? 바로 제대로 동작하는 GREEN 용 코드를 생각해서 테스트로 돌려보면 안되나? 라고 생각했다. 하지만 다시 생각해보니 실패하는 코드를 확인 해야 다음에 성공한 코드를 작성한 후 그것이 GREEN 을 띄워줬을 때 그 코드가 제대로 동작한 것을 믿을 수 있는 것이라는 생각이 들었다. 다시 말해 실패하는 것을 확인 해야 다음 코드가 제대로 동작한 것임을 확신할 수 있다. 개발자에게는 '굳이, 또 굳이 해보기'가 필요한 것을 잊지 말자!!!!
'TIL' 카테고리의 다른 글
생각의 전환 (22.09.17 TIL) (0) | 2022.09.17 |
---|---|
Bounded Context (22.09.16 TIL) (0) | 2022.09.16 |
문제-해결-반성의 성장 싸이클 (22.09.14 TIL) (0) | 2022.09.14 |
코딩도장 시간 활용하기 (22.09.13 TIL) (1) | 2022.09.13 |
작은 성공 만들기 (22.09.12 TIL) (0) | 2022.09.12 |
댓글