김경호

김경호

Slow but steady wins the race
2022.01 ~

느리더라도 꾸준하게…

[Daily Contents] SW 테스트케이스 설계


주제

테스트 가능한 코드 작성법
BE 및 FE의 테스트

테스트 가능한 코드 작성

아예 Test Driven 하기

테스트를 먼저 작성하면 테스트가 어려운 코드는 만들어질 수 없음.

아래 두 가지 원칙을 따른다.

  • Parameterize
  • Separate Logic and Effect
    • 참조 : https://eunjin3786.tistory.com/90

테스트의 기본 형식: Input & Output

ex) AM, PM을 판별하는 시스템

  • 현재 시간을 Input함으로서 AM, PM을 판별.

Protocol

  • Swift언어에서 나오는 데이터 구조체

  • Python의 데이터클래스(Data Class)
  • Swift의 Protocol

  • Java의 record

  • WWDC 발표에서는 파라미터를 Protocol로 전달하여 유연성을 확보

Seperating Logic and Effects

ex) /temp 디렉토리 내 파일들 중 생성 시간이 현재 기준으로 10분 이내 것만 남기고 나머지 파일을 삭제하는 프로그램

  • Input이 없으므로 Parameterize가 안 되었다.
  • Output도 없다.
  • 엉뚱한 파일이 삭제될 수도 있는 파일 삭제 테스트의 위험성

Output 파일 삭제의 위험성

  • 삭제 대상 선정 로직과 실제 삭제 부분(Effect)을 분리하자.
  • CleanTemp() 함수는 삭제 대상 목록을 리턴 -> 이 로직 부분이 테스트 대상
  • 별도의 삭제 함수에서 이를 받아 삭제만 함.
  • 이제 테스트는 CleanTemp의 변수를 조정하고 이에 맞는 삭제

FE 테스트

시각적 테스트

  • HTML 출력 비교
  • 스냅샷 비교(JEST 활용)

시각적 테스트의 한계

  • 실제 결과물의 구조를 예측할 수 있을까? -> To Be의 특정이 어렵다.
  • 테스트가 성공해도 항상 의도된 결과가 나올까? -> 조금씩 틀어지면 항상 실패 테스트? -> FE는 결과에 영향을 주는 요소들이 너무 많다 : CSS, 브라우저 환경 등등
  • 이게 리팩토링에 도움이 될까?
  • 지원 도구들은 많이 있음 -> Percy, Chromatic, applitools -> AI를 활용하여 의미있는 변경점을 찾아줌
  시각적 테스트 기능적 테스트
용도 회귀 테스트 모든 종류 테스트
TDD 불가능 가능
실행 환경 브라우저 외부 브라우저 외/내부, Node.js
테스트 도구 외부 서비스 필요(유료) Jest, Mocha
결과 확인 이미지 확인 UI 필요 커맨드 라인으로 확인
CI연동/이력 관리 별도 UI 필요 빌트인으로 확인 가능

테스트 대상별

  Code Component 통합
대상 method 개별 컴포넌트 화면 + 시나리오
테스트 prop 값, 기타 변수 값 컴포넌트의 pixel 등 기능 수행 자동화
도구(추천) JEST Storybook Cypress

ex) 버튼을 눌러 숫자를 증가시키는 버튼
** 기능적 테스트 **

  • 기능적 테스트는 클릭을 하여 값이 증가, 감소함을 체크

** 시각적 테스트 **

  • 기능적 요소는 제외, 숫자가 제 위치에 있는지, 폰트 크기 등을 체크

시각적 테스트 준비

  • StoryBook으로 관리하면 편하다!

통합 테스트(E2E 테스트)

  • 서버 모킹 : API 모킹 서버 활용(https://resttesttest.com/ 등)
  • 테스트 스크립트 : 자동화 도구 사용
  Selenium Web Driver Cypress
주 용도 E2E테스트 통합 테스트
주 사용자 QA/개발자 개발자(프론트)
사용 언어 JS, Java, Python, C#, Ruby JS
크로스 브라우징 지원 미지원
실행환경 브라우저 외부 브라우저 내부
실행속도 느림 빠름
서버 목킹 미지원 지원

시각적 테스트 VS 기능적 테스트

  • 둘 사이의 구분이 명확하지 않은 경우도 많음.
  • 프로젝트, 컴포넌트, 기능별 특징에 따라 적절한 방식 선택
  • 테스트의 가치, 효용을 고려하여 균형있는 선택 필요

단위 테스트 VS 통합 테스트

  • 단위 테스트는 효용성, 비용을 따져 수행 여부를 판단해야 함. -> 단위 테스트의 사업적 가치?
  • 컴포넌트 단위 통합 테스트를 우선으로 고려.
  • 애플리케이션 단위 통합 테스트는 보조적으로 활용.

정리.

** 테스트 가능한 코드 **

  • 파라미터화
  • Logic과 Effect의 분리

** 프론트엔드 테스트 **

  • 시각적 테스트 VS 기능적 테스트
  • 컴포넌트 단위 시각적 테스트 : StoryBoard 활용
  • 도구를 활용한 통합 테스트 : Cypress 등 활용

Q&A

Q. cypress는 빠르지만 크로스브라우징을 지원하지 않는 반면 selenium은 크로스브라우징을 지원한다. cypress만을 사용하는 것은 위험하지 않은지?
A. 용도에 따른 것. selenium은 QA에서 많이 활용. 반면 cypress는 개발자용. 빠르게 하나의 타켓을 체크하고 넘어가기 때문에 가볍기도 하다.

Q. 테스트해야 할 시기를 정하는 법에 대해 알고 싶다.
A. 단위 테스트, 통합 테스트, 시스템 테스트 세 가지 등으로 나뉘는데, 각각 기능 범위, 페이지 범위, 전체 시스템 범위로 테스트.

Q. 현재 FE에서 TDD 도입하여 개발 중이며 유닛테스트에서는 Jset에서 MSW로 서버 목킹해서 테스팅 중. E2E 테스트에서는 서버를 목킹해서 테스트 해도 될 지, 아니면 실 API로 테스트 하는게 좋을지 여쭈어 봄.
A. API 모킹 서버를 활용하여 테스트할 수 있음. 실 API 테스트가 베스트이나, 어려울 때 모킹 서버 활용.

댓글남기기

참고