QA(Quality Assurance)

결과물을 최종적으로 사용자에게 전달되기 직전에 결과물이 요구 사항에 맞게 동작하는 지를 검증하는 과정

일정 규모 이상의 기업에서는 QA조직이 따로 있음(중요한 작업)

개발 과정에서는 QA 과정이 각 단계에서 꾸준히 이루어진다(UX 검증후 개선, 서버 API 호출하고 값 확인, 화면 렌더링 결과를 디자인 시안과 비교 등..)

위와 같은 테스트 과정에서는 반복적인 작업이 일어남(반복해서 확인 후 버그 수정) → 테스트 비용 증가 → 테스트 소홀, 리팩토링 주저 → 애플리케이션 품질 저하

그래서 나온 것이 테스트 자동화

테스트 자동화

자동화 할 테스트 코드 작성, 유지보수 측면에서 비용이 많이 들 수 있음

테스트 코드도 애플리케이션이 변화함에 따라서 계속 관리해주어야 함

무조건 도입하지 말고 왜 필요한지를 생각해보고 비용이 적게 드는지 계산해본 후 자동화 테스트를 하는 것이 중요

좋은 테스트가 공통적으로 갖고 있는 특징 5가지

1. 실행 속도 빨라야 함
2. 내부 구현 변경 시 깨지지 않아야 함
   1. 인터페이스 기준으로 o, 구현 종속적인 테스트 x(단위를 너무 작게 쪼개지 x)
   2. 작은 리팩토링에도 테스트가 깨지면 코드를 개선할 때 개선된 코드를 믿고 의지할 수 없고, 테스트를 수정하는 비용을 발생시켜 코드 개선을 방해
3. 버그 검출할 수 있어야 함
   1. 버그 발견하기 위해서는 테스트 기대 결과를 구체적으로 명시하고 예상 가능한 시나리오를 모두 검증할 수 있어야 함, mock 사용은 최대한 지양
   2. Mock를 과하게 사용하면 의존성 있는 객체의 동작이 바뀌어도 테스트 코드가 연결 과정에서의 버그를 전혀 검출하지 못하게 됨
4. 테스트 결과가 안정적이어야 함
   1. 외부 환경의 영향을 최소화 → 시간, 기기, 네트워크 상태마다 동일한 결과
5. 의도가 명확히 드러나야 함
   1. 코드 수정, 제거할 때 관리 비용을 줄이기 위해서 사람이 읽기 좋은 코드, 한 눈에 어떤 내용을 테스트하는 지 파악할 수 있게 짜야 함. 그렇지 않으면 다른 개발자, 심지어 본인조차 나중에 코드를 볼 때 의도를 파악하기 어려움

프론트엔드 테스트

• 테스트를 얼마나 작은 단위로 쪼개서 작성할 지, 얼마나 상세하게 작성할 지 등 고려해야 할 부분이 많다. 모든 요소를 다 만족하는 테스트를 작성하는 것은 사실상 불가능하기 때문에 전략을 잘 세워야 함

• 특히 프론트 엔드는 GUI와 밀접하게 관계, 사용자의 다양한 실행 환경을 고려해야 함 → 다른 플랫폼에서 사용되는 전략을 그대로 사용할 수 x

  시각적 요소, 서버와의 통신, UI를 통한 입력 등을 각가 어떻게 테스트할 지 고민, 전략 세워야 함(프론트엔드에 맞는 실용적인 전략이 필요)

• 테스트 도구

  여러 최신 테스트 도구들은 기존보다 더 실용적이고 효율적인 테스트 전략을 세울 수 있게 도와줌

  E2E(End To End)도구인 Cypress: 사용자의 관점에서 테스트 + 직관적이고 빠르고 안정적인 테스트 작성

• html 문자열 비교 테스트는 예상되는 결과를 먼저 작성하는 TDD 방식과 다름(브라우저 or 테스트 도구의 콘솔 로그를 이용해서 실제 컴포넌트가 생성한 HTML을 복사하고 테스트 코드에 붙여넣을 때가 많음) → Jest 등의 테스트 도구에서 지원하는 스냅샷 테스트로 해결

  But 둘 다 태그 변경하거나 클래스 이름 변경 시 → 테스트가 깨짐, html css를 리팩토링할 때에도 테스트 코드를 수정해주어야 하는 번거로움, 개발 속도 느려짐

  html css 코드 보고 실제의 이미지를 머릿속에 정확히 그려내기가 힘듬(의도가 드러나지 않기 때문에 좋은 테스트라고 보기가 어려움)

• 시각적 요소는 실제 화면에 표시되는 이미지를 픽셀 단위로 비교하지 않는 이상 효과적인 테스트라고 하기 어려움
• 디자인 시안은 발생 가능한 모든 시나리오가 고려되어 있지 않는 경우가 대부분(ex. 하나의 컴포넌트에 대해 여러 state값에 따라 여러가지 모습으로 렌더링)

• 화면 해상도, 브라우저 고유 렌더링 방식, 뷰 포트의 크기 및 여백 등의 많은 조건을 고려하여 픽셀 단위로 비교하기는 기술적으로 많이 어려움

• 실제로 개발할 때 개발자들은 html 태그 하나, css 스타일 하나를 추가, 수정할 때마다 눈으로 확인하고 다른 결괏값을 기대 → 가장 효율적인 시각적 테스트 방법은 개발자가 확인하는 것일 수도 있음

• 아직까지는 시각적 테스트를 완벽히 자동화를 할 수는 없지만 UI를 개발하는 방식을 개선할 수는 있다. 그것은 바로 스토리북!

• 최근에는 브라우저 렌더링 방식 차이를 이해하고 이미지를 비교해주는 시각적 테스트 도구들이 많이 발전하고 있지만 주로 회귀 테스트의 용도로 사용됨(회귀 테스트는 최근 프로그램이나 코드 변경이 기존 기능에 나쁜 영향을 미치지 않았 음을 확인하는 소프트웨어 테스트 유형), 스토리북과 같이 사용할 경우 효과적

스토리북

테스트 도구라기 보다는 UI 개발 환경

컴포넌트 갤러리라고 할 수 있음 → 애플리케이션에서 사용되는 모든 컴포넌트의 조합을 페이지별로 등록해놓고 편리하게 눈으로 확인할 수 있도록 네비게이션을 제공

결과물을 시각적으로 검증하는 행위는 자동화x, 사람이 직접 보고 검증하되 검증을 위한 준비 작업을 최대한 자동화

reference

• 실용적인 프론트엔드 테스트 전략 (1) : NHN Cloud Meetup