이전 포스팅에서는 Zod를 사용하여 하나의 스키마로 유효성 검증과 타입 선언을 한 번에 해결하는 방법에 대해서 살펴보았는데요. 이번 포스팅에서는 Zod에 제공하는 타입스크립트 친화적인 검증자를 사용하여 스키마를 정의하는 다양한 방법에 대해서 알아보도록 하겠습니다. 자료형 스키마 정의는 자료형울 명시하는 것부터 시작하는데요. Zod는 자바스크립트의 기본 자료형이나 Date와 같은 내장 클래스에 대응하는 검증자(validator) 함수를 제공합니다. 예를 들어, 이메일, 나이, 활성화 여부, 생성 일자로 이루어진 사용자 객체를 나타내는
이전 포스팅에서 타입스크립트로 코드를 작성하는 것과 무관하게 왜 자바스크립트 프로그램에서 유효성 검증이 필요한지에 대해서 알아보았는데요. 이번 포스팅에서는 최근 개발자들로부터 많은 인기를 끌고 있는 Zod를 사용하는 전반적인 방법에 대해서 알아보겠습니다. 라이브러리 설치 프로젝트에 zod라는 패키지를 npm으로 설치합니다. 그리고 Zod를 사용하실 때는 가급적 타입스크립트는 strict 모드로 쓰시기를 추천드릴게요. 이제 zod 패키지에서 z를 불러올 수 있으며, 이 녀석만 있으면 우리는 Zod의 모든 기능을 활용할 수 있습니다.
"타입스크립트로 코드를 짜니까 별도로 유효성 검증은 필요없는 거 아니에요?" 타입스크립트를 공부하고 계시거나 자바스크립트 경험이 많지 않은 개발자들로 부터 종종 받는 질문인데요. 정말 타입스크립트의 타입 검사가 자바스크립트의 유효성 검증을 대신할 수 있을까요? 이번 포스팅에서는 이러한 타입스크립트에 대한 오해를 풀어보는 시간을 갖도록 하겠습니다. 타입스크립트의 역할 이해를 돕기 위해서 타입스크립트로 간단한 코드를 함께 짜볼까요? 사용자 계정을 나타내는 Account 인터페이스를 선언하고 이것을 입력으로 받는 processAccoun
우리가 버그가 없는 코드를 작성하기 위해서 사용하는 타입스크립트도 알고 보면 은근히 버그 투성이라는 것을 혹시 알고 계신가요? 이번 포스팅에서는 많은 개발자들이 타입스크립트로 코딩하다가 겪게 되는 황당한 경우에 대해서 알아보고, 이러한 타입스크립트의 버그를 깔끔하게 고쳐주는 ts-reset이라는 라이브러리를 소개해드리려고 합니다. 배열의 includes() 함수의 배신 배열에 특정 요소가 존재하는지를 확인하기 위해서 includes() 함수를 많이 사용하시죠? 그런데 배열을 상대로 as const를 사용하여 읽기 전용(read-on
이번 포스팅에서는 테스트 커버리지(coverage)가 무엇인지 알아보고 Jest를 이용해서 테스트 커버리지를 수집하는 방법에 대해서 알아보겠습니다. 테스트 커버리지(Test Coverage)란? 테스트 커버리지(test coverage)는 코드 커버리지(code coverage)라고도 하는데요. 쉽게 말해 코드가 얼만큼 테스트되고 있는지를 나타내는 소프트웨어의 품질 지표입니다. 테스트 커버리지가 높은 소프트웨어는 버그가 발생할 확률이 적기 때문에 사용자가 좀 더 신뢰하고 사용할 수 있습니다. 당연히 반대로 테스트 커버리지가 낮은 소
지난 포스팅에서는 커스텀(custom) React Hook을 사용하여 양식(form) UI를 구현해보았는데요. 이번 포스팅에서는 이와 유사한 방식으로 React Hook 기반의 API를 제공하는 React Hook Form 라이브러리에 대해서 알아보려고 합니다. 새로운 라이브러리를 배우는 가장 효과적인 방법은 그 라이브러리를 이용해서 무언가를 만들어보는 것이 겠죠? 본 포스팅을 끝까지 따라오시면 아래와 같은 로그인 폼(form)을 만드실 수 있으실 거 에요 😁 패키지 설치 React Hook Form 라이브러리는 자바스크립트 패키
이번 포스팅에서는 MSW(Mock Service Worker) 라이브러리를 이용하여 백엔드 API를 모킹(mocking)하는 방법에 대해서 알아보겠습니다. Mock Service Worker란? MSW(Mock Service Worker)는 서비스 워커(Service Worker)를 사용하여 네트워크 호출을 가로채는 API 모킹(mocking) 라이브러리입니다. 쉽게 말해, 브라우저에 기생(?)해서 마치 백엔드 API인 척하면서 프론트엔드의 요청에 가짜 데이터를 응답해주는 녀석이라고 볼 수 있겠네요. 비교적에 최근에 도입된 웹 표준
이번 포스팅에서는 다국어 지원을 할 때 정말 유용하게 쓸 수 있는 자바스크립트의 Intl API에 대해 알아보도록 하겠습니다. Intl API 소개 여러 가지 언어로 서비스를 할 수 있도록 웹 애플리케이션을 설계하고 구현하는 과정을 흔히 국제화(internalization, i18n)라고 합니다. 이를 위해서는 웹페이지 상에 사용된 문구들을 단순히 번역하여 표시해주는 것만 뿐만 아니라 동일한 데이터를 언어나 지역별로 다른 형식으로 보여줘야 하는데요. 예를 들어, 12/11/21로 표시된 날짜 데이터를 한국 사용자들은 2012년 11
요즘 프론트엔드(front-end) 개발을 하다 보면 SPA, SSG, SSR이라는 상당히 비슷해서 헷갈리는 약어를 심심치 않게 들을 수 있는데요. 이번 포스팅에서는 모던 웹 개발의 트랜드를 주도하고 있는 이 3가지 랜더링(rendering) 기법에 대해서 이야기해보려고 합니다. SPA: Single Page Application SPA(Single Page Application)는 직역하면 단일 웹페이지로 돌아가는 애플리케이션을 의미하는데요. 이를 곧이곧대로 받아드리면 정말로 페이지 하나로 이루어진 정말 간단한 웹사이트로 오해할
국내 많은 서비스들이 당장 다국어 지원의 요구가 없더라도 향후 해외 진출을 염두해두고 개발 초기부터 애플리케이션을 국제화(internalization, i18n)하는 사례가 늘고 있는데요. 이번 포스팅에서는 React Intl 라이브러리를 이용해서 다국어를 지원하는 방법에 대해서 알아보겠습니다. React가 아닌 일반 자바스크립트에서 국제화하는 방법에 대해서는 관련 게시물을 참고 바랍니다. React Intl 설치 React Intl 라이브러리는 Node.js 패키지 매니저인 npm으로 설치할 수 있습니다. Locale: Langu
중요: 본 포스팅에서 소개하고 있는 faker라는 라이브러리는 안타깝게도 안타깝게도 2022년에 faker를 유지보수하던 개발자가 불미스러운 일을 저질러 더 이상 사용하면 안 되는 라이브러리가 되었습니다. 가짜 데이터 생성을 위한 라이브러리가 필요하신 분들은 새로운 포스팅을 참고하시길 바랍니다. 가짜 데이터 시제품(prototype)을 개발하거나, 단위 테스트를 작성할 때 가짜 데이터가 필요할 때가 자주 있습니다. 이럴 때, 직접 가짜 데이터를 하드코딩(hard-coding)할 수도 있겠지만, 좀 더 편하고 빠르게 가짜 데이터를 얻
테스트를 작성하다보면 다양한 테스트 데이터에 대해서 동일한 테스트 코드를 돌리고 싶을 때가 있죠? 이러한 테스팅 기법을 보통 파라미터화(parameterized) 테스팅이라고 하는데요. 이번 글에서는 Jest에서 제공하는 test.each()와 describe.each() 함수를 사용하여 파라미터화 테스트를 하는 방법에 대해서 배워보겠습니다. 파라미터화(parameterized) 테스트 간단한 실습을 위해 2개의 문자열의 인자로 받아 애너그램(anagram) 여부를 반환해주는 함수를 작성해볼까요? 이제 위 함수에 대한 테스트를 작성
이번 포스팅에서는 Jest를 이용해서 스냅샷(snapshot) 테스트를 하는 방법에 대해서 알아보겠습니다. Jest에 대한 기본적인 설치 및 사용 방법은 관련 포스팅를 참고하시길 바랍니다. 스냅샷 테스팅 스냅샷 테스팅(snapshot testing)이란 어떤 기능의 예상 결과를 미리 정확히 포착해두고 실제 결과에 비교하는 테스트 기법입니다. 테스트 대상 기능의 구현이 변경되어 실제 결과과 스냅샷을 떠놓은 예상 결과와 달라질 경우 해당 테스트 케이스는 실패하게 되는데요. 이럴 경우, 다시 새로운 스냅샷을 떠서 기존 스냅샷을 교체하는
웹 접근성(accessibility)을 준수하는 드롭다운(dropdown)를 구현하는 것은 생각보다 쉽지 않은 일입니다. 사실 가장 쉬운 방법은 지난 포스팅에서 소개했던 것처럼 HTML의 <select> 엘리먼트를 사용하는 것인데요. <select> 엘리먼트를 사용하면 내부에 있는 <option> 엘리먼트에 커스텀 스타일을 적용할 방법이 없기 때문에 스타일링에 한계가 있습니다. 그래서 여러 가지 엘리먼트를 이용해서 직접 드롭다운를 만드는 경우가 많은데요. 이 때, 시각적으로는 원하는 모습의 UI를 얻을지 몰라도, 웹 접근성 측면에서
지난 포스팅에서 jest.fn()과 jest.spyOn() 함수를 어떻게 사용하는지 배웠습니다. 이번 포스팅에서는 Jest에서 제공하는 또 다른 모킹 함수인 jest.mock()를 활용해서 좀 더 다양한 상황에서 모킹을 해보도록 하겠습니다. 자바스크립트 모듈 먼저 자바스크립트에서 모듈이 무엇인지에 대해서 간단하게 개념만 짚고 넘어가겠습니다. 모듈이란 어떤 코드를 다른 자바스크립트 파일에서 불러오기 편하도록 하나의 파일에 모아둔 것을 뜻하는데요. 프로젝트의 규모가 커지면 모든 자바스크립트 코드를 하나의 파일에 두기 어렵기 때문에, 자
올인원(All-in-one) 테스팅 프레임워크 Jest를 사용하면 다른 라이브러리 설치 없이 바로 소위 mocking 기능을 쓸 수 있는데요. 그런데 여기서 mocking을 한국어로 뭐라고 번역해야 모르겠네요. 😅 주변에서 보면 “모킹”으로 그냥 영어를 차용해서 쓰고 있는 것 같습니다. mocking 이란? 먼저 mocking이 생소하신 분들을 위해서 mocking 대한 기본 개념부터 잡고 들어가는 게 좋을 것 같습니다. mocking은 단위 테스트를 작성할 때, 해당 코드가 의존하는 부분을 가짜(mock)로 대체하는 기법을 말하
테스트를 작성하다보면 모든 테스트 함수에서 공통적으로 필요한 공통 로직이 필요할 때가 있습니다. 이번 포스팅에서는 Jest를 이용해서 이렇게 테스트 전이나 후에 항상 실행되야 하는 코드를 작성하는 방법에 대해서 알아보겠습니다. 테스트 대상 코드 데이터베이스에 접근하는 코드에 대한 테스트를 작성한다는 가정 하에, 다음과 같이 간단한 예제 코드를 작성해보겠습니다. 임의의 데이터베이스 역할을 하는 모듈로서 사용자 데이터를 저장하기 위한 users 배열을 가지고 있습니다. data 모듈에 저장되어 있는 users 배열에 사용자 데이터를 조
지난 포스팅에서 Jest로 기본적인 테스트 코드 작성하는 방법에 대해서 알아보았습니다. 자바스크립트 언어 특상 상 실제 프로젝트에서는 비동기(Asynchronous)로 돌아가는 코드를 테스트해야 할 일이 많은데요. Jest Runner가 비동기 코드에 대한 테스트라는 사실을 인지할 수 있도록 테스트를 작성해주지 않으면 예상치 못했던 테스트 결과에 당황할 수가 있습니다. 이번 포스팅에서는 이러한 비동기 코드에 대한 테스트를 작성할 때 흔히 하는 실수들과 적절한 대응 방법에 대해서 알아보겠습니다. 콜백 함수 테스트 먼저 콜백 함수를 이
Jest는 페이스북에서 만들어서 React와 더불어 많은 자바스크립트 개발자들에게 사랑받고 있는 테스팅 라이브러리입니다. 출시 초기에는 프론트엔드에서 주로 쓰였지만 최근에는 백엔드에서도 기존의 자바스크립트 테스팅 라이브러리를 대체하고 있습니다. Jest: All-in-one 테스팅 라이브러리 페이스북에서는 Jest를 단순한 테스팅 라이브러리가 아닌 "테스팅 프레임워크"라고 부르는 만큼 기존 자바스크립트 테스팅 라이브러리와는 차별점이 있습니다. Jest 이전에는 자바스크립트 코드를 테스트하라면 여러 가지 테스팅 라이브러리를 조합해서