- 구현을 합니다.
- 테스트를 작성합니다.
- 테스트가 잘 안됩니다.
- 테스트를 만들기 위해 구현을 이것 저것 바꿉니다.
- 테스트 합니다.
- 잘 안됩니다.
- 테스트를 작성하는데 구현보다 시간이 많이 걸립니다.
- 하~ 이거 배보다 배꼽이 더 큰거 아닌가요?
네. 배보다 배꼽이 더 크네요. 그럼 생각을 바꿔봅시다.
“난 원래 배꼽을 만들려는 거였어!“ 라고 정신승리를 해봅니다.
테스트는 언제 필요한건가?
테스트는 코드를 검증하기 위해 만드는 거죠. 그러니까 코드를 작성하고 나서 검증을 위해 만들게 되죠.
하지만, 코드 만들고 실행해 보잖아요? 그래서 잘 돌아가는거 확인 하자나요?
그런데도 테스트 코드가 필요한 건가요?
테스트 코드는 코드가 변경될 때 필요한 겁니다.
이미 작성된 코드의 구현 내용이 변경될 때 테스트코드가 있어야 합니다.
1.리팩토링 : 동작은 동일하지만 코드가 달라진다.
일단 코드를 변경하기 전에 정상동작하는 테스트를 만들어 놓고,
리팩토링을 합니다.
리팩토링이 완료된 후에도 기존 테스트가 정상동작 한다면, 잘 바꾼겁니다.
2.구현변경 : 요구사항이 변경되어 코드가 달라진다.
일단 코드를 변경하기 전에 정상동작하는 테스트를 만들어 둡니다.
변경된 요구사항에 맞춰 올바르게 동작해야할 테스트로 변경해 줍니다.
이제 구현을 변경합니다.
구현수정 후 테스트가 정상동작 한다면, 잘 바꾼겁니다.
TDD 할 때는 코드 작성하기 전에 테스트를 먼저 만들라고 하지 않나요?
구현변경 케이스와 같습니다. 다만 변경 전의 코드가 ∅ 이었던 것 뿐입니다.
TDD를 한다는 말은 정신승리 하자는 말입니다.
코드를 작성했다면, 테스트 코드를 만들어서 검증하세요.
테스트 코드를 만드는데 불편한 것이 있다면, 테스트가 용이하도록 코드를 변경하세요.
테스트 코드를 만드는데 작성하기 어렵다면, 테스트 작성이 용이하도록 리팩토링 하세요.
코드 작성시간보다 테스트 코드 작성 시간이 더 많이 소모된다면, 정신승리 해보세요.
“난 원래 테스트를 작성하려고 했던거야!“
내가 작성하는 모든 설계와 구조와 코드가 테스트를 위한 것 같이 느껴 집니다.
마치 테스트가 나의 코드 생산 과정을 주도(drive) 하고 있네요!!
네. 그것이 test에 의해 driven된 development (테스트 주도개발)인 것입니다.