웹 API를 호출하는 코드를 작성하다 보면 항상 마주치는 고민이 있는데요. "이 코드는 어떻게 테스트하지?" 하는 문제입니다. 실제 API를 호출하는 테스트는 네트워크 상태에 따라 결과가 달라지고, 외부 서비스의 응답을 마음대로 흉내내기도 어렵죠. 이럴 때 유용한 것이 바로 HTTP 모킹 라이브러리인데요. Rust 생태계에서는 mockito 크레이트가 가장 널리 사용되고 있습니다. 이 글에서는 mockito를 사용해서 HTTP 요청을 보내는 코드를 어떻게 테스트하는지 단계별로 살펴보겠습니다. mockito란? mockito는 Rus
Rust로 어느 정도 규모가 있는 코드를 짜다 보면 한 번쯤 부딪히는 문제가 있는데요. 바로 외부 의존성을 단위 테스트에서 어떻게 분리할 것인가 하는 문제입니다. 데이터베이스에 붙는 함수나 결제 게이트웨이를 호출하는 로직을, 매번 실제 서비스를 띄워놓고 검증할 수는 없잖아요. 자바에서는 Mockito, 파이썬에서는 unittest.mock이 이런 역할을 해주는데요. Rust 진영에서 이에 해당하는 라이브러리가 바로 mockall입니다. mockito가 HTTP 요청을 가로채는 도구라면, mockall은 트레이트의 구현체를 통째로 흉
"장바구니 기능 만들어줘." 코딩 에이전트에게 이렇게 요청하면 뭔가 그럴듯한 코드가 나옵니다. 그런데 결과를 보면 내가 원했던 것과 미묘하게 다릅니다. 상품 수량 변경이 빠져 있거나 할인 적용 로직이 내 의도와 다릅니다. 합계를 계산하는 방식이 요구사항과 안 맞기도 하죠. 에이전트가 멍청한 걸까요? 아닙니다. 내가 원하는 걸 충분히 명확하게 전달하지 않은 겁니다. 이런 식으로 분위기에 맡겨 코드를 생성하는 걸 **바이브 코딩(Vibe Coding)**이라고 부릅니다. 대략적인 의도만 던지고 에이전트가 알아서 해주길 바라는 거죠. 간
테스트를 열심히 작성했는데 과연 우리 코드가 어디까지 테스트되고 있는 걸까요? "이 모듈은 테스트를 꽤 많이 짰으니까 괜찮겠지"라고 막연하게 생각하다가 정작 핵심 에러 처리 분기는 한 번도 실행된 적이 없었다는 걸 나중에 발견하는 경우가 종종 있습니다 😅 코드 커버리지는 이런 사각지대를 눈에 보이게 만들어주는 도구입니다. Rust에서는 cargo-llvm-cov가 이 역할을 맡고 있는데 LLVM의 소스 기반 커버리지 기능을 활용해서 정확한 측정 결과를 제공해요. 이번 글에서는 설치부터 기본 사용법, 여러 리포트 형식, CI 연동까
웹 애플리케이션을 개발하다 보면 "이거 진짜 브라우저에서도 잘 되나?" 하는 불안감이 들 때가 있죠. 단위 테스트로 함수 하나하나는 검증했지만, 사용자가 실제로 버튼을 클릭하고 페이지를 이동하고 폼을 제출하는 흐름까지 테스트하려면 별도의 도구가 필요합니다. 이런 종단간(End-to-End) 테스트를 위해 등장한 것이 바로 Playwright입니다. 이 글에서는 Playwright가 무엇인지 살펴보고, 설치부터 테스트 작성과 실행, 그리고 디버깅까지 E2E 테스트의 전체 흐름을 다뤄보겠습니다. Playwright란? Playwrigh
올인원(All-in-one) 테스팅 프레임워크 Vitest를 사용하면 다른 라이브러리 설치 없이 바로 mocking과 spying 기능을 쓸 수 있는데요. 그런데 여기서 mocking과 spying을 한국어로 뭐라고 번역해야 모르겠네요. 😅 주변에서 보면 "모킹"과 "스파잉"으로 그냥 영어를 차용해서 쓰고 있는 것 같습니다. Mocking 이란? 먼저 mocking이 생소하신 분들을 위해서 mocking 대한 기본 개념부터 잡고 들어가는 게 좋을 것 같습니다. mocking은 단위 테스트를 작성할 때, 해당 코드가 의존하는 부분을
테스트를 작성하다 보면 여러 테스트에 걸쳐서 반복되는 로직이 생기기 마련인데요. 이러한 공통 로직을 모든 테스트마다 중복해서 작성하면 개발 생산성이 떨이지고 유지보수가 힘들어집니다. 이번 포스팅에서는 Vitest를 이용해서 테스트 전이나 후에 항상 실행되야 하는 로직을 효과적으로 실행하는 방법에 대해서 알아보겠습니다. 테스트 대상 코드 데이터베이스에 접근하는 애플리케이션에 대한 테스트를 작성한다는 가정 하에 예제 코드를 작성해보겠습니다. 최대한 간단한 예제를 위해서 자바스크립트 배열로 데이터베이스를 대신하도록 할께요. 사용자 데이터
길고 복잡한 코드에 대한 테스트를 작성하다보면 테스트 코드의 양도 비례해서 늘어나게 되기 마련지요? 하나의 파일 안에 테스트 코드가 많아지면 도대체 어느 테스트가 어떤 기능을 위한 것인지 빠르게 파악하기가 어려워집니다. 게다가 디버깅을 하다보면 특정 테스트만 실행하거나 특정 테스트만 제외하고 테스트를 해야하는 경우도 생기죠. 이번 포스팅에서는 이러한 상황을 효과적으로 대처하기 위해서 Vitest로 어떻게 테스트를 깔끔하게 묶어서 관리하고 테스트 별로 실행 제어를 할 수 있는지 알아보려고 합니다. 테스트 케이스와 스위트 테스트를 그룹
테스트를 작성하시다보면 어떤 함수나 호출한 후 예상 결과가 실제과 동일한지 검증하는 작업을 많이 하는데요. Vitest는 테스트를 작성할 때 효과적인 결과값 매칭이 가능하도록 Jest의 API와 호환되는 다양한 매처 함수를 제공하고 있습니다. 이번 포스팅는 실전 테스팅에서 많이 사용되는 Vitest의 매처 함수를 하나씩 살펴보면서 언제 어떻게 활용하는지 알아보겠습니다. 차세대 테스팅 프레임워크로 각광받고 있는 Vitest에서 생소하시다면 먼저 소개 포스팅을 읽어 보시고 돌아오시기를 추천드립니다. 검증 (Assertion) 테스트라는
ES6에서 클래스(class)가 도입되고 타입스크립트가 대중화되면서 이제 클래스를 사용하는 자바스크립트 코드를 흔하게 볼 수 있게 되었습니다. 뿐만 아니라 Angular나 NestJS처럼 클래스를 기반으로 동작하는 라이브러리나 프레임워크도 점점 늘어나고 있지요. 하지만 아직 클래스를 모킹하거나 테스팅하시는데 어려움을 겪는 개발자 분들이 많은 것 같습니다. 이번 포스팅에서는 자바스크립트의 대표적인 테스팅 프레임워크인 Jest를 사용하여 클래스를 모킹(mocking)하고 테스트 코드를 작성해보겠습니다. 본 포스팅을 이해하시려면 jest
자바스크립트 생태계에서 Vite가 번들러의 왕으로 등극하면서, 덩달아 자매 제품인 Vitest도 인기도 높아지고 있는데요. State of JS 2024 설문 결과를 보면 오랫동안 테스팅 프레임워크의 강자였던 Jest까지 위협하는 모습입니다. 이번 포스팅에서는 차세대 테스팅 프레임워크로 각광받고 있는 Vitest에 대해서 살펴보는 시간을 가져보겠습니다. Vitest란? Vitest는 Vite를 기반으로 작동하는 테스팅 프레임워크입니다. 이전에 나왔던 Jest처럼 테스트 실행뿐만 아니라 모킹(mocking)과 스냅샷(snapshot)
테스트를 작성하다보면 날짜와 시간이 골칫거리가 되는 경우가 많습니다. 날짜와 시간은 다른 데이터와 다르게 항상 변하기 때문인데요. 이번 포스팅에서는 Jest를 이용하여 날짜와 시간을 효과적으로 모킹(mocking)하는 방법에 대해서 알아보겠습니다. 테스팅 프레임워크인 Jest에 생소하신 분들은 먼저 관련 포스팅를 읽어 보시고 돌아오시기를 추천드립니다. 예제 코드 자바스크립트의 Intl API를 사용하여 현재 날짜를 주어진 언어에 따라 문자열로 변환해주는 간단한 함수를 작성해보겠습니다. 이 함수는 Date() 생성자를 통해서 현재 날
제가 몇 년 전에 블로그에서 npm 패키지 저장소에 faker라는 이름으로 등록되어 있는 라이브러리를 소개해 드린 적이 있는데요. 안타깝게도 2022년에 faker를 유지보수하던 개발자가 불미스러운 일을 저질러 더 이상 사용하면 안 되는 라이브러리가 되었습니다. (오픈 소스 커뮤니티에 시사하는 바가 컸던 사건이므로 관심있으신 분은 관련 기사를 참고하시기 바랍니다.) 현재는 npm 패키지 저장소에 @faker-js/faker라는 패키지 이름으로 등록된 새로운 라이브러리가 예전에 faker 라이브러리를 대신하고 있는데요. 과거의 실수를
유지보수가 용이하고 안정적으로 동작하는 NestJS API를 개발하려면 각각의 엔드포인트가 잘 작동하는지 확인하는 것이 필수적입니다. 이번 글에서는 Jest와 Supertest를 활용하여 효과적으로 NestJS 앱을 테스트하는 방법에 대해서 알아보겠습니다. 실습 프로젝트 구성 먼저 간단한 실습을 위해서 NestJS 프로젝트가 하나 필요할 것 같은데요. 터미널에서 NestJS CLI 도구의 nest new 명령어를 실행하여 새로운 프로젝트를 구성하도록 하겠습니다. NestJS CLI를 설치하고 NestJS 프로젝트를 구성하는 기본적인
이번 포스팅에서는 테스트 커버리지(coverage)가 무엇인지 알아보고 Jest를 이용해서 테스트 커버리지를 수집하는 방법에 대해서 알아보겠습니다. 테스트 커버리지(Test Coverage)란? 테스트 커버리지(test coverage)는 코드 커버리지(code coverage)라고도 하는데요. 쉽게 말해 코드가 얼만큼 테스트되고 있는지를 나타내는 소프트웨어의 품질 지표입니다. 테스트 커버리지가 높은 소프트웨어는 버그가 발생할 확률이 적기 때문에 사용자가 좀 더 신뢰하고 사용할 수 있습니다. 당연히 반대로 테스트 커버리지가 낮은 소
지난 포스팅에서는 커스텀(custom) React Hook을 사용하여 양식(form) UI를 구현해보았는데요. 이번 포스팅에서는 이와 유사한 방식으로 React Hook 기반의 API를 제공하는 React Hook Form 라이브러리에 대해서 알아보려고 합니다. 새로운 라이브러리를 배우는 가장 효과적인 방법은 그 라이브러리를 이용해서 무언가를 만들어보는 것이 겠죠? 본 포스팅을 끝까지 따라오시면 아래와 같은 로그인 폼(form)을 만드실 수 있으실 거 에요 😁 패키지 설치 React Hook Form 라이브러리는 자바스크립트 패키
React v16.8에서 리액트 훅(React Hook)이 소개된 이후로 많은 프로젝트에서 커스텀(custom) 훅 함수를 사용하고 있는 것 같은데요. 이번 포스팅에는 리액트 훅(React Hook)을 테스트하는 방법에 대해서 알아보겠습니다. 예제 React Hook 먼저 테스트 대상이 될 간단한 React Hook 함수 하나를 작성해보겠습니다. 아래 useToggle() 함수는 true 또는 false가 될 수 있는 상태 state와 그 상태값을 반전할 수 있는 함수 toggle()을 배열에 담아 반환합니다. 초기 상태값을 ini
지난 포스팅에서 가짜 데이터를 만들 때 사용하는 Faker.js에 대해서 간단히 알아보았는데요. 이번 포스팅에서는 실제로 테스트를 작성할 때 Faker.js를 어떻게 활용할 수 있는지에 대해서 다뤄보려고 합니다. 테스트 대상 코드 작성하기 먼저 테스트 대상이 될 임의의 함수를 하나 필요한데요. 사용자 객체를 인자로 받아 회원 가입을 처리해주는 함수를 작성해보겠습니다. 이 함수는 인자로 넘어온 사용자의 이메일과 비밀번호에 대한 입력값 검증이 실패할 경우 error 속성에 오류 메시지를 담아서 반환하며, 회원 가입이 성공한 경우 use
중요: 본 포스팅에서 소개하고 있는 faker라는 라이브러리는 안타깝게도 안타깝게도 2022년에 faker를 유지보수하던 개발자가 불미스러운 일을 저질러 더 이상 사용하면 안 되는 라이브러리가 되었습니다. 가짜 데이터 생성을 위한 라이브러리가 필요하신 분들은 새로운 포스팅을 참고하시길 바랍니다. 가짜 데이터 시제품(prototype)을 개발하거나, 단위 테스트를 작성할 때 가짜 데이터가 필요할 때가 자주 있습니다. 이럴 때, 직접 가짜 데이터를 하드코딩(hard-coding)할 수도 있겠지만, 좀 더 편하고 빠르게 가짜 데이터를 얻
웹에서는 UI가 비동기로 업데이트되는 경우가 참 많죠? UI가 변경될 때까지 기다려줘야 하기 때문에 많은 개발자들이 테스트하기 어려운하는 부분입니다. 이번 포스팅에서는 Testing Library로 비동기(asynchronous)로 작동하는 React 컴포넌트를 테스트하는 방법에 대해서 알아보겠습니다. 예제 컴포넌트 우선 테스트 대상이 될 간단한 React 컴포넌트 하나를 작성해보도록 하겠습니다. 아래 <Switch/> 컴포넌트 함수는 on 상태값에 따라 ON 버튼 또는 OFF 버튼을 리턴합니다. on 상태값은 최초에는 false이