들어가며 벨로퍼트님의 테스팅 튜토리얼을 공부한 내용을 정리하는 글입니다. 비동기적으로 바뀌는 컴포넌트 UI 테스트 const { useState, useEffect } = require("react"); const DelayedToggle = () => { const [toggle, setToggle] = useState(false); useEffect(() => { setInterval(() => { setToggle((prev) => !prev); }, 1000); }, []); return ( 상태 : {toggle ? "On" : "Off"} {toggle && 토글이 켜졌다!} ); }; export default DelayedToggle; 다음과 같이 1초마다 상태 값이 바뀌는 컴포넌트가 있습..

들어가며 벨로퍼트님의 테스팅 튜토리얼을 공부한 내용을 정리하는 글입니다. 이번에는 TDD 방식으로 Todo List를 만들어본다. 전체적인 시나리오는 벨로퍼트님을 따라가지만 컴포넌트 자체는 스스로 만들어볼 생각이다. 컴포넌트 계획 Todo List를 만들기 위해서 필요한 컴포넌트는 무엇일까? ▶ Todo Form : Input과 Button으로 이루어진 Form 컴포넌트이다. Todo App으로부터 Submit을 전달받아 새로운 항목을 추가할 수 있어야 한다. ▶ Todo Item : 각 Todo 항목을 보여주는 컴포넌트이다. 텍스트를 클릭하면 텍스트에 삭제선이 그어져야 하고, 우측 삭제 버튼을 누르면 항목이 사라져야 한다. ▶ Todo List : Todo 배열을 받아와서 여러 개의 TodoItem 컴..

들어가며 벨로퍼트님의 테스팅 튜토리얼을 공부한 내용을 정리하는 글입니다. 이 전에 Test Coverage를 공부할 때 한번 정리했지만 사용의 전반적인 흐름이 더 좋다고 느껴서 다시 정리한다. react-testing-library 모든 테스트를 DOM 위주로 진행하는 방식이다. 컴포넌트를 리팩토링할 때, 내부 구조 및 네이밍은 많이 바뀔 수 있지만 작동 방법은 크게 바뀌지 않는다. react-testing-library는 이러한 특징을 중요하게 생각해서 컴포넌트의 기능이 똑같이 작동한다면, 컴포넌트의 내부 구현 방식이 변해도 테스트가 실패하지 않도록 설계되어있다. 테스트 코드 const Profile = ({ username, name }) => { return ( {username} ({name}) ..

들어가며 벨로퍼트님의 테스팅 튜토리얼을 공부한 내용을 정리하는 글입니다. TDD ? TDD는 테스트를 통해서 개발을 이끌어나가는 형태의 개발론이다. 먼저 테스트 코드를 작성하고, 구현을 하는 방식이라고 보면 된다. TDD에는 3가지 절차가 있다. 실패 첫 번째 절차로 실패이다. 말 그대로 실패하는 테스트 케이스를 먼저 만드는 것이다. 상황에 따라 다르지만, 먼저 구현할 기능부터 하나씩 테스트 케이스를 작성한다. 성공 두 번째 절차로 성공이다. 앞서 작성한 실패하는 테스트 케이스를 통과시키기 위해서 코드를 작성하는 것을 말한다. 리팩토링 구현한 코드가 테스트를 통과한다면, 중복되는 코드 또는 개선시킬 방법이 있는 코드를 리팩토링 시킨다. 리팩토링을 했을 때 테스트 케이스가 성공하면 다른 기능을 다시 첫 번..

들어가며 벨로퍼트님의 테스팅 튜토리얼을 공부한 내용을 정리하는 글입니다. 작업환경 설정 간단한 자바스크립트 환경에서 함수 테스트 코드를 작성하기 위해서 테스트 환경을 만들어보자! npm init -y npm install --save jest @types/jest npm init -y 명령어를 통해서 자바스크립트 프로젝트를 만들고 jest를 설치해준다. 테스트 작성하기 // javascript/sum/sum.js function sum(a, b) { return a + b; } export default sum; // 본인은 귀찮아서 그냥 react 환경에서 작성 ㅎㅎ... 아주 간단한 sum 함수이다. 테스트 코드를 작성하기 위해서 sum.test.js 파일을 작성하자 // javascript/sum/..

들어가며 바로 어제 테스팅 게시글을 하나 작성했는데, 이번에 또 좋은 글을 하나 더 발견해서 추가로 작성하려고 한다. 테스트란? 테스트 개발에서 테스트는 우리가 작성한 코드가 잘 동작하는지 검증하는 것을 의미한다. 솔직히 프론트엔드에서의 테스트는 어제 글을 작성했지만서도 실행해서 직접 확인하면 되는 거니 필요성을 못느꼇다. 하지만 테스트를 수동으로 하나하나하는 것은 번거로운 일이다. 이것을 자동화한다면 편하게 검증이 가능하다. 테스트 자동화의 이점 협업을 하다보면 내가 작성한 코드를 다른 사람이 수정해야하는 경우가 있고, 내가 다른사람의 코드를 수정하는 경우가 있다. 규모가 점차 커지면 커질수록 수동으로 확인하는 일에 많은 시간을 사용하거나 특정 상황을 고려하지 못한 경우 기능의 일부가 고장날 수 있다...