소프트웨어 개발은 테스트의 연속입니다.
일일이 결과를 출력하든, 브레이크 포인트를 잡아서 한 단계씩 확인하든 어떤 방식을 사용하든 만든 코드가 의도한 대로 돌아가는지 확인해야 합니다.
테스트를 누군가 해준다면 나는 코드에 집중할 수 있을 거라는 생각도 했었었지만 리뷰를 쓰며 드는 생각이 그러려면 분신술을 쓸 수 있어야겠다는 생각이 드네요.
배보다 배꼽이
체계적이고 효율적인 테스트를 추구한다고 합니다만 내용을 읽다 보면 '이 정도까지 한다고'라는 생각이 들 수 있습니다.
자판기에서 음료를 뽑듯이, 누가 하더라도 누락되는 부분 없이 기본 테스트 구성을 만들 수 있다는 데서 시작합니다.
기본 구성 위에 다양한 테스트 대상을 적용하며 테스트를 다듬어 나갑니다.
테스트를 개발에 적극 활용한다 정도로 생각하면 오산입니다.
TDD는 그 용도가 아닙니다
테스트를 얘기하는 곳이면 빠지지 않고 등장하는 개념이 테스트 주도 개발(TDD)입니다. 워낙 많이 얘기하고 권장하는 개발 방식이라 실제 적용하지 않더라도 언젠가는 도입할 거라 생각하는 개발 방식입니다. TDD를 사용하지 않으면 살짝 뒤처진 듯한 느낌마저 가지기도 합니다.
대략 알려진 방식이 맞지만 TDD가 하는 역할의 비중이 생각만큼 크지 않다는 얘기를 듣는 순간 멈칫하게 됩니다.
TDD가 맡고 있는 개발 유도는 전체 테스트 가운데 전반부 리더 역할이라고 볼 수 있습니다.
테스트의 전부가 아니라는 얘기죠.
부러운데요
이 책은 공과대학교 소프트웨어 테스트 과정에서 다루는 강의 내용을 바탕으로 하고 있다고 합니다.
대학과정에서 이미 이 정도로 테스트를 진지하게 다루고 고민하는 훈련을 받고 있다는 사실이 부러울 따름입니다.
'길을 아는 것과 걷는 것은 다르다'는 명대사가 있습니다.
지금까지는 길을 몰라 헤매었다면 이제 이렇게 든든한 길잡이가 있습니다.
길을 걸어가는 일만 남은 거죠.
이 책이 든든한 파트너가 되리라 생각합니다.
소프트웨어 개발을 한다면 어떤 식으로든 테스트를 합니다. 그게 단순히 결과 출력하여 확인하는 거라 할지라도.
사람이 부지런하게 테스트하는 것 말고, 컴퓨터가 테스트하도록 하고 느긋하게 지켜보는 게 어떨까요.
