TDD(Test Driven Development)
코드는 두 가지로 나뉠 수 있다. 1. 프로덕션 코드, 2. 테스트 코드.
프로덕션 코드란, 사용자가 실제로 사용하게 될 코드를 의미한다. (우리가 코드를 생각하면 떠올리는 것들!)
테스트 코드란, 프로덕션 코드를 테스트하기 위한 코드이다.
TDD는 뭘까?
TDD = TFD(Test First Development) + Refactoring 이라고 한다.
유추할 수 있듯이, 테스트를 먼저 작성하면서, 리팩토링으로 보강하는 개발 방법이다!
- TDD란 프로그래밍 의사결정과 피드백 사이의 간극을 의식하고 이를 제어하는 기술이다. - 켄트벡, Test Driven Development by Example 중
- TDD의 아이러니 중 하나는 테스트 기술이 아니라는 점이다. TDD는 분석 기술이며, 설계 기술이기도 하다. - 켄트벡, Test Driven Development by Example 중
그래서 TDD를 왜 하는데?
테스트를 먼저 하면 무슨 이점이 있을까?
우선 테스트 코드가 중요한 것은 모두가 알고 있는 사실이다.
내가 작성한 코드에 대한 검증, 보증 역할을 수행해준다. 또한 변화에 대한 두려움을 줄여준다.
TDD가 좋다는 건 알겠는데 어떻게 해야할까?
1. 실패하는 테스트를 작성한다.
2. 테스트를 통과하기 위해 프로덕션 코드를 수정한다.
3. 리팩토링 과정을 통해 프로덕션 및 테스트 코드를 보강한다.
TDD를 진행하면서 따라야 할 원칙은 다음과 같다.
- 원칙 1 - 실패하는 단위 테스트를 작성할 때까지 프로덕션 코드(production code)를 작성하지 않는다.
- 원칙 2 - 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
- 원칙 3 - 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
즉, 실패하는 테스트를 먼저 작성하고, 컴파일이 안되는 테스트여서는 안되며, 테스트를 통과할 정도로만 프로덕션 코드를 작성한다.
단, 리팩토링 단계에서 기존 테스트 코드가 작동 불가능이 되면 안된다.
그것은 기능에 대한 변화이지, 리팩토링이 아니다!
답해보기
- 내가 TDD, 리팩토링을 하는 이유는 무엇인가?
TDD를 최근에 접했기 때문에 아직까지는 큰 효용을 느끼고 있지는 않다. TDD를 수행하면서 개발하는 것에 대한 비용이 크다고 느꼈기 때문이다. 또한 TDD 사이클에 익숙해지기까지 시간이 꽤 걸릴 것 같기도 하다.
사실 이전까지 테스트 코드를 작성하면서 다음과 같은 느낌을 많이 받았었다.
'프로덕션 코드를 작성하고, 테스트 코드도 작성하는 것이 나라면, 테스트에 진정한 의미가 있을까?'
프로덕션 코드 구현을 다 마친 후에 테스트 코드를 작성하는 것은 단순한 이차검증에 불과하다.
무엇을 모르는지 모르는 상황에 마주치게 된다. 또한 테스트 코드가 프로덕션 코드를 뒤따르는 것은 유연하지 않다.
의존성의 방향이 테스트 코드 -> 프로덕션 코드 이기 때문에, 프로덕션 코드를 수정하면서 테스트 코드까지 수정되는 상황이 많았다.
그렇기에 TDD가 필요한 것이 아닌가? 생각한다. 어떻게 보면 인간의 불완전함을 이해하고 그것을 해소시키기 위한 방법론일 수도 있겠다.
따라서 앞으로 더 연습해보고, 글도 많이 읽어볼 예정!
- 기존에 구현하는 방식과 TDD로 코드를 구현할 때 어떠한 차이를 느꼈는가?
TDD로 구현하니, 우선 개발 속도가 느리다.. ㅎㅎ
하지만 코드가 안전하다는 느낌을 받았다. 구현에 대한 빠른 피드백을 받기 때문에, 기초공사가 탄탄하다는 느낌을 받았다.
또한 메소드 및 클래스에 필요한 기능만 남는다.
TDD의 기본 원리가 '테스트를 통과할 정도로만 프로덕션 코드를 작성하는 것' 이기 때문에 불필요한 코드가 들어갈 틈이 없다.
하지만, 다른 객체들과 엮여 있는 메소드, 즉 복잡한 테스트를 수행하기에는 조금 어려웠던 것 같다.
'어느정도의 실패할 테스트를 작성할 것인가?'를 결정하기가 어려웠다.
- 미션을 진행하면서 리팩토링을 경험하며 어떠한 어려움을 겪었는가?
리팩토링을 하면서, 가장 어려웠던 점은 리팩토링을 하는 것도 나 자신이라는 점이다.
내 코드를 보면서, 무엇이 잘못되었는지, 어떤 부분이 개선되어야 할지 쉽게 눈에 들어오지 않는다.
어찌보면 당연한 것이, 내가 리팩토링하려고 보고 있는 코드도 며칠 전의 '나'가 작성한 것이기 때문이다.
며칠만에 사고가 바뀌지 않는 한, 리팩토링도 마찬가지로 쉽지 않다.
객관적으로 코드를 볼 수 있는 방법이 있을까 고민이 된다. 리팩토링에서도 주관이 많이 들어간다는 점이 어려웠다 :(
- 리팩토링 과정에서 어려움을 줄이기 위해 어떠한 시도를 해볼 수 있는가?
페어 프로그래밍을 적극 응용하거나, 다른 크루들에게 의견을 물어볼 수도 있겠다.
또한 내가 당연하다고 알고 있던 지식이 맞는지 검증해볼 수도 있겠고, 새로운 지식을 배워 적용해볼 수도 있을 것이다.
'우테코 5기' 카테고리의 다른 글
[레벨 1 미션] 자동차 경주 미션 회고 (0) | 2023.02.18 |
---|---|
[레벨 1 미션] 자동차 경주 학습 기록 (0) | 2023.02.18 |
[레벨1 강의] 단위 테스트, 코드 품질 (0) | 2023.02.10 |
[우테코] 우아한테크코스 백엔드 5기 최종 합격 후기 (24) | 2022.12.31 |
[우테코] 우아한 테크코스 5기 1차 합격 + 최종 합격 (1) | 2022.12.15 |