🚀 테스트코드에 대한 참고 자료

보통 이런 Red, Green, Refactor 라는 싸이클을 돈다.
테스트를 통과시키고, 중복을 제거하면서 개발을 진행하는 사이클인데.. 이것만 보면 쉽게 접근할 수 있을 것 같은데.. 많은 사람들이 TDD에 도전하고 많이 좌절한다.
연사자분도 지금 좌절한다.

🚀 왜 어려운가?

코드 자체가 Testable하지 않아서 그렇다.
Testable한 코드를 작성하지 않아서 그렇다.
우리가 유지보수하는 서비스는 레거시가 커서 Testable하기 쉽지 않다.

🚀 어떻게 하는가?

관심사의 분리(Separation of concerns)
자신이 관심갖고 있는 부분에만 관심가져서 개발하는 방식을 말한다.

🚀 TDD의 가장 중요한 것

자동화된 테스트의 실행

🚀 Todo App을 테스트로 작성

제일 먼저 테스트 코드 작성 (App component를 바타응로 자것ㅇ)

import React from 'react';
import {render} from '@testing-library/react';
import App from './App';

describe('App', () => {
	it('redners tasks', () => {
		const {container} = render({
			<App />
		});
		
		expect(container).toHaveTextContent('아무 일도 하기 싫다.');
	});
});

이런 테스트 코드를 작성한다.

🚀 TDD의 원칙

이걸 빠르게 통과시키기 위해서 수단 방법을 가리지마라. 이게 원칙이다.

import React from 'react';

export default function App() {
	return (
		<div>
			<h1>To-do</h1>
			<ul>
				<li>
					아무일도 하기 싫다.
				</li>
			</ul>
		</div>
	);
}

이게 우리가 원하는 모습은 아니다.

🚀 관심사의 분리

관심사의 분리를 위해서 우리가 원하는 형태로 분리한다.

List.test.jsx를 만든다.

import {render} from '@testing-library/react';
import List from './App';

describe('List', () => {
	it('redners tasks', () => {
		const {container} = render({
			<List />
		});
		
		expect(container).toHaveTextContent('아무 일도 하기 싫다.');
	});
});

List.jsx를 만든다.

import React from 'react';

export default function App() {
	return (
			<ul>
				<li>
					아무일도 하기 싫다.
				</li>
			</ul>
	);
}

이후 실행을 하면 테스트가 통과가 된다.

그런데, 이 부분이 테스트가 아니다. 우리는 배열을 받아서 그 배열에 있는 Todo 제목들을 보여주려고 하는 것이다.

import {render} from '@testing-library/react';
import List from './App';

describe('List', () => {
	it('redners tasks', () => {
		const tasks = [{id:1, title: '아무 일도 하기 싫다.'}]
		const {container} = render({
			<List tasks={tasks}/>
		});
		
		expect(container).toHaveTextContent('아무 일도 하기 싫다.');
	});
});

import React from 'react';

export default function App({tasks}) {
	return (
			<ul>
			{tasks.map((task)=>{
				<li key={task.id}>
					{task.title}
				</li>
			})}
			</ul>
	);
}

이렇게 바꿔주면 동작을 한다.

여기까지도 살짝 불안하다. 테스트가 제대로 동작하는 지 알 수 없다.

import {render} from '@testing-library/react';
import List from './App';

describe('List', () => {
	it('redners tasks', () => {
		const tasks = [{id:1, title: '아무 일도 하기 싫다.'}, {id:2, title: '건물 매입'}]
		const {container} = render({
			<List tasks={tasks}/>
		});
		
		expect(container).toHaveTextContent('아무 일도 하기 싫다.');
		expect(container).toHaveTextContent('건물 매입');
	});
});

이렇게 하면 테스트를 통과한다. List는 테스트를 잘 통과하고 있다.

다시 App을 수정해보자.

import React from 'react';

import List from './List';

export default function App() {
	return (
		<div>
			<h1>To-do</h1>
			<List />
			</ul>
		</div>
	);
}

그렇게 하면 테스트가 깨진다.

각 테스트는 독립적인데, App 내의 List는 상태를 바꾸지 않고 있기 때문이다. 그래서 임의로 바꾸지 안흥면 테스트가 깨지게 되어있다.

import React from 'react';

import List from './List';

export default function App() {
		const tasks = [{id:1, title: '아무 일도 하기 싫다.'}, {id:2, title: '건물 매입'}]
		
	return (
		<div>
			<h1>To-do</h1>
			<List tasks={tasks}/>
			</ul>
		</div>
	);
}

임의로 상태를 만들어서 넣어주면, 테스크는 통과된다.

🚀 팀의 문화

테스트와, 자동화된 테스트 코드를 보고 브라우저를 볼 필요는 거의 없다.

거의 확실한 피드백 루프가 있고, 거의 확실한 피드백 모드가 있기 때문이다.

🚀 Redux

왜 쓰는가?
상태관리 측면에서 쓴다.
좀 더 깊게 들어가서 보자.
React의 관심사 때문에 쓴다.
React의 관심사는 state reflection 즉, 상태 반영이다.
상태가 전달되면 상태를 반영하는 것을 신경쓴다.
그래서 리액트는 상태 관리에 대해서는 관심이 없다. 반영에만 관심이 있을 뿐이지.
로그인 기능 등이 추가되고 앱이 비대해지면, 관심사 분리가 어렵고 테스트하기 어려운걸 자주 확인할 수 있다.

Container component만 redux의 존재를 알고 얘만 상태를 가져온다.

그 상태를 가져와서 presentation component에 전달한다.

🚀 항상 컴포넌트 입장에서 이런 질문이 나온다.

응~ 그거 내 관심사 아니야.

그래서 요소와 컴포넌트를 작게 작게 만들 수 있도록 주의를 기울여야 한다.

🚀 SRP :: Single Responsibility Principle

의존성이 생기지 않고 또 다시 테스트를 쉽게 작성할 수 있고, 그래야 TDD를 할 수 있다.

🔗 관련 링크:

📜 라이센스: MIT 라이센스

👥 기여자: 기여자 목록 보기

💻 개발 문서

⚖ 개발/학습 기록 바로가기

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

🚀 테스트코드에 대한 참고 자료

테스트코드에 대한 참고 자료

테스트 관련 학습에 도움될 자료들

제로초님의 Jest 테스트 강의

프론트앤드 테스트 강의

실무에 바로 적용하는 프런트엔드 테스트

근본있는 프론트앤드 유닛테스트

TDD 책

코드와함께 살펴보는 프론트엔드 단위 테스트 - 배달의민족

프론트엔드 개발자가 알아야 할 ‘유닛 테스트’ 작성법

프론트엔드에서 의미있는 테스트 코드 작성하기 - 미디움

프론트엔드 테스트 코드 도입기

모던 프론트엔드 테스트 전략

프론트앤드 개발을 위한 테스트 입문

실용적인 프론트엔드 테스트 전략 - NHN Cloud

Toast UI의 테스트코드 관련 내용 모음

프론트앤드에서도 TDD가 가능한 것을 보여줍니다.

📚 영상 내용 정리

🚀 테스트 코드 작성하시나요?

🚀 왜 안하게 되는가?

🚀 TDD (Test Driven Development)