[Test] 테스트에 대한 이해

요즘 관심을 두고 공부하고 있는 건 테스트 코드 Jest, Cypress이다.

직무를 하면서 항상 나한테는 두려운 부분과 더불어 감당하기 어려운 부분이라고 생각되는 게 테스트였다.

작업자인 내가 짠 코드를 평가받는 것 뿐 아니라 기능이 잘 작동하고, 프로세스 flow를 알아야 되는데

회사 안에서는 그럴 수 있는 사람이 없었다. 비 개발자 분야 분들이 직접 베타 테스트를 진행하기 때문에 내 스스로 판단하고 버그를 수정할 여건이 되지 않았다고 생각한다.

 

이 참에 테스트 코드를 작성하면서 처리해보자는 생각에 공부를 하였고, 그중 인프런에 하루 만에 Cypress로 작성하는 자바스크립트 E2E 테스트 코드를 찾아보며 Jest, Cypress 등 테스트 프레임워크를 배우기 시작했다.

 

https://github.com/shin-eunji/cypress-testcode

GitHub - shin-eunji/cypress-testcode

 

실습을 하며, 테스트 진행과 어떻게 코드를 작성하는지 알 수 있는 정말 정말 간단한 단계였다.

테스트 코드가 있다면 시간을 얼마나 줄어들 수 있을까?

두려움 => 자신감

 

테스트를 작성하는 이유

테스트란? 

애플리케이션이 요구사항에 맞게 동작하는지 검증하는 행위입니다.

 

테스트의 예)

• DB에 데이터를 입력하는 API를 개발 => API 호출 => DB값 검증
• 디자인 시안에 맞게 HTML/CSS를 작성 => 브라우저에서 실제 렌더링 된 결과를 확인
• 새로운 기능을 추가하기 위해 기존 모듈을 리팩터링 => 영향을 받는 다른 모듈의 실행 결과를 확인
• 버그를 수정하기 위해 기존 함수를 수정 => 버그각 수정 확인 & 영향을 받는 다른 모듈의 실행 결과를 확인
• 버그를 수정하기 위해 기존 함수를 수정 => 버그가 수정 확인 & 영향을 받는 다른 모듈의 실행 결과를 확인
• 개발 환경에서 테스트된 애플리케이션을 리얼 환경에 배포 => 배포 과정에서 발생한 무제가 없는지 확인

 

개발과 테스트

개발자는 사실상 코드를 작성하는 것보다 더 많은 시간을 테스트에 사용

 

 

왜 테스트를 작성하는가? 

테스트 자동화

장점

사람이 수행해야 하는 반복된 테스트를 자동화할 수 있음 (비용 감소)

사람이 수행하는 것보다 훨씬 빠르게 테스트할 수 있음.

사람이 수행하는 것보다 더 신뢰할 수 있다.

 

단점

감각적인 요소(시각, 청각)등 사용자 경험과 관련된 문제를 찾아낼 수 없음.

실제 환경에서 벌어지는 다양한 상황을 자동화하기 어려움(네트워크, 디바이스 관련 등)

 

 

테스트 자동화는 누가 하는가?

QA

개발자

 

개발자가 테스트 작성해야 하는 이유

제품 품질

개발자는 작성한 프로그램의 퀄리티에 대한 책임이 있음.

QA에 넘기기 전에 기본 요구사항을 모두 만족하는지에 대한 검증은 개발자가 해야 함.

자동화된 테스트를 작성해 두지 않으면, 애플리케이션이 복잡해질수록 테스트 비용이 증가함.

이 경우 개발 기간이나 인력 등은 한정되어 있기 때문에, 테스트를 소홀히 하게 되는 경우가 많음.

그렇지 않은 경우 QA와의 커뮤니케이션 비용이 늘어나, 업무 효율이 떨어지게 됨.

 

코드 품질

코드 품질을 위해서는 계속해서 리팩터링 등의 개선 작업이 필요

이 과정에서 기존에 잘 동작하던 프로그램을 망칠 수 있기 때문에 적극적으로 코드를 개선하지 않게 됨.

신괴할 수 있는 자동화된 테스트가 있으면 적극적으로 코드를 개선할 수 있음.

 

 

테스트의 종류

분류

범위에 따라

- 단위(Unit) 테스트

모듈(함수/클래스) 단위의 테스트

작성 비용이 적게 들고 실행 속도가 빠름.

실패했을 때 문제가 생긴 부분을 비교적 정확하게 파악할 수 있음.

 

- 통합(Integation) 테스트

주로 단위 테스트보다 큰 범위의 테스트를 의미

개별 모듈(함수/클래스)들이 연결되어 제대로 상호작용하는지를 테스트

단위 테스트에 비해 실패 시 문제가 생긴 부분을 정확히 파악하기가 어려움

 

- E2E(End to End) 테스트

실제 사용자가 사용하는 것과 같은 조건에서 전체 시스템을 테스트

단위/통합 테스트에 비해 작성이 어렵고 실행 속도가 비교적 느림

API 서버, DB 등의 외부 서비스들을 모두 사용하여 통합된 시스템을 테스트

 

좋은 테스트란?

1. 실행 속도가 빨라야 한다.

빠른 피드백은 개발 속도가 향상해준다.

너무 느리면 테스트를 자주 실행하지 않게 된다.

 

2. 내부 구현 변경 시 실패하지 않아야 한다.

리팩터링 할 때 테스트가 깨진다면? 오히려 코드 개선을 방해

자주 변하는 로직과 변하지 않는 로직을 구분

 

3. 버그를 검출할 수 있어야 한다.

소스 코드에 버그가 있어도 검출하지 못한다면 잘못된 테스트

테스트가 기대하는 결과를 구체적으로 명시하지 않으면 버그를 검출할 수 없음.

 

4. 테스트 결과가 안정적이어야 한다.

특정 환경에서만 실패하거나 실행할 때마다 결과가 달라지는 테스트는 신뢰할 수가 없음.

외부 환경의 영향을 최소화해서 동일한 결과를 최대한 보장할 수 있는 게 중요함.

 

5. 의도가 명확히 드러나야 한다.

가독성: "기계가 읽기 좋은 코드" => "사람이 읽기 좋은 코드"

테스트 코드를 보고 한눈에 어떤 내용을 테스트하는지를 파악할 수 있어야 함.

 

테스팅 ROI

1. 테스트 코드 작성과 유지보수는 비용이다.

• 테스트가 없는 것보다는 있는 게 무조건 낫다?
• 테스트는 많을수록 좋다?

⇒ 불필요한 테스트나 잘못 짜인 테스트는 차라리 없는 게 나음.

비용 대비 효과가 충분한가?

• 테스트를 작성하는 비용에 비해 얻을 수 있는 효과가 더 큰가 가 중요
• 로직이 거의 없는 코드는 따로 테스트하지 않아도 됨.(ex. 이벤트 페이지)
• 테스트 범위에 대한 조절이 필요 (단위, 통합, E2E)
  • 모든 모듈에 대해 단위 테스트를 작성하는 것은 비효율적
  • 모든 테스트 케이스를 E2E 테스트로만 검증하는 것도 비효율적

커버리지 100%를 목표로 하는 것은 비효율적

• 라이브러리 등은 100% 커버리지 가능
• 복잡한 애플리케이션의 경우 적절한 선을 잘 찾는 것이 중요