DevOps Day 33 (4.20) 지속적 통합_테스트

테스트
테스트 주도 개발 (Test Driven Deployment, TDD) :
 - 테스트 주도 개발이란 테스트가 기능의 디자인을 주도하는 반복적인 개발 방법론을 뜻합니다.

 

기존의 개발 과정 :

기존의 개발 프로세스는 아래와 같습니다 :

1. 요구사항 분석
2. 요구 사항을 토대로 디자인(설계)을 진행
3. 설계에 맞추어 기능을 개발.
4. 구현 완료 후 수동으로 기능을 테스트
5. 원하는 대로 동작하지 않거나 문제가 발생하면 디버깅을 통해 원인을 파악하고 수정
6. 3 - 4의 과정을 개발이 완료될 때까지 반복

테스트 프로세스 :

1. 요구사항 분석
2. 요구 사항을 토대로 디자인(설계)을 진행
3. 설계를 기반으로 기능 테스트 진행
 - 실패 시 다시 설계
4. 테스트가 성공했다면 개발 진행
5. 3 - 4의 과정을 개발이 완료될 때까지 반복

Q. TDD는 기존 개발 프로세스의 문제점을 어떻게 해결해 주었을까요?
설계 → 개발 → 테스트로 이어지던 기존의 개발 프로세스를 설계 → 테스트 → 개발의 프로세스로 변경하여 버그를 조기에 발견하고 해결할 수 있게 되었습니다.
TDD의 설계 → 테스트 → 개발의 프로세스는 변경 점에 따라 테스트를 진행해야 하는 상황에 대한 부담을 줄여 주었습니다.

 

테스트 주도 개발 사이클

테스트 주도 개발의 장점 :
1. 더욱 명확한 기능과 구조를 설계할 수 있습니다.
2. 재사용성이 고려된, 모듈화된 코드를 작성할 수 있습니다.
3. 설계 수정 시간과 디버깅 시간의 단축
 - 단위 테스트 기반의 테스트 코드를 작성하기 때문에 추후 프로그램에 문제가 발생할 경우, 각각의 모듈별로 테스트를 진행하면서 문제 지점을 쉽게 찾아낼 수 있습니다.
4. 완성도 높은 설계
 - 코드의 기능, 정의 등 구조적인 문제에 대하여 명확하게 접근할 수 있으며 다양한 예외상황에 대해서도 고려하게 되므로 이는 완성도 높은 설계로 이어집니다.
5. 유지 보수의 용이성

- 프로젝트에 어떤 기능을 추가하는 등의 유지 보수를 해야 하는 상황이라면 항상 기존 코드들에 끼칠 영향에 대해 생각해야 합니다.

- TDD 이전의 개발 방식에선 단순한 기능이라도 수정되거나, 추가되는 경우에는 많은 코드에 대하여 테스트를 진행해야 했으나, TDD를 진행한다면 변경 점에 따른 테스트를 진행해야 하는 상황에 대한 부담이 줄어들 수 있습니다.

 

테스트의 종류
단위 테스트 :
- 작은 단위의 테스트입니다.
- 검증이 필요한 코드에 대해 테스트 케이스를 작성하는 절차 혹은 프로세스를 뜻합니다.
- 유닛 테스트의 장점으로는 즉각적인 피드백이 나오는 것을 들 수 있습니다. 다만, 하나의 메서드가 잘 작동함은 보장할 수 있지만 그들이 결합하는 시점에서도 잘 작동하는지에 대해서는 보장할 수 없기 때문에 염두에 두어야 합니다.

통합 테스트 :
모듈을 통합하는 과정에서 모듈 간 호환성의 문제를 찾아내기 위해 수행되는 테스트입니다

테스트 시 사용하는 도구 :
- Mocha, Chai (Javascript)
- JUnit (Java)

 

E2E 테스트 (End to End Test) :
- 전체 시스템이 제대로 동작하는지 확인하기 위한 테스트입니다.
- 사용자의 입장에서 사용자가 사용하는 상황을 가정하고 시뮬레이션을 진행합니다

장점 :
- 실제 상황에서 발생할 수 있는 에러를 사전에 발견할 수 있습니다.

단점 :
- 테스트 작성 시 들어가는 비용이 너무 많습니다.
- 수행 속도가 느립니다.
- "실패했다"라는 결과만 있기 때문에 피드백의 질이 낮습니다

 

E2E 테스트 도구 :
- Cypress
- Nightwatch
- Testcafe

 

E2E 추가 내용 :
E2E 테스트에는 수평 및 수직 두 가지 주요 방법이 있습니다. 두 방법 모두 긍정적인 결과를 얻을 수 있지만, 서로 다른 방식으로 도움이 되며 차이점을 이해하는 것이 중요합니다.

 

수평 방법 : 수평 E2E 테스트는 전체 응용 프로그램을 고려합니다. 이러한 E2E 테스트를 위해서는 잘 정의된 워크플로우와 정의된 테스트 환경이 필요합니다. 수평 E2E 테스트는 기본적으로 시작부터 끝까지 개별 워크플로 이벤트를 검증하며, 여러 시스템을 동시에 테스트합니다.

예를 들어 전자 상거래 응용 프로그램을 살펴보면, 수평 E2E 테스트를 위해 테스터는 사용자 계정에 로그인하고 회사의 제품을 둘러보고 몇 가지 제품을 장바구니에 추가한 다음 체크아웃을 시도합니다.

 

수직 방법 : E2E 테스트는 응용 프로그램 구조를 다른 레이어로 분해합니다. 각 레이어는 개별적으로 테스트되어 계층적 순서로 분석됩니다. UI, 데이터베이스 셀 또는 API 요구 사항을 포함할 수 있는 레이어는 각각 하향식으로 테스트됩니다.

 

E2E 테스트의 라이프사이클 : E2E 테스팅의 라이프사이클을 이해하는 것은 E2E 테스팅과 그 유용성을 이해하는 좋은 방법입니다.
- 테스트 계획: 이 단계에서 E2E 테스팅을 완료하기 위해 필요한 중요한 작업, 연관된 일정 및 자원을 식별합니다.
- 테스트 디자인: E2E 테스트를 디자인할 때, 테스트 사양을 식별하고, 테스트 케이스를 생성합니다. 테스트를 스케줄링하기 전에 리스크 분석과 사용 분석도 수행해야 합니다.
- 테스트 실행: 마지막으로 테스트 케이스를 실행합니다. 이 과정에서 결과를 문서화해야 합니다.
- 결과 분석: 테스트가 완료된 후 결과를 분석합니다. 전반적으로 테스팅을 평가하고 필요한 경우 추가 테스팅을 수행해야 합니다.

 

프로세스 :
다음은 가장 일반적인 E2E 테스트 수행 방법입니다:
- 테스트 시나리오 확인: 비즈니스 소유자, 개발자, 테스터, 매니저 등과 함께 다양한 시나리오에 대해 브레인스토밍합니다. 이러한 시나리오는 실제 사용자가 수행할 것과 유사한 시나리오입니다.
- 시나리오를 사용하여 단계를 매핑: 시나리오가 준비되면, 각 시나리오를 완료하는 데 필요한 단계를 매핑하고 예상 결과를 확인합니다.
- 테스트 자동화: 자동화를 통해 가장 정확하고 빠른 결과를 얻을 수 있습니다.
- CI 프로세스에서 테스트 케이스 실행: 이를 통해 각 시나리오와 관련된 개발자에게 매우 가치 있는 피드백을 제공할 수 있습니다.