출처: Practical Testing: 실용적인 테스트 가이드

1. 학습 내용 요약

• 수동으로 테스트할 경우

  • 누락되는 케이스 발생

     

  • 늦은 피드백

  • 유지보수 어려움

  • 소프트웨어 신뢰도 낮아짐

• 테스트 코드를 작성하지 않는다면

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

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

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

• 테스트 코드가 병목이 된다면

  • 프로덕션 코드의 안정성을 제공하기 어려움

  • 테스트 코드 자체가 유지보수하기 어려운, 새로운 짐이 되어버림

  • 잘못된 검증이 이루어질 가능성이 생김

• 올바른 테스트 코드는

  • 자동화 테스트로 비교적 빠른 시간 안에 버그 발견 가능, 수동 테스트에 드는 비용 절약

  • 소프트웨어의 빠른 변화 지원

     

• 단위 테스트

  • 작은 코드 단위(클래스 or 메서드)를 독립적으로 검증하는 테스트

  • 검증 속도가 빠르고, 안정적

     

• 테스트 케이스 세분화

  • 해피 케이스

  • 예외 케이스

  • 경계값 테스트 → 범위(이상, 이하, 초과, 미만), 구간, 날짜 등

• 테스트하기 어려운 영역을 구분하고 분리하기

  • 현재 일시와 같이 테스트가 어려운 코드가 들어오는 경우

  • 전체가 테스트하기 어려워질 수 있음

  • 테스트가 어려운 부분을 외부로 분리

     

• 테스트하기 어려운 영역

  • 관측할 때마다 다른 값에 의존하는 코드

    • 현재 날짜/시간, 랜덤 값, 전역 변수/함수, 사용자 입력 등

  • 외부 세계에 영향을 주는 코드

    • 표준 출력, 메시지 발송, 데이터베이스에 기록하기 등

• 테스트하기 좋은 함수

  • 순수함수 (pure functions)

    • 같은 입력에는 항상 같은 결과

    • 외부 세상과 단절된 형태

    • 테스트하기 쉬운 코드

• Test Driven Development

  • 프로덕션 코드보다 테스트 코드를 먼저 작성하여 테스트가 구현 과정을 주도하도록 하는 방법론

• TDD의 3단계

  • Red

    • 실패하는 테스트 작성

  • Green

    • 테스트 통과

    • 최소한의 코딩

       

  • Refactor

    • 구현코드 개선

    • 테스트 통과 유지

• 선 테스트 작성, 후 기능 구현

  • 복잡도가 낮은, 테스트 가능한 코드로 구현할 수 있게 해줌

  • 쉽게 발견하기 어려운 엣지 케이스를 놓지지 않게 해줌

  • 구현에 대한 빠른 피드백 가능

  • 과감한 리팩토링 가능

     

• BDD 스타일로 작성

  • Behavior Driven Development

  • TDD에서 파생된 개발 방법

  • 함수 단위의 테스트에 집중하기보다, 시나리오에 기반한 테스트케이스(TC) 자체에 집중하여 테스트

     

• BDD Tool

  • Given

    • 시나리오 진행에 필요한 모든 준비 과정 (객체, 값, 상태 등)

  • When

    • 시나리오 행동 진행

  • Then

    • 시나리오 진행에 대한 결과 명시, 검증

• 통합 테스트

  • 여러 모듈이 협력하는 기능을 통합적으로 검증

  • 일반적으로 작은 범위의 단위테스트만으로는 기능 전체의 신뢰성 보장 불가

  • 풍부한 단위 테스트 & 큰 기능 단위를 검증하는 통합 테스트

  ---

  2. 미션 회고

  Day 12. 주어진 코드에 대하여 단위 코드를 작성해보는 미션이었다. 직접 테스트 코드를 작성해보는 건 이번이 처음이었다. 이번 미션에서 어려웠던 부분은 테스트하기 어려운 부분을 통제하는 것이었다. 예를 들어 static으로 클래스 내부에 선언된 Scanner의 경우 입력값을 두 번 이상 넣기가 어려웠다. Scanner를 변수로 빼는 부분도 고려해볼 수 있었지만, 원래 코드의 의도를 테스트때문에 해치는 것 같아 망설이게 되었다. 다행히 강의 뒷편에서 이러한 고민을 다루는 부분이 있는 것 같아 학습 후에 이번 미션에서 고민했던 것들을 확인해 볼 수 있을 것 같다.

   

  ---

  3. KPT

  • Keep

    • 미션을 해결하고 다른 사람들의 코드들을 보면서 놓쳤던 케이스들을 확인하였다.

  • Problem

    • 테스트 환경을 제어하는 부분들 중 어려운 것이 많았다.

  • Try

     

    • 강의 후반부에서 지금까지 생긴 궁금증들을 많이 다루고 있어서, 나중에도 기억할 수 있도록 정리하면서 들어야겠다.

  ---

  4. 느낀점

  3주차 테스트 코트 강의가 시작되었다. 워밍업 클럽에 참가한 이유 중에 하나이기도 하다. 이전에 서비스 코드는 작성해 본 적이 있지만 단위 테스트, 통합 테스트는 작성해 본 적이 없었다. 테스트를 작성하지 않았던 이유는 강의 초반에서 강사님이 언급했던 것처럼 '귀찮음'이 가장 컸었다. 그러나 여러 테스트 코드를 작성하고, 전체 테스트를 돌려 모두 성공했을 때의 기쁨은 그 귀찮음을 충분히 보상해 주는 것 같다. 또한, TDD 방식으로 구현을 연습해보았는데, 테스트를 먼저 작성하고 코드를 작성하는 방식이 다소 낯설었다. 그러나 기존의 구현 우선 방식보다 확실히 여러 엣지 케이스를 떠올리기가 쉬웠다. 이 방식을 습관화하여 자연스럽게 활용할 수 있도록 노력해야겠다.