TDD란
- Test Driven Development의 약자이며 한글로는
테스트 주도 개발로 번역됩니다. - TDD는 기존의
설계 -> 코드개발 -> 테스트의 절차가 아니라설계 -> 테스트케이스 작성 -> 코드개발 -> 리펙토링의 과정으로 개발을 진행하는 걸 말합니다.- 테스트 케이스를 만들고 이를 통과하는 코드를 추가하는 걸 반복해 전체 시스템을 만드는 걸 얘기합니다.
TDD방법이 효율적인 경우
- 코드의 변경이 많을 것으로 예상될 때
- 처음 도전하는 주제의 프로젝트일 때
- 고객의 요구조건이 자주 변경되는 프로젝트일 때
- 다른 사람이 코드를 사용할 것으로 예상될 때
JUnit
- JUnit은 자바의 유닛 테스트 프레임워크로 TDD를 돕는 도구 중 하나입니다.
개인적인 생각
- 인터넷의 JUnit 예제는 대부분
assertEquals(숫자,계산기 메서드로 구현한(a+b))수준의 간단한 검증들이었다. 직접 해보지 않았기에 자세한 건 모르지만 내가 생각한검증과는 거리가 있는 것 같다. - 개발자가 얼마나 많은 경우의 수를 예상할 수 있을까? 예상하지 못한 경우는 언제든지 나오기 마련이고, 그렇게 새로운 경우를 만나서 사후 디버깅을 하게 된다면 결국은 기존의 방법론과 같아지는 거 아닐까?
- 실제로 개발속도의 향상이 이뤄질까? 나의 관념속에서는 실체가 존재하지 않는 것의 예시를 먼저 만드는 것이 잘 그려지지 않는다. 그래서 TDD가 좋은건지 직접 경험해 보고 싶기도 하다.
- 어떻게 하면 TDD방법론을 경험해 볼 수 있을까? 언젠가 회사에서 프로젝트를 진행할 때 TDD를 경험해보고 싶다.
- 코딩테스트 문제를 풀 때 이론적으로 기능을 구현하려 하지 않고 테스트케이스를 비벼서 통과를 했던 적이 몇번 있는데 이런게 TDD의 실체라면 실망스러울 것 같다.(효율적인 TDD는 내가하는 이런게 아니겠지)
- 이런 느낌인가? '바람을 피하려고 벽을 세웠을 뿐인데, 모든 바람을 막으려고 하다보니 집을 짓게 되었더라.'
References
기록하고 정리하는 걸 좋아하는 백엔드 개발자입니다.