테스트를 하는 이유는?
첫째, 에러를 사전에 감사하기 위해서이고
둘째, 동작이 이전과 다른것이 있는지에 관하여 검사하는 것이고
셋째, 사전 검증을 통하여 안정성 있는 앱을 전달 하기 위해서이다.
이런 테스트과정이 없다면 버그가있는 상태로 사용자에게 전달이 될 수 있으며, 그 결과 사용자들은 안좋은 결험을 할 수 밖에 없게 된다.
먼저, 코드상에 있는 문제를 바로 알아 낼 수 있는 Static Analysis 정적분석을 이용하는 방법이 있다. 접근성도 쉽고 저비용 고효율을 낼 수 있다. (Typescript, Eslint)
정적분석 외에 테스트를 작성하는 방법이 있는데, 먼저 테스트가 가능한 코드로 변경하는 작업이 선행되어야한다. React-native 공식홈페이지에서는 테스트가능한 코드에 대해서 business logic과 앱의상태 react component등을 잘 분리해놓는 것을 권장하고 있고, 그 이유로는 나누면 나눌수록 신뢰성있는 테스트를 할 수 있기 때문이다.
코드가 잘 분리 되었다면, 테스트 작성을 하게 되는데 테스트 작성시에 테스트를 잘 구조화해야한다. 구조화가 제대로 되어있지 않다면 테스트 하는사람마다 각자 다른 스타일로 테스트를 설명하기에 테스트가 어떤 테스트인지 알 수 없어질 경우가 생기기 때문이다.
Given : 어떤 조건의 테스트인지?
When : 어떤 함수 또는 행동에 의해서 발생하는 것인지?
Then : 어떠한 결과값이 나와야 하는지?
다음과 같은 구조로 작성하면 테스트가 무엇인지? 알수있게 된다.
테스트의 종류
-
Unit Test
가장 작은 단위에 대한 테스트이다.
쉽고 빠르게 작성할 수 있고 바로 실행하여 검증 가능하다.
작은단위로만 테스트 하기에, 합쳐졌을때 동작이 상이할 수 있다. -
Integration Test
통합테스트, 유닛테스트들과 함께 통합하여 테스트 하는것이다.
각각의 유닛테스트 결과들을 섞어 테스트 결과값을 정하게 된다. -
Component Test
컴포넌트 자체에 대한 검증을 테스트 진행한다.
Integration Test : 버튼이 눌리는지, 혹은 disable되었을때 눌리지 않는지 등에 대한 검증을 한다.
Snapshot Test : 이전에 render되던 것과 지금 render되는 것이 동일한지에 대한 검증을 한다. -
E2E Test (End to End Test)
실제로 돌아가는 앱에서 지정된 스크립트대로 반복하는 것이다.
실제로 로그인 플로우등 잘 변하지 않는 화면에 대해서는 테스트 가능하다.
제일 깨지기 쉬운 테스트이기 때문이다. 앱의 화면이 변경되거나 외부페이지가 변경되면 정상동작임에도 다음 스텝으로 넘어가지 못하기 때문이다.
Unit Test 나 Integration Test는 logic의 수정이 빈번하게 일어나더라도 가장작은단위 그것을 합친단위이기 때문에 테스트가 제대로 동작하지 않는 빈도가 E2E Test에 비해 낮다.
테스트는 비용이 많이 들어가는 작업이다. 그럼에도 테스트를 작성해야하는 이유는 생산성과 안전성을 보장해야하기 때문이다.
Jest란?
Javascript Unit Test Framework 의 약자이다.
자바스크립트에서 유닛테스트를 만들때 가장 범용적으로 사용되고 있다.
Jest 기본 테스트 구조
test("What to Test it", () => {
expect(1+1).toBe(2)
})첫번째 인자에 어떤 것을 테스트 하는 것인지에 대한 설명을 적는다.
두번째 콜백을 통해서 함수를 실행하게 되는데 expect에 검증대상을 넣고 toBe에 기대값을 넣는다.
설치, 세팅, 실행
npm install --save-dev jest @types/jest
package.json에 script를 추가해준다.
"test:unit": "jest"Test할 파일을 생성한다.
NumberTest.test.ts파일에 코드를 작성해주고 스크립트에 작성한
npm run test:unit 명령어로 테스트를 진행한다.
