2carrot84
by 2carrot84
2 min read

Categories

  • lecture

Tags

  • test
  • test code

오늘은 새로 이직한 회사에서 다행히(?) 테스트 코드를 많이 활용하고 있어, 그간 소홀히 했던 테스트 코드에 대해 공부를 좀 해보자는 마음에 새로 신청한 강의 내용을 간단히 정리해 보고자 합니다.

유트브 채널 개발바닥의 ‘배달의민족 합격한 신입 개발자 이력서 공개합니다.’ 라는 영상으로 유명한 박우빈님의 인프런 강의 Practical Testing: 실용적인 테스트 가이드 를 듣고 내용을 정리한 것이니 참고 부탁드립니다.

테스트 코드에 대해 실무적으로 경험이 적은 저 같은 개발자나 신입 개발자 분들을 위한 실무 중심의 강의라고 하니 많은 관심 부탁드립니다.

섹션 1은 강의 인트로 내용이라 섹션 2부터 내용을 정리해 보았습니다.

섹션2. 테스트는 왜 필요한가?

테스트는 왜 필요한가?

  • 이득
    • 빠른 피드백
    • 자동화
    • 안정감
  • 테스트 코드를 작성하지 않는다면
    • 변화가 생기는 매 순간마다 발생할 수 있는 모든 케이스를 고려
    • 변화가 생기는 매 순간마다 모든 팀원이 동일한 고민
    • 빠르게 변화하는 소프트웨어의 안정성을 보장할 수 없다.
  • 올바른 테스트 코드는
    • 자동화 테스트로 비교적 바른 시간 안에 버그를 발견할 수 있고, 수동 테스트에 드는 비용을 크게 절약할 수 있다.
    • 소프트웨어의 빠른 변화를 지원한다.
    • 팀원들의 집단지성을 팀 차원의 이익으로 승격시킨다.
    • 가까이 보면 느리지만, 멀리 보면 가장 빠르다.

섹션3. 단위 테스트

수동 테스트 vs 자동화된 테스트

  • 자동화된 테스트 코드를 통해 사람의 개입을 줄이자
  • 수동 테스트의 경우 테스트 코드만 보고 테스트 하고자 하는 의도와 결과를 예측할 수 없다.

Junit5 로 테스트 하기

  • 단위 테스트
    • 작은 코드 단위를 독립적으로 검증하는 테스트
      • 클래스 또는 메서드 단위
    • 검증 속도가 빠르고, 안정적이다
  • Junit5
    • 단위 테스트를 위한 Java 테스트 프레임워크
    • XUnit - Kent Beck
  • AssertJ
    • 테스트 코드 작성을 원활하게 돕는 테스트 라이브러리
    • 풍부한 API, 메서드 체이닝 지원

테스트 케이스 세분화하기

  • 질문하기 : 암묵적이거나 아직 드러나지 않은 요구사힝이 있는가?
  • 해피케이스, 예외케이스에 대한 경계값 테스트가 효과적
    • 범위(이상, 이하, 초과, 미만), 구간, 날짜 등

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

  • 테스트하기 어려운 영역을 구분하고 분리하기
    • 테스트 하고자 하는 영역에 집중하여 테스트가 어려운 영역은 외부로 분리하도록 설계를 변경
      • 테스트 가능한 코드가 많아진다.
  • 테스트하기 어려운 영역 (function input)
    • 관측할때 마다 다른 값에 의존하는 코드
      • 현재 날짜/시간, 랜덤 값, 전역 변수/함수, 사용자 입력 등
    • 외부 세계에 영향을 주는 코드 (function output)
      • 표준 출력, 메시지 발송, 데이터베이스에 기록하기 등
  • 테스트하기 쉬운 영역 - 순수 함수 (pure function)
    • 같은 입력에는 항상 같은 결과
    • 외부 세상과 단절된 형태
    • 테스트하기 쉬운 코드

키워드 정리

  • 다뤄본 것들
    • 단위테스트
    • 수동 테스트, 자동화 테스트
    • Junit5, AssertJ
    • 해피 케이스, 예외 케이스
    • 경계값 테스트
    • 테스트하기 쉬운/어려운 영역 - 순수함수
  • 찾아볼 것들
    • lombok
      • @Data, @Setter, @AllArgsConstructor 지양
      • JPA 양방향 연관관계시 @ToString 순환 참조 문제

마무리

초반 강의는 테스트 코드의 필요성과 이점에 대해 간략하게 설명해 주었습니다.

이번 내용 중 저는 수동 테스트는 꼭 불필요 한건가?라는 고민이 생겼습니다. 실무를 하다보면 필요한 경우도 있지 않을까? 라는 의문이 남아있습니다.

테스트하기 어려운 영역, 특히 날짜를 이용한 로직의 경우 날짜를 파라미터로 분리하는 방법은 현재 코드에서도 많이 적용돼 특히 공감이 많이 되었습니다.

현재 근무하는 환경이 테스트 코드가 적지 않고, 테스트 코드를 위해 많은 공을 들인 환경이라 학습을 통해 테스트 코드에 대한 실무 경험을 많이 쌓고 잘 녹일 수 있었으면 좋겠다고 생각합니다.

그럼 이만. 🥕👋🏼🖐🏼

참고자료🤣

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