Practical Testing 실용적인 테스트 가이드 - Section 01. 테스트는 왜 필요할까

목록

1. 포스팅 개요
2. 본론
     2-1. 테스트가 왜 필요할까?
     2-2. 테스트를 통해 얻어야 하는 것
     2-3. 테스트 코드가 엉망이라면
     2-4. 테스트 코드를 작성하지 않는다면?
     2-5. 테스트 코드가 병목이 된다면?
     2-6. 올바른 테스트 코드가 가져다 주는 것
3. 요약

1. 포스팅 개요

평소 Test 코드에 대해서 좀 딥하게 배워보고 싶었다.
따라서 인프런에서 박우빈님의 Practical Testing: 실용적인 테스트 가이드 강의 섹션 1 테스트는 왜 필요할까?를 학습하며 정리한 포스팅이다.

(포스팅 시간을 1초라도 줄이고자, JPA 기본편 학습을 끝으로 경어체를 생략한다.)

2. 본론

2-1. 테스트가 왜 필요할까?

"테스트는 사실 귀찮다"

기능을 만들기도 바쁜데 테스트를 짜는 것은 귀찮다.
그럼에도 불구하고 테스트 코드를 작성해야하는 이유가 있다.

제품에 대한 코드(이하 Production code)가 있다.
그럼 Production code가 의도한 예상대로 잘 돌아가는지, 버그는 없는지 테스트를 해야한다.
그런데 이런 테스트는 개발자가 아니라, 타 직군에 계신 분들이 수동으로 테스트하는 경우가 있다.
어쨌든 예외에 대한 처리도 잘 되는지 확인했다.

그런데 시간이 갈수록 Production은 점점 확장된다.
그럼 테스트 비용이 더 커질 것이고, 테스트 인력을 구해야되고, 제품이 커지다보니 테스트가 누락되는 경우도 있을 것이다.
그럼 상용 소프트웨어에 문제가 야기될 수 있다. 따라서 다음과 같은 문제가 발생할 수 있다.

• 커버할 수 없는 영역 발생
• 경험과 감에 의존
• 늦은 피드백
• 유지보수의 어려움
• 소프트웨어에 대한 신뢰가 떨어진다.

2-2. 테스트를 통해 얻어야 하는 것

그럼 테스트를 통해 얻고자 하는 것은 무엇일까?
다음과 같은 세 가지가 있다.

• 빠른 피드백
• 자동화
• 안정감

빠른 피드백

다른 사람이 아니라, 내가 의도한대로 프로그램이 동작하는지 빠르게 피드백을 받을 수 있어야 한다.

자동화

매번 사람이 모든 케이스에 대해 검증을 하는 것이 아니라, 기계에게 검증을 맡겨서 자동화되도록 해야한다.

안정감

위와 두 가지 이유를 통해서 소프트웨어에 안정감과 신뢰성을 올릴 수 있어야 한다.

이 세 가지를 얻어야 한다.

그럼에도 불구하고, 테스트 코드로 커버하지 못하는 영역이 있는데, 이런 부분은 사람이 테스트를 해서 확인해야한다.

2-3. 테스트 코드가 엉망이라면

테스트 코드가 엉망이면 어떨까..?

• 굉장히 복잡하거나,
• 뭘 테스트 하는지를 모르게 작성되어있거나,
• Production code를 제대로 테스트 해준다는 느낌이 없고,
• 다른 팀원이 봤을 때 건드리고 싶지 않은 영역이 되거나
• 그냥 "잘 돌아가니까 된 거겠지" 하고 넘기거나 하는 일이 발생할 수 있다.

따라서 테스트 코드 자체를 작성하는 것도 굉장히 중요한 일이지만, 보다 더욱 중요한 것은 Production code를 명확히 지원할 수 있도록 잘 짜야하는 것이다.

2-4. 테스트 코드를 작성하지 않는다면?

• 변화가 생기는 매 순간마다 발생할 수 있는 모든 Case를 고려해야한다.
• 변화가 생기는 매 순간마다 모든 팀원이 동일한 고민을 해야한다.
• 빠르게 변화하는 소프트웨어의 안정성을 보장할 수 없다.

변화가 생기는 매 순간마다 발생할 수 있는 모든 Case를 고려해야한다.

예를 들어 기능 A가 있을 때 테스트 없이 사람이 검증을 하고 이후에 기능 B가 추가되었을 때 과연 이전 기능에 대한 영향은 없는 것인지 고려해야한다.

변화가 생기는 매 순간마다 모든 팀원이 동일한 고민을 해야한다.

그리고 내가 한 고민을 옆의 사람, 옆의 동료 개발자도 동일한 고민을 해야 한다. 서로 공유가 되지 않는다.
(개인적인 생각인데 일을 두번해야한다.)

빠르게 변화하는 소프트웨어의 안정성을 보장할 수 없다.

소프트웨어는 저~ㅇ말 빠르게 변화하는데, 이처럼 빠르게 변화하는 소프트웨어의 안정성을 보장할 수 없다.

2-5. 테스트 코드가 병목이 된다면?

• Production code의 안정성을 제공하기 힘들어진다.
• 테스트 코드 자체가 유지보수하기 어려운, 새로운 짐이 된다.
• 잘못된 검증이 이루어질 가능성이 생긴다.

테스트 자체가 명확하지 않다보니,

1. 무엇을 검증하는지 명확하지 않다.
2. 더 복잡하게 검증을 할 수 있다.
3. 얼렁뚱당 뭉뚱그려서 검증을 할 수 있다.

이와 같은 이러한 잘못된 검증이 이루어질 수 있다.

| 참고로 병목된다는 것은 테스트 코드가 지저분해진다는 의미다.

2-6. 올바른 테스트 코드가 가져다 주는 것

• 자동화 테스트로 비교적 빠른 시간 안에 버그를 발견할 수 있고, 수동 테스트에 드는 비용을 크게 절약할 수 있다.
  • 이는 절약한 리소스를 다른 곳에 더 활용할 수 있다.
• 소프트웨어의 빠른 변화를 지원한다.
• 팀원들의 집단 지성을 팀 차원의 이익으로 승격시킨다.
  • 프로젝트 코드는 공동 자산이다. 따라서 내가 남긴 이 자산들을 다른 사람이 보면서 "A라는 기능에는 이런 테스트들이 필요하구나" 혹은 팀 내의 공유 지식으로 팀 차원의 이익으로 승격해서 관리할 수 있다.
• 가까이 보면 느리지만, 멀리서 보면 가장 빠르다.
  • 귀찮고, 기능 구현도 바쁜데 테스트까지 짜니 속도고 그렇고, 시간을 더욱 많이 쓰게 된다.
  • 하지만, 전체적인 소프트웨어의 주기를 살펴보면 가장 빠르고 확실하다.

3. 요약

테스트 코드가 왜 필요한지 살펴보았다.

결론은 다음과 같다.

테스트는 귀찮다. 귀찮지만, 해야한다.