평소에 그냥 하던대로 로직을 구성하고 실행해보면 일말의 예외없이 에러가 발생했다. 도르마무 찾아가는거 마냥 문제하나 해결하면 그거에 관련된 코드가 말썽을 부린다. 해결하면 또 옆에 있는애가 말썽..
그러다 보니 자연스레 간단한 로직을 먼저 구성하고 성공적으로 실행된다면 그래도 옮겨서 필요한 것만 수정하고 진행하는 방식으로 변경했다. 그리고 컴퓨터공부를 하면서 TDD라는 개념을 알게 되었다.
TDD란?
- Test Driven Development의 약자로 테스트 주도 개발이라고 한다.
- 개발할 때 사용하는 방법중 하나.
- 테스트를 거치며 기능이 정상적으로 잘 작동하는지, 간단한 코드로 검증하는 것.
🤔 보통 어떤 경우에 사용할까?
- 처음해보는 프로젝트일 경우
- 불확실성이 높기 때문에 TDD를 한 번 거쳐가면 좋을 것.
- 고객의 요구조건으로 변경될 가능성이 있는 프로젝트.
- 비슷한 이유로 불확실성 때문.
- 내가 개발을 하고 다른 사람이 유지보수를 하는 경우.
- 다른사람이 코드의 로직을 보고 이해를 못할 수 있기 때문에 TDD사용.
TDD의 효과
- 객체 지향적 코드 개발
- 테스트 코드를 먼저 작성한다면 좀 더 명확한 기능과 구조를 알아볼 수 있음.
- 덕분에 코드의 재사용성을 보장하며 코드를 작성하게 됨.
- 디버깅 시간 단축.
- 테스트를 거치기 때문에 초반에 발생하는 버그들을 어느 영역에서 발생하는지 쉽게 찾을 수 있음.
- 재설계 시간 단축.
- 지속적인 테스트로 마지막 단계에는 무거운 일을 할 경우가 별로 없음.
- 추가 구현 용이.
- 코드의 기능들을 테스트하며 코드의존성에 대한 이해가 있기 때문에 추가로직을 구성하기 편리함.
TDD의 단점
- 가장 큰 단점은 생산성 저하.
- 처음부터 코드를 2번 짜야하고 중간중간에 테스트를 하면서 고쳐나가야 하기 때문.
- 이런 점 때문에 SI 업체는 TDD방식을 잘 사용하지 않음.
후기
코드를 많이 작성해보신 분들이라면 자연스럽게 다들 자기 자신만의 테스트코드가 있다고 생각합니다. 저도 그냥 이게 될까?하면서 옆에 에디터하나 더 띄어놓고 항상 hello world를 남발하고 있으니까요..ㅎ 지금은 학생이지만 앞으로 업무를 보게 된다면 좀 더 신경쓰고 적용해야 할 기술일 것 같습니다.
Reference
