테스트의 필요성

테스트에 관한 시리즈 글을 작성해보려 합니다. 이 글은 본격적으로 글을 작성하기 전에 테스트 코드를 작성하며 제가 느꼈던 것들을 짧게나마 공유해보려고 작성하기 시작한 글입니다.

 

테스트에 대해 알기 전

테스트에 관한 책들을 보기 전, 테스트에 대해 더 알고 싶다는 마음을 가지기 전에 테스트 대한 생각은 아래와 같았습니다.

 

• 테스트 코드는 작성한 코드가 잘 돌아가는지 확인하기 위한 목적의 코드
• 이후에 수정될 될 일이 없는 코드에 대해선 굳이 테스트 코드가 필요 없다
• 테스트 코드를 작성하면 개발 시간이 오래 걸린다

현재의 첫 회사에 입사하기 전에 개발 공부를 할 때 저는 코딩을 할때 테스트 코드를 작성하지 않고 코딩을 했었습니다.

필요한 기능을 구현할 때 System.out.println() 을 이용하여 값을 출력, 확인을 했었고 제대로 기능이 구현된 이후에는 값 출력하는 메서드를 삭제하곤 했습니다.

 

테스트 코드를 자주 만들지도 않았지만, 만들었다 해도 그 테스트 코드는 단순히 현재의 기능이 잘 돌아가는지를 검증하는 용도의 테스트 코드 였습니다. 그리고 테스트 코드를 작성하면 개발시간이 오래 걸려 개발을 빨리 할 수 없다는 생각을 가지고 있었습니다...

 

테스트 공부를 시작하며

하지만 입사 후에 맡게된 프로젝트에서 여러 테스트 코드를 만났고, 그 테스트 코드를 이용하여 기능을 리팩토링하는 작업을 시작하며 테스트의 필요성, 테스트의 가치에 대해 조금이나마 깨닫게 되었습니다. 그리고 테스트에 관한 책을 읽기 시작하고 직접 테스트 코드를 작성하면서 부터는 테스트 코드의 작성과 관리가 중요하다는 사실을 깨닫고 있습니다. 일단 제 짧은 테스트 인생? 에서 깨닫게 된 테스트의 가치는 아래와 같습니다.

 

• 테스트 코드는 실수를 바로 잡아준다.
• 테스트 코드를 작성하면 개발시간이 단축된다.
• 테스트 코드가 존재하면 이후에 수정 및 개선을 하기 쉬워진다.
• 테스트 코드를 작성하면 실사용에 적합한 설계를 이끌어내준다.(다음 포스팅)
• 구현하고자 하는 기능의 불필요한 코드를 제거해준다.(다음 포스팅)

단순히 테스트 작성을 통해 깨닫게 된 것과 TDD(테스트 주도 개발) 를 시도해가며 깨닫게 된것이 다소 섞여 있는 내용입니다. 이번 글에서는 TDD 에 대한 내용은 배제하고 단순하게 테스트를 작성하며 느꼈던 경험을 공유해보려 합니다.

 

테스트 코드는 실수를 바로 잡아준다 → 개발시간 단축, 기능 변경을 쉽게 해준다

 

 테스트 코드를 작성하면 해당 기능이 원하는 대로 잘 돌아가는지 검증하기 수월합니다. 이것은 테스트를 먼저 작성하며 코딩을 하는 방식이든 코딩 이후에 테스트 코드를 작성하는 방식이든 동일하게 적용됩니다. 작성한 자동화된 테스트 코드를 실행하기만 하면? 바로 결과의 성공 실패 유무로 알 수 있기 때문입니다. 실패를 했을 때 그것을 성공으로 이끌어 가기만 하면 실수를 바로 잡을 수 있습니다. 그리고 실수를 바로 잡을 수 있기 때문에 개발시간 또한 단축시킬 수 있습니다.

 

 우리가 개발하는 기능들은 대부분의 경우에 변경될 가능성이 있습니다. 요구사항이 변하거나, 구조개선의 이유 등 여러 이유로 변경될 가능성이 존재합니다. 그러면 기능 수정을 어떤식으로 할 것이냐? 웹 어플리케이션을 예로 들어보겠습니다. 기능 수정을 조금 하고 WAS 를 실행해서 수정한 기능과 관련된 부분까지 링크를 타고 들어간 이후에 직접 클릭해가며 기능이 제대로 변경 되었는지 테스트를 할것인가요?

 

 생각만해도 시간이 오래 걸릴것 같습니다. 만약 해당 기능에 대한 단위 테스트 코드가 존재한다면? 해당 기능을 변경한 이후에 테스트 코드를 실행해보고 실패하면 다시 코드를 수정하면 됩니다. 또 실패하면 ? 수정 후 성공시키면 됩니다. 이런식으로 테스트코드가 존재하면 하나의 기능을 빠르게 테스트 해 볼 수 있습니다.

 

 그러면 전체적인 개발 시간을 단축시켜 줄 수 있습니다. 또한 테스트 코드의 존재가 기능의 변경시 이전과 동일하게 동작하는지를 검증(회귀테스트) 할 수 있게 해주기 때문에 기능 변경 또한 쉽게 할 수 있도록 도와줍니다.

 

 물론 이것은 테스트 코드를 잘 작성했을 때 적용되는 원칙입니다. 기능의 비정상적인 동작 원인이 테스트 범위 내에 존재 했을 때만 적용이 됩니다. 여러가지를 한번에 테스트 하는게 아닌 오직 하나만 테스트 하기 위한 단위 테스트 이어야 하고 환경 및 외부 시스템에 종속되지 않아야 하며 필요하다면 대역을 세워서 적절하게 고립시킨 테스트 여야 합니다. 또한 blah, blah~

 

테스트 코드를 잘 작성하는 방법과 관련된 글은 이후에 작성하겠습니다. 여기에선 테스트 코드가 존재가 실수를 잡아주고 개발 시간을 단축시켜 준다는 사실만 알아주셨으면 좋겠습니다.

 

다음 글에서

이번 글은 시리즈 글을 쓰기 전에 도입부 정도의 목적으로 쓴 글입니다. 그런데 쓰고 나서 보니 적절한 그림이 있었다면 더 좋았을 것 같네요... 이후 글에선 보완하겠습니다.

 

오랜만에 글을 작성하는 것이라 다소 정신 없는 글입니다... 또한 시리즈로 글을 쓰려다 보니 생각보다 어려운 것 같습니다. 조금씩 성장하겠습니다...

 

이후에 테스트에 관하여 쓰려고 계획중인 글은

 

• 좋은 테스트 코드란?
• TDD - '통과할만큼만, 필요한만큼만'
• 테스트가 주도하는 리팩토링 예시

일단 3개 입니다. 좀 더 나은 글을 쓰기 위해 노력하겠습니다.