수업 60일차
이론
- 코드 테스트: 코드를 작성하고 나면, 원하는 대로 동작하는지 알기 위해 테스트를 함
화이트 박스 테스팅: 컴포넌트 내부 구조를 미리 안다고 가정하고 테스트 코드를 작성
블랙박스 테스팅: 컴포넌트 내부 구조를 모른채 어떻게 동작하는지에 대한 테스트
Unit Testing: 다른 부분과 분리된 작은 코드를 만들고 그것을 테스트함
Integration Testing: 앱의 특정 부분이 잘 동작하는지를 테스트 하는 경우
End-to-end Testing: 유저가 어떤 시나리오를 가지고 그 시나리오의 end-to-end로 잘 동작하는지 테스트함
jest: Facebook에서 오픈소스화한 테스팅 프레임워크
Assertion matchers: jest는 풍부한 matcher를 제공하여, 여러 상황에서 match를 체크함
mock funcrions: mock funcrion을 만듦
Lifecycle funcrions: 각 테스트의 시작과 끝, 전체 테스트의 시작과 끝에 원하는 작업을 할 수 있음
Snapshot Testing: 특정 함수, 모듈, 컴포넌트 등의 결과를 serializable한 형태의 Snapshot으로 저장하고, 추후 변경이 발생했을때 이전의 Snapshot과 새로운 Snapshot을 비교하여 변경이 발생 했는지 추측함
react-testing-library: 테스트가 소프트웨어 사용되는 모습을 닮을수록, 테스트를 더욱 신뢰할 수 있게됨
user-event: 내장 이벤트 함수인 fireEvent, createEvent를, 좀더 직관적이고 범용적으로 사용할 수 있도록 만든 라이브러리
화이트박스 테스트(White Box Test)
- 개발자 중심
- Test 과정 초기 적용. 논리적 경로. 프로그램 흐름 점검
- 모듈 안 동작을 직접 관찰
- 모든 문장을 한 번 이상 실행
화이트박스 테스트의 종류
기초 경로 검사 (Base Path Testing)
- 대표적인 화이트박스 테스트 기법
- 테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법, 테스트 측정 결과는 실행 경로의 기초를 정의하는 데 지침으로 사용
제어 구조 검사 (Control Structure Testing)
- 조건 검사(Condition Testing): 프로그램 모듈 내에 있는 논리적 조건을 테스트하는 테스트 케이스 설계 기법
- 루프 검사(Loop Testing): Loop 구조에 초점을 맞춰 실시하는 테스트 케이스 설계 기법
- 데이터 흐름 검사(Data Flow Testing): 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시하는 테스트 케이스 설계 기법
블랙박스 테스트(Black Box Test)
- 기능, 사용자 중심
- 소프트웨어가 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 테스트
- 사용자의 요구사항 명세를 보면서 주로 구현된 기능을 테스트
- 인터페이스에서 실시
- 테스트 과정의 후반부에서 적용
블랙박스 테스트의 종류
동치 분할 검사 (Equivalence Partitioning Testing)
- 입력 자료에 초점을 맞춰 테스트 케이스를 만들고 검사하는 방법으로 동등 분할 기법이라고도 함
- 입력 데이터의 영역을 유사한 도메인별로 유횻값 / 무횻값을 그룹핑하여 나누어서 검사
경계값 분석 (Boundary Value Analysis)
- 입력 자료에만 치중한 동치 분할 기법을 보완하기 위한 기법이다.
- 입력 조건의 중간값보다 경계값에서 오류가 발생될 확률이 높다는 점을 이용
원인-효과 그래프 검사 (Cause-Effect Graph)
- 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한 다음 효용성이 높은 테스트 케이스를 선정하여 검사하는 기법.
오류 예측 검사 (Error Guessing)
- 과거의 경험이나 확인자의 감각으로 테스트하는 기법
- 다른 블랙 박스 테스트 기법으로는 찾아낼 수 없는 오류를 찾아냄
비교 검사 (Comparison Testing)
- 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 테스트하는 기법.
Unit Testing
- 작은 양의 코드가 실행되고 제 역할 하는지 확인함
- 앱 속 하나의 컴포넌트를 확인함
- module 특화
- scope가 매우 좁은 편: 하나의 클래스만 확인하는 경우도 있음
- unit test 밖에 있는 코드에 dependency가 없어야 함 ➡ 관심사 분리!
- unit testing은 더 상세하게 나눠져있지 않음
- 각자의 unit들의 testing의 집중하지 서로 상호작용할 때의 문제점까지 짚지 않음
- White Box Testing Type에 포함되어 있음
Integration Testing
- 각자의 모듈들이 서로 통합했을 때의 testing ➡ 통합 됐을 때 어떤 문제들이 발생하는지
- 앱 전체의 testing
- interface 특화
- integration testing은 DB, 하드웨어 등 외부 시스템을 의존, 참조
- unit test 다음, 그리고 system test 전에 하는 테스트
- integration testing은 top-down, bottom-up 등 다양한 type들로 나눠짐
- Black Box, White Box Testing에 포함되어 있음
End-To-End Test
- 크롬 브라우저를 띄운 다음, 내가 만든 검색페이지로 들어가서 검색을 해보고 검색한 내용이 제대로 나오는지 화면상에서 확인하거나 직접 회원가입을 해보고 회원가입후에 로그인 되는지 직접 브라우저 상에서 값을 입력해서 테스트 하는방법
- UI Testing이 가장 어렵고 까다로움
- Manual Testing은 실행하기 쉽다는 장점이 있지만 비용이 많이 들고 부정확하며 실행 시간이 오래 걸림
- 자동화 할 수 있지만 UI Testing은 자동화 하기가 가장 까다롭고 또 실행하기도 까다로움
코린이 입니당 :)