TestCrunch에 올라온 “테스트는 누가해야 하는가?”에 대한 트랙백을 위한 글 입니다.
Nikkei Electronics 2007년 4월 23일 자에 나온 “공들여 만드는 소프트웨어, 검증하기 쉬운 설계로“라는 제목의 자료에도 나오는 그림 중에 이런 말이 있습니다.
” 아니 이렇게 테스트하기 어렵게 설계하면 어떻게 해요!”
- 테스터
아직 우리나라 대부분의 업체에서는 테스터가 이렇게 이야기 할 수 있는 곳은 없을 것입니다.
“아니 이렇게 생산하기 어렵게 설계하면 어떻게 해요!”
- 생산담당자
생산하기 힘드니 다시 설계하라는 이야기를 하는 곳은 있을 수도 있을 겁니다.
생산을 고려해서 설계를하고 개발하라는 것입니다.
Application/Game 개발자분들은… 디자이너분들과 이런 이야기 자주 나누지 않습니까?
“이런 디자인/컨셉은 개발하기 힘들다… 당신들이 개발을 안해봐서 그런가 본데… 이건 너무 힘들어요…”
- 개발자
테스트도 개발의 한 부분이고 중요하다는 것을 개발자가 더 잘 알고 있을 것입니다.
그러나 오랜 관습과 바쁘다는 현실에서 변화하기가 쉽지 않은 것 같습니다.
개발자 테스트하면 자주 등장하는 TDD는 테스트보다는 Design적인 측면이 더 중요하게 생각되는 것 같습니다.
Test Driven Development 보다는 Design의 의미가 강하다고 생각됩니다.
TDD에 의해서 모든 테스트가 끝나지 않습니다. TDD는 품질에 대한 최소한의 요구사항이라고 생각합니다.
“Clean code that works!"- Test Driven Devlopment 에서 Kent Bect
TDD는 분석/설계 도구이지 테스트 도구가 아닙니다. TDD를 통해서 얻는 Code Coverage는 TDD의 목적이 아니라고 생각됩니다. 부수적인 이득이라고 봐야겠죠.
TDD의 궁극의 목적은 “Clean Code That Works”라고 봅니다.
테스트를 위하여 API 뿐만 아니라, 시스템 전체를 고려한 설계와 개발이 이루어지고 함께 테스트가 진행되어야 더욱 빠른 개발을 할 수 있다고 생각합니다.
Tags: tdd, TestCrunch, 테스트
