리액트 네이티브(React Native) 테스팅
테스팅
코드가 커질수록 예상치 못한 작은 에러와 경계 케이스(Edge Cases)들이 큰 오류로 이어질 수 있습니다. 버그들은 사용자들로 하여금 나쁜 사용자 경험을 하게 하고 결국엔 사업적인 손실까지 발생시키게 됩니다. 이런 취약한 프로그래밍을 방지하는 방법은 배포하기 전에 코드를 테스트하는 것입니다.
이 가이드에선 정적 분석부터 E2E 테스트까지 여러분의 앱이 예상한대로 동작하도록 도와주는 다양한 자동화 테스트 방법들에 대해 다룰 것입니다.
테스트는 왜 필요한가
우리는 사람이고, 사람은 실수합니다. 테스팅은 실수를 발견해 주고 코드가 정상적으로 동작한다는 것을 입증하기에 테스팅은 중요합니다. 새로운 기능을 더하고, 기존의 코드를 리팩터링하고, 프로젝트의 중요한 의존성의 업그레이드에도 코드가 지속해서 동작할 수 있도록 확인시켜 주기 때문에 테스팅은 생각보다 더 중요할 수도 있습니다.
이처럼 테스팅에는 여러분이 생각하시는 것보다 더 큰 가치가 있습니다. 실패하는 테스트를 써보는 것은 버그를 고치기 가장 좋은 방법 중 하나입니다. 버그를 고치고 테스트를 다시 돌렸을 때, 만약 통과한다면 버그는 고쳐진 것이기에 다시 코드에 넣지 않을 수 있습니다.
또한 테스트는 팀에 새롭게 합류한 사람들에게 문서의 역할을 하기도 합니다. 전체 코드를 한 번도 보지 못한 사람들이 테스트를 읽는다면 기존 코드의 진행 방식을 이해할 수 있도록 도와줍니다.
마지막으로 중요한 것은 더 자동화된 테스팅은 더 적은 수동적 QA 시간을 의미하고 소중한 시간을 절약해 준다는 것입니다.
정적 분석
코드 품질을 향상시킬 수 있는 첫 번째 방법으로는 정적 분석 툴을 이용하는 것입니다. 정적 분석은 코드를 실행하지 않고도 작성한 코드의 에러를 확인해 줍니다.
린터(Linters)는 사용하지 않은 코드 같은 일반적 에러를 잡아주고 실수를 피할 수 있도록 도와주며 스페이스 대신 탭을 사용하는 (반대도 동일, 설정에 따라) 등의 스타일 가이드의 표시를 위해 코드를 분석합니다.
타입 확인(Type checking)은 함수가 받기로 되어 있는 구조가 함수에 전달하는 구조와 일치하는지 확인해 줍니다. 예를 들어 number 타입을 기대하는 카운팅 함수에 string 타입을 전달하는 것을 방지해 줍니다.
리액트 네이티브에는 기본적으로 linting을 위한 ESLint와 타입 확인을 위한 TypeScript 두 개의 툴이 구성되어 있습니다.
테스트 가능한 코드를 작성하기
테스트를 시작하기에 앞서 가장 첫 번째로 해야 할 일은 테스트할 수 있는 코드를 작성하는 것입니다. 항공기 제조 과정을 생각해 보세요. 어떤 항공기라도 첫 번째 이륙 전 복잡한 시스템이 모두 잘 작동하는지 보여주기 위해 개별적인 부분들이 안전하고 제대로 동작한다는 것을 확신할 수 있을 정도로 테스트합니다. 예를 들어 날개는 극한의 하중을 주어 구부려 테스트합니다. 엔진 부분은 내구성을 테스트합니다. 유리는 새의 충격을 시뮬레이션으로 테스트합니다.
소프트웨어도 유사합니다. 수많은 코드 라인으로 구성되어 있는 하나의 거대한 프로그램 파일을 작성하는 것 대신 작은 몇 개의 모듈로 코드를 작성하세요. 전체의 코드를 테스트하는 것보다 더 완전하게 테스트할 수 있습니다. 이렇게 테스트할 수 있는 코드를 작성한다면 깔끔한 모듈식 코드를 작성할 수 있습니다.
여러분의 앱을 좀 더 테스트 가능하게 하고 싶다면 View 파트(리액트 컴포넌트)를 비즈니스 로직과 앱의 상태(Redux, MobX, 그 외 어떤 것이든)로부터 분리해 보세요. 그렇게 한다면 리액트 컴포넌트에 의존하면 안 되는 비즈니스 로직 검증을 앱의 UI 렌더링을 담당하는 부분들과 독립적 컴포넌트로 유지할 수 있습니다.
이론적으로는 컴포넌트로부터 데이터 요청 부분과 모든 로직을 분리할 수 있습니다. 이렇게 한다면 컴포넌트들은 오로지 렌더링에만 기여할 것입니다. 상태는 완전히 컴포넌트로부터 독립될 것이고요. 앱 로직은 리액트 컴포넌트가 전혀 없이도 동작할 것입니다.
다른 리소스에서 더 많은 테스트 가능한 코드들을 살펴보는 것을 권장합니다.
테스트 작성하기
테스트할 수 있는 코드를 작성하고 나면 실제 테스트를 작성해 볼 수 있습니다. 리액트 네이티브의 기본 템플릿엔 Jest 테스팅 프레임워크가 내장되어 있습니다. 환경에 맞는 사전 설정이 되어있기에 초기 환경 구성과 mocks 설정으로 고생하지 않고 바로 생산적인 작업을 시작할 수 있습니다. (mocks에 대한 짧은 설명) 이 가이드에서 나오는 모든 테스트는 Jest를 이용해 작성할 수 있습니다.
만약 테스트 주도 개발을 한다면 테스트를 먼저 작성합니다. 그렇다면 그 뒤의 코드에 대한 테스트 가능성은 이미 주어진 것이죠.
구조 테스트
테스트는 짧아야 하며 한 번에 하나만 수행하는 것이 이상적입니다. Jest로 작성된 단위 테스트 예제를 봅시다.
it('given a date in the past, colorForDueDate() returns red', () => {
expect(colorForDueDate('2000-10-20')).toBe('red');
});
이 테스트는 it이라는 함수에 전달되는 문자열을 통해 설명됩니다. 설명을 작성하는 것에 신경을 써야 무엇이 테스트 되고 있는지 명확해질 수 있습니다. 최선을 다해 아래의 사항들을 지켜보세요.
Given - 전제 조건
When - 함수를 통해 실행될 테스트 하고자 하는 동작
Then - 기대되는 결과
이건 AAA로 알려져 있기도 합니다 (Arrange, Act, Assert).
Jest는 테스트 구조를 잡을 수 있도록 describe 함수를 제공합니다. 하나의 기능을 담당하는 테스트 그룹을 만드는 데에 describe를 사용하세요. describe는 중첩될 수 있습니다. 가장 흔하게 사용하는 또 다른 함수들은 beforeEach 또는 beforeAll 입니다. 테스트를 위한 객체를 설정하는데 사용할 수 있습니다. Jest api 참조 문헌을 읽어보세요.
만약 테스트에 너무 많은 단계와 기대 결과가 있다면 작은 단위의 여러개로 쪼개야합니다. 또한 테스트는 완전히 다른 테스트로부터 독립적이어야 한다는 것을 명심하세요. 다른 테스트를 먼저 실행하지 않고도 독립적으로 실행이 가능해야 합니다. 반대로 동시에 여러 테스트를 작동한다면 첫 번째 테스트의 결과가 두 번째 테스트의 결과에 영향을 주어서는 안 됩니다.
마지막으로 우리는 개발자로서 코드가 멋지게 동작하고 충돌하지 않는 것을 좋아합니다. 그러나 테스트와 함께라면 반대가 되어야 합니다. 실패하는 테스트를 좋은 일인 것처럼 생각하세요! 테스트가 실패한다면 때때로 무엇인가가 잘못되었다는 뜻이니까요. 이는 사용자들에게 영향을 주기 전에 문제를 고칠 수 있는 기회를 줍니다.
단위 테스트
단위 테스트들은 개별적 함수나 클래스와 같은 코드의 작은 부분들을 다룹니다.
테스트 되는 객체가 의존성이 있는 경우 다음 문단에서 이야기할 mock을 이용해서 처리해야 합니다.
단위 테스트가 좋은 점은 빠르게 작성하고 실행시킬 수 있다는 것입니다. 그러므로 일을 하면서 테스트가 통과하는지 아닌지에 대한 빠른 피드백을 얻을 수 있습니다. Jest는 코드를 수정하면서 계속해서 테스트를 실행시킬 수 있는 옵션도 가지고 있습니다. Watch mode
모킹(Mocking)
가끔 테스트 중인 객체가 외부의 의존성을 가지고 있다면 모킹(Mocking)으로 처리해야 합니다. "모킹"은 코드의 의존성을 자체 구현으로 대체합니다.
일반적으로 테스트의 실제 객체들을 이용하는 것은 mock을 이용하는 것보다 낫지만 이게 불가능한 상황들이 있습니다. 예를 들어 JS 단위 테스트가 Java나 Obective-C로 작성된 네이티브 모듈에 의존적일 때가 그 예입니다.
여러분이 살고 있는 도시의 현재 날씨를 보여주는 앱을 만들면서 외부의 서비스나 날씨 정보를 제공해 주는 의존성을 사용하고 있다고 상상해 보세요. 만약 이 서비스가 비가 온다고 알려준다면 비구름 이미지를 보여주어야 합니다. 하지만 테스트에서 서비스를 호출하면 안 됩니다. 그 이유는 아래와 같습니다.
테스트를 느리고 불안정하게 만들 수 있습니다 (네트워크 요청이 포함되어 있기 때문에).
테스트를 매번 실행할 때마다 서비스는 다른 데이터를 반환할 수 있습니다.
외부 서비스들은 테스트를 실행해야 할 때 연결이 종료될 수도 있습니다!
그러므로 서비스의 mock을 구현함으로써 몇천 개의 코드 라인과 인터넷으로 연결된 온도계를 효과적으로 대체할 수 있습니다.
Jest는 함수 레벨에서부터 모듈 레벨까지 mocking을 지원합니다.
통합 테스트
큰 소프트웨어 시스템을 개발하고 있을 땐 개별적 부분들은 상호 작용을 해야 합니다. 단위 테스트에서는 만약 하나의 유닛이 다른 유닛에 의존적이라면 가짜 모킹을 만들어 의존성을 대체했을 것입니다.
통합 테스트에서는 실제의 개별적 유닛들이 합쳐져 있고 (앱과 동일) 예상대로 협력하며 잘 작동하는지 확인하기 위해 함께 테스트됩니다. 여기서는 모킹이 절대 일어나지 않는다는 것을 말하려는 게 아닙니다. 여전히 모킹이 필요하겠지만 (예를 들어 날씨 서비스와의 소통을 위한 모킹) 단위 테스트에서 보단 현저히 적게 필요하게 될 것입니다.
통합 테스트에 대한 용어가 항상 일관되지 않는다는 것을 명심해 주세요. 또한 단위 테스트와 통합 테스트 사이의 경계도 명확하지 않을 수 있습니다. 이 가이드에서 "통합 테스트"에 해당하는 경우는 아래와 같습니다.
위에서 말한 것과 같이 여러 모듈이 결합된 경우
외부 시스템을 이용하는 경우
다른 애플리케이션으로 네트워크 요청을 하는 경우 (날씨 서비스 API와 같은)
파일이나 데이터베이스의 입출력이 일어나는 경우
컴포넌트 테스트
리액트 컴포넌트들은 앱을 렌더링하는 역할을 합니다. 그리고 사용자들은 그 결과와 바로 상호작용하게 됩니다. 앱의 비즈니스 로직이 높은 테스트 커버리지를 가지고 있고 올바르게 동작한다 해도 컴포넌트 테스트 없이는 잘못된 UI를 사용자들에게 전달할 가능성이 있습니다. 컴포넌트 테스트는 단위, 통합 테스트 모두에 해당할 수 있지만 리액트 네이티브에서 핵심적인 부분이기에 이를 따로 다루도록 하겠습니다.
리액트 컴포넌트를 테스트하기 위해서는 이 두 가지를 테스트해야 합니다.
상호작용: 사용자와 상호작용할 때 (예를 들어 사용자가 버튼을 누를 때) 컴포넌트가 올바르게 동작하고 있다는 것을 확인
렌더링: 리액트에서 사용하는 렌더링 출력이 올바른지 (예를 들어 버튼의 모양과 UI 배치) 확인
예를 들어 만약 onPress 리스너를 가지고 있는 버튼이 있다면 그 버튼이 제대로 된 모양을 가지고 있고 눌렀을 때 컴포넌트에 의해 제대로 처리되고 있는지 테스트해야 합니다.
이 테스트를 도와주는 몇 개의 라이브러리가 있습니다.
리액트의 Test Renderer, 리액트 코어와 함께 개발된 리액트 렌더러는 DOM이나 모바일 네이티브 환경에 의존하지 않고도 리액트 컴포넌트들을 순수 자바스크립트 객체로 렌더링 할 수 있게 해줍니다.
React Native Testing Library는 리액트 테스트 렌더러 위에 구축되고 다음 문단에서 설명할
fireEvent나queryAPI들을 추가합니다.
컴포넌트 테스트는 Node.js 환경에서 실행되는 자바스크립트 테스트입니다. 리액트 컴포넌트를 지원하는 iOS, 안드로이드, 또는 다른 플랫폼 코드는 고려하지 않습니다. 따라서 사용자에게 모든 것이 완벽하게 동작할 거란 100%의 확신은 줄 수 없습니다. 만약 iOS나 안드로이드 코드에 버그가 있다면 찾을 수 없을 겁니다.
사용자 상호작용 테스트
컴포넌트는 일부 UI를 렌더링하는 것 외에도 TextInput을 위한 onChangeText 또는 Button을 위한 onPress와 같은 이벤트를 처리합니다. 다른 함수와 이벤트 콜백 또한 포함하고 있을 수 있습니다. 이 예제를 보세요.
function GroceryShoppingList() {
const [groceryItem, setGroceryItem] = useState('');
const [items, setItems] = useState<string[]>([]);
const addNewItemToShoppingList = useCallback(() => {
setItems([groceryItem, ...items]);
setGroceryItem('');
}, [groceryItem, items]);
return (
<>
<TextInput
value={groceryItem}
placeholder="Enter grocery item"
onChangeText={text => setGroceryItem(text)}
/>
<Button
title="Add the item to list"
onPress={addNewItemToShoppingList}
/>
{items.map(item => (
<Text key={item}>{item}</Text>
))}
</>
);
}
사용자 상호작용을 테스트할 때 컴포넌트를 사용자 관점에서 테스트하세요. 페이지에 뭐가 있을지, 상호작용할 때 어떤 변화가 있을지.
저는 경험상 사용자가 보거나 들을 수 있는 것들을 사용하는 걸 선호합니다.
- 렌더링된 텍스트 또는 accessibility helpers를 사용할 때 추론하기
반대로 아래의 테스트는 피하세요.
컴포넌트 props나 상태를 추론하기
테스트 ID 쿼리
props나 상태와 같은 자세한 구현 사항을 테스트하는 것을 피하세요. 그런 테스트들은 작동하긴 하지만 사용자가 컴포넌트에 어떻게 반응할지에 중심이 맞춰져 있는 것이 아니며 리팩터링으로 인해 (예를 들어 이름이나 클래스 컴포넌트를 훅으로 변경하는 경우) 깨지기도 합니다.
특히 리액트 클래스 컴포넌트는 내부 상태, props 또는 이벤트 핸들러와 같은 자세한 구현 사항을 테스트하는 경향이 있습니다. 구현 사항을 테스트하는 것을 피하기 위해서 컴포넌트에 대한 의존을 어렵게 하는 훅을 사용한 함수 컴포넌트를 선호하세요.
React Native Testing Library와 같은 컴포넌트 테스팅 라이브러리는 신중하게 선택하여 제공되는 API를 통해 사용자 중심 테스트를 쉽게 만들어 줍니다. 아래의 예시에서는 사용자가 컴포넌트와 상호작용하고 매칭되는 Text 노드를 렌더링 된 화면에서 찾아주는 getAllByText 쿼리 함수를 시뮬레이션하기 위해 fireEvent 메서드 changeText와 press를 사용합니다.
test('given empty GroceryShoppingList, user can add an item to it', () => {
const {getByPlaceholderText, getByText, getAllByText} = render(
<GroceryShoppingList />,
);
fireEvent.changeText(
getByPlaceholderText('Enter grocery item'),
'banana',
);
fireEvent.press(getByText('Add the item to list'));
const bananaElements = getAllByText('banana');
expect(bananaElements).toHaveLength(1); // 'banana'가 리스트에 있는 것을 예상
});
이 예시는 테스트가 함수 호출 시에 어떻게 상태가 변경되는지를 테스트하는 것이 아닙니다. 사용자가 TextInput의 텍스트를 변경시키고 Button을 눌렀을 때 어떤 일이 일어나는지를 테스트하는 것입니다!
렌더링 이후의 출력 테스트
스냅샷 테스팅은 Jest가 지원하는 고급 테스트입니다. 매우 강력하고 저수준의 툴이기 때문에 사용할 때 추가적인 주의가 필요합니다.
"컴포넌트 스냅샷"은 Jest에 내장된 커스텀 리액트 직렬 변환기로 생성된 JSX와 비슷한 문자열입니다. 이 직렬 변환기를 사용하면 Jest가 사람이 읽을 수 있는 문자열로 리액트 컴포넌트 트리를 번역해 줍니다. 다르게 말하면 컴포넌트 스냅샷은 테스트 중에 생성된 컴포넌트의 렌더링된 화면을 텍스트로 표현한 것입니다. 아래와 같이 보일 수 있습니다.
<Text
style={
Object {
"fontSize": 20,
"textAlign": "center",
}
}>
Welcome to React Native!
</Text>
스냅샷 테스팅은 보통 컴포넌트를 먼저 구현한 후에 스냅샷 테스트를 실행시킵니다. 그리고 스냅샷 테스트는 스냅샷을 생성하고 참조 스냅샷으로 리포지토리에 파일로 저장시킵니다. 그런 다음 코드 리뷰 중에 커밋되고 확인됩니다. 추후에 컴포넌트 출력을 변경하면 스냅샷은 변경될 것이고 테스트는 실패하게 될 것입니다. 그렇게 되면 테스트를 통과할 수 있도록 저장된 참조 스냅샷을 다시 수정해야 합니다. 그렇게 변경된 사항은 또 커밋되고 리뷰되어야 합니다.
스냅샷은 아래의 단점들을 가지고 있습니다.
개발자나 리뷰어라면 스냅샷에서의 변경이 의도되었는지 혹은 버그의 증거인지 판별하는 게 어렵습니다. 특히 대규모 스냅샷은 빠르게 이해하기 어려워지고 가치가 낮아집니다.
스냅샷이 생성되었을 때 렌더링된 출력이 실제로는 틀렸음에도 맞는 케이스로 간주됩니다.
스냅샷이 실패하면 어떤 변경이 예상되는지 주의 깊게 조사하는 것 대신
--updateSnapshotJest옵션을 사용하고 싶은 유혹이 생길 수 있습니다. 그러므로 개발 규율이 필요합니다.
스냅샷 자체는 구성 요소 렌더링 로직이 올바른지 확인하는 것이 아니라 예기치 않은 변경에 대한 보호 및 테스트 중인 반응 트리의 구성 요소가 예상되는 props(스타일 등)를 받는지 확인하는 데만 적합합니다.
작은 스냅샷만 사용하는 것이 좋습니다 (no-large-snapshots rule을 보세요). 두 반응 구성 요소 상태 간의 변화를 검증하려면 snapshot-diff를 사용합니다. 의심스러울 때는 앞에서 설명한 대로 명시적인 기대치를 선호합니다.
End-to-End 테스트
E2E(End-to-End) 테스트에서는 장치 (또는 시뮬레이터나 에뮬레이터)에서 앱이 사용자 관점에서 예상대로 작동하는지 확인합니다.
이는 릴리스 구성에서 앱을 구축하고 이에 대한 테스트를 실행함으로써 수행됩니다. E2E 테스트에서는 더 이상 리액트 구성 요소, 리액트 네이티브 API, 리덕스 스토어 또는 비즈니스 로직에 대해 고려하지 않습니다. 이것은 E2E 테스트의 목적이 아니며 E2E 테스트 중에는 접근할 수도 없습니다.
대신 E2E 테스트 라이브러리를 사용하면 앱 화면의 요소를 찾아 제어할 수 있습니다. 예를 들어 실제 사용자와 같은 방식으로 버튼을 누르거나 텍스트를 TextInputs에 삽입할 수 있습니다. 그러면 앱 화면에 특정 요소가 있는지, 표시되는지, 텍스트가 무엇인지 등에 대해 알 수 있습니다.
E2E 테스트는 앱의 일부가 작동하고 있다는 가장 높은 신뢰성을 제공합니다. 다만 포기해야 할 것들은 아래를 포함합니다.
다른 유형의 테스트에 비해 더 긴 시간이 걸립니다.
실행 시간이 더 느립니다.
더 취약한 경향이 있습니다 ("flaky" 테스트는 코드를 변경하지 않고 무작위로 통과하고 실패하는 테스트입니다).
인증 흐름, 핵심 기능, 결제 등과 같은 앱의 중요한 부분을 E2E 테스트로 다뤄보세요. 앱의 덜 중요한 부분에서는 더 빠른 자바스크립트 테스트를 사용하세요. 더 많은 테스트를 추가할수록 여러분의 자신감은 더 높아지지만 더 많은 시간을 코드를 유지하고 실행하는 데에 사용하게 될 것입니다. 절충점을 고려하고 여러분에게 가장 좋은 것이 무엇인지 결정하세요.
리액트 네이티브 커뮤니티에서는 Detox가 리액트 네이티브 앱을 위해 설계되었기 때문에 인기 있는 프레임워크입니다. iOS 및 안드로이드 앱 공간에서 또 다른 인기 있는 라이브러리는 Appium 또는 Maestro 입니다.
요약
이 가이드를 재미있게 읽고 어떤 것이든 배울 수 있기를 바랍니다. 여러분의 앱을 테스트할 수 있는 많은 방법이 있습니다. 처음에 바로 무엇을 사용할지 결정하기는 어려울 수 있습니다. 하지만 멋진 리액트 네이티브 앱에 테스트를 추가하기 시작하면 모든 것이 곧 이해될 것이라고 믿습니다. 그러니 무엇을 기다리고 있나요? 여러분의 커버리지를 높이세요!
