eui-jin.log

에러 처리 개선 과정

Sat, 03 May 2025 07:41:15 GMT

에러 처리에 대한 문제점 인식

최근 포트폴리오 기반의 면접을 진행하던 중 에러 처리 방식의 확장성과 공통화 여부에 대한 질문을 받았습니다. 그에 대한 대답을 하며, 제가 구현한 API 요청 로직에서 개선할 여지가 많다는 점을 인식하게 되었습니다.

기존 API 구조 분석

첫 번째로 현재 구조는 다소 분산되어 있었습니다. 이전에 리펙토링했던 대로 각각의 역할을 가진 4개의 API 함수로 구성되어 있습니다.

GET 요청을 담당하는 함수는 다음과 같이 작성되었습니다.

export async function GET(url: string): Promise {
  try {
    const response = await axiosInstance.get(url);
    return response.data;
  } catch (error) {
    throw new Error(error instanceof Error ? error.message : String(error));
  }
}

POST 요청을 담당하는 함수는 다음과 같이 작성되었습니다.

export async function POST(url: string, data?: U): Promise {
  try {
    const response = await axiosInstance.post(url, data);
    return response.data;
  } catch (error) {
    throw new Error(error instanceof Error ? error.message : String(error));
  }
}

각 메서드는 네트워크 요청, 응답 데이터 반환, 에러 처리 등 거의 동일한 흐름을 갖고 있었으며 이로 인해 같은 패턴의 코드가 여러 파일에 중복되어 유지보수가 어렵고 에러 처리 기준을 일관되게 적용하기 힘들었습니다.

두 번째로 에러 처리 방식이 너무 단순해서 개선할 필요성을 느꼈습니다.

기존에는 에러의 상태나 종류를 구분하지 않고 발생한 에러를 그대로 다시 던지는 방식이었습니다.

그렇게 되면 GET요청처럼 useQuery를 사용하는 경우 UI 상에서 에러 메시지를 처리하거나 사용자에게 알리는 로직이 빠져있었습니다. 특히 Tanstack Query v5 에서는 에러 처리를 QueryClient의 공통 설정으로 이동하는 방식이 권장되기 때문에 기존 구조로는 사용자에게 적절한 피드백이 어려웠습니다.

이러한 두 가지의 문제를 해결하기 위해 개선하였습니다.

개선 과정

API 함수 통합

중복을 제거하고 일관된 에러 처리와 확장 가능한 구조를 만들기 위해 모든 HTTP 요청을 처리할 수 있는 공통 request함수로 통합하였습니다.

async function request({
  method,
  url,
  data,
  token,
}: RequestOptionsProps): Promise {
  try {
    if (token) {
      setAuthToken(token);
    }

    const response = await axiosInstance.request({
      method,
      url,
      data,
    });

    return response.data;
  } catch (error) {
    handleHttpError(error);
    throw error;
  }
}

여기서 token은 GET 요청을 서버사이드에서 사용할 때 필요하기 때문에 포함시켰습니다.

위에서 구현한 request를 간편하게 사용하기 위해서 역할별로 객체로 나누어 정의했습니다.

export const API = {
  get: (url: string, token?: string) =>
    request({ method: 'GET', url, token }),
  post: (url: string, data?: U) =>
    request({ method: 'POST', url, data }),
  put: (url: string, data: U) => request({ method: 'PUT', url, data }),
  delete: (url: string) => request({ method: 'DELETE', url }),
};

이로서 기존에 사용하던 API 함수들과 사용방식은 거의 동일하지만 내부적으로는 공통 request함수로 로직이 통합되어 있어 유지보수성과 재사용성이 크게 향상되었습니다.

공통 에러 처리 함수

handleHttpError라는 함수를 만들어 에러가 발생했을 때 공통적으로 에러를 처리할 수 있도록 했습니다.

import { AxiosError } from 'axios';

import { notify } from '@/store/useToastStore';

export function handleHttpError(error: unknown) {
  if (!(error instanceof AxiosError)) {
    notify('error', '에러가 발생했습니다.', 3000);
    return;
  }

  const status = error.response?.status;
  const message = error.response?.data?.message || '';

  switch (status) {
    case 401:
      notify('info', '로그아웃 되었습니다.', 3000);
      break;
    case 500:
      notify('error', '서버에서 오류가 발생하였습니다.', 3000);
      break;
    default:
      notify('error', message, 3000);
      break;
  }
}

handleHttpError 함수는 에러가 AxsosError 인스턴스인지 확인한 뒤, HTTP 상태 코드에 따라 적절한 사용자 메시지를 표시합니다.

예를 들어 401에러는 인증 만료로 간주해 로그아웃 안내 메시지를 보여주고 500에러는 서버 오류 메시지를 표시합니다. 그 외의 에러는 서버에서 내려준 메시지를 그대로 사용자에게 전달합니다.

QueryClient 공통 에러 처리

useQuery 에서 발생한 에러를 처리하기 위해서 QueryClient 객체에서 공통적인 에러 처리를 할 수 있도록 queryCache 부분에 onError를 추가하였습니다.

function makeQueryClient() {
  return new QueryClient({
    defaultOptions: {
      queries: {
        staleTime: DEFAULT_STALE_TIME,
        refetchOnWindowFocus: false,
        refetchOnReconnect: false,
        retry: 0,
      },
      dehydrate: {
        shouldDehydrateQuery: (query) =>
          defaultShouldDehydrateQuery(query) ||
          query.state.status === 'pending',
      },
    },
    queryCache: new QueryCache({
      onError: (error: unknown) => {
        handleHttpError(error);
      },
    }),
  });
}

이렇게 구현하여 잘 통합했다고 생각했지만 예상치 못한 문제가 발생해 추가 수정이 필요했습니다.

에러 처리 중복 문제 발생

문제 정의

현재 공통 API에서는 handleHttpError를 통해 에러를 처리하고 있지만, GET 요청의 경우 QueryClient에서 설정한 공통 에러 핸들러(onError)가 한 번 더 실행되면서 에러 처리가 중복되는 문제가 발생했습니다.

또한 useMutation을 사용하는 요청에서는 각 onError 설정에 따라 또 한 번 에러 처리가 이루어지게 되어, 동일한 에러에 대해 여러 번 토스트 메시지가 표시되는 현상이 나타났습니다.

결국은 동일한 에러에 대해 request 내부와 Tanstack Query의 에러 핸들러가 각각 토스트 메시지를 표시하면서 사용자에게 동일한 에러 메시지가 중복 노출되는 문제가 발생했습니다.

해결 방안

따라서 공통 API 내에서의 에러 처리는 에러를 파싱하는 역할만 하도록 수정했습니다.

  } catch (error) {
    if (!(error instanceof AxiosError)) {
      throw new Error('오류가 발생했습니다.');
    }

    const status = error.response?.status;
    const message = error.response?.data.message || error.message;

    throw new Error(JSON.stringify({ status, message }));
  }

이렇게 수정하면 useQuery 부분은 QueryClient 에서 설정한 공통된 에러 처리로 토스트 메시지를 보여주고 useMutation 부분은 각자의 onError 에서 파싱된 에러 객체를 받아 설정한 토스트 메시지를 보여주게 됩니다.

느낀점

이번 경험을 통해 에러 처리와 공통 로직 수정에 대해서 부분적으로만 이해하고 있었다는 것을 알게되었습니다. 실제로 공통화한다고 해서 끝나는 게 아니라 상황에 따라 어떻게 처리할지도 함께 고민해야 한다는 걸 배웠고 기능 분리나 재사용성 외에도 흐름 제어와 사용자 경험까지 고려한 설계가 필요하다는 걸 체감했습니다.

이번에 적용한 개선 방향이 정말 올바른 방향인지는 잘 모르겠습니다. 실제 서비스 상황에서의 다양한 예외 케이스를 더 많이 경험해봐야 진짜로 견고한 구조라고 말할 수 있을 것 같습니다.

또한 ErrorBoundary를 실제 프로젝트에 적용해본 경험이 없어, 다음 프로젝트에서는 컴포넌트 단위의 예외 상황도 포괄적으로 처리할 수 있도록 도입해볼 것입니다.

앞으로는 사용자 경험을 해치지 않으면서도 예외 상황을 안정적으로 처리할 수 있는 구조와, 도메인의 특성을 고려한 에러 메시지 설계까지 함께 고민해야될 것 같습니다.

Tanstack Query와 SSR을 활용한 대시보드 페이지 리팩토링

Sat, 08 Mar 2025 09:17:31 GMT

이전에 만들었던 공통 API 함수를 리펙토링 하였다.

대시보드 페이지

현재 대시보드 페이지는 이렇게 생겼다.

대시보드는 4개의 주요 컴포넌트로 이루어져 있고, 각각의 컴포넌트가 별도의 API 요청을 수행하여 데이터를 가져오도록 되어 있다.

export default function DashBoardPage() {
  return (
    <>
      
      
        
        
        
        
      
    
  );
}

현재 문제점

기존에는 isLoading을 활용하여 데이터를 불러오는 동안 로딩 UI (스켈레톤 UI)를 보여주고 있다. 하지만 이 방식에는 두가지 문제가 있다.

1. 클라이언트에서만 로딩 상태를 관리해야 한다.

서버에서 렌더링된 화면에는 데이터가 포함되지 않기 때문에, 브라우저가 API 요청을 보내 데이터를 가져올 때까지 빈 화면이 표시된다.

2. 코드의 가독성이 저해된다는 점이다.

isLoading이 컴포넌트 내부 곳곳에서 사용되고 있어, 코드가 한눈에 이해되지 않을 수 있다.

이를 해결하기 위해 useSuspenseQuery를 활용한다면 SSR에서 데이터를 미리 패칭하여 첫 화면부터 데이터를 포함할 수 있고, 코드도 더 간결해진다.

최근 등록한 할일 부분 적용

이 중에서 최근 등록한 할일을 담당하는 RecentTodos 컴포넌트는 다음과 같이 구현되어 있다.

'use client';

// ...

export const RecentTodos = () => {
  const { todos, isLoading } = useRecentTodosQuery();
  const { goals } = useGoalsQuery();

  const hasTodos = todos.length > 0;
  const hasGoals = goals.length > 0;

  return (
    
      {isLoading && }

      {!isLoading && !hasGoals && (
        // ...
      )}

      {!isLoading && hasGoals && !hasTodos && (
        // ...
      )}

      {!isLoading && hasGoals && hasTodos && (
        // ...
      )}
    
  );
};

다른 컴포넌트에서도 같은 방식으로 로딩 상태를 관리하고 있어, isLoading을 사용하지 않고 Suspense를 활용하는 방식으로 리팩토링하려고 한다.

먼저, 최근 등록한 할일을 불러오는 useRecentTodosQuery는 useQuery를 사용해 API 요청을 보낸다.

// ...

export const recentTodosOptions = (): UseQueryOptions<
  RecentTodosResponse,
  AxiosError
> => ({
  queryKey: [QUERY_KEYS.RECENT_TODOS],
  queryFn: () =>
    GET(
      `${API_ENDPOINTS.TODOS.GET_ALL}?lastTodoId=0&size=3`,
    ),
});

export const useRecentTodosQuery = () => {
  const { data, ...etc } = useQuery(recentTodosOptions());
  const todos = data?.data.content ?? [];

  return { todos, ...etc };
};

여기 useQuery를 useSuspenseQuery로만 변경하기만 하면 된다.

하지만 에러가 발생했다.

Uncaught Error: Switched to client rendering because the server rendering errored: document is not defined

이 에러는 서버 렌더링 중에서 document 객체를 참조면서, 강제로 클라이언트 렌더링으로 변경되었다는 의미이다.

그 원인은 useSuspenseQuery로 변경하면서 브라우저에서만 접근 가능한 document.cookie를 SSR에서도 호출하려고 했기 때문이다.

현재 프로젝트에서는 axiosInstance를 커스텀하여 사용하고 있었고, 토큰 값을 헤더에 주입하기 위해서 브라우저의 쿠키에서 값을 가져오고 있었다. 이 작업에서 document.cookie를 사용했기 때문에 SSR 환경에서는 오류가 발생한 것이다.

이를 해결하기 위해, 서버에서는 document 객체를 참조할 수 없도록 클라이언트 환경에서만 토큰을 주입할 수 있도록 수정했다.

axiosInstance.interceptors.request.use(
  (config) => {
    if (typeof window !== 'undefined') {
        // 쿠키 설정 코드
    }

    return config;
  },
  (error) => {
    return Promise.reject(error);
  },
);

그렇지만 이렇게 해도 여전히 같은 에러가 발생했다.

이제 Tanstack Query의 Hydration API를 활용해서 SSR에서 데이터를 미리 패칭하는 방식을 적용해보려고 한다.

Hydration API 적용

먼저 이 블로그를 참고해 ServerFetchBoundary라는 컴포넌트를 만들었다.

https://velog.io/@sik02/Next.js에서-react-query를-왜-써

SSR은 적용했지만, 새로고침 했을 때 기대했던 결과가 나오지 않았다. 클라이언트에서 요청했을 때와 동일하게 로딩 UI가 나타나고 SSR이 적용되었음에도 UI가 거의 같은 속도로 렌더링되었다..

이유를 찾아보니, RecentTodos 컴포넌트에 목표(goals)를 받아오는 쿼리도 있었고 이 부분은 여전히 useQuery를 사용하고 있었다. useSuspenseQuery로 변경한 후에 적용이 되었다.

로딩의 결과는 이렇게 나타난다.

변경 전

변경 후

내 진행 상황 부분 적용

MyProgress 컴포넌트에도 SSR을 적용했다.

하지만 이 컴포넌트는 애니메이션이 포함되어 있었다. 애니메이션이 useEffect에서 실행되기 때문에 SSR에서는 애니메이션이 동작하지 않았고, 클라이언트 렌더링과 차이가 없었다.

다시 클라이언트 렌더링 방식으로 되돌렸다.

팔로워 현황, 목표 별 할 일 부분 적용

이 두 컴포넌트는 무한 스크롤을 위한 useInfiniteQuery가 적용되어 있다.

useSuspenseInfiniteQuery로 변경하고 위에서 했던 작업과 비슷하게 적용해보았지만, 에러가 발생하였다.

TypeError: Cannot read properties of undefined (reading 'length')

// ...

export const todosOfGoalsOptions = (
  token?: string,
): UseSuspenseInfiniteQueryOptions<
  TodosOfGoalsResponse,
  AxiosError,
  BaseInfiniteQueryResponse
> => ({
  queryKey: [QUERY_KEYS.TODOS_OF_GOALS],
  queryFn: ({ pageParam = 0 }) =>
    GET(
      `${API_ENDPOINTS.TODOS.GET_GOALS}?lastGoalId=${pageParam}&size=5`,
      token,
    ),
  getNextPageParam: (lastPage) => {
    const nextCursor = lastPage.data.nextCursor;
    return nextCursor !== 0 ? nextCursor : undefined;
  },
  initialPageParam: 0,
});

export const useTodosOfGoalsQuery = () => {
  const { data, ...etc } = useSuspenseInfiniteQuery(todosOfGoalsOptions());
  const goals = data?.pages.flatMap((page) => page.data.content) ?? [];

  return { goals, ...etc };
};

에러가 getNextPageParam에서 발생했다. 처음에는 서버에서 받아온 데이터의 타입과 getNextPageParam이 요구하는 타입이 다르다고 생각해, 받아온 데이터의 형태를 수정하고 다시 해보았지만 해결되지 않았다.

그래서 getNextPageParam의 타입을 확인해보았다.

// getNextPageParam
interface InfiniteQueryPageParamsOptions extends InitialPageParam {
    /**
     * This function can be set to automatically get the previous cursor for infinite queries.
     * The result will also be used to determine the value of `hasPreviousPage`.
     */
    getPreviousPageParam?: GetPreviousPageParamFunction;
    /**
     * This function can be set to automatically get the next cursor for infinite queries.
     * The result will also be used to determine the value of `hasNextPage`.
     */
    getNextPageParam: GetNextPageParamFunction;
}

// GetNextPAgeParamFuction
type GetNextPageParamFunction = (lastPage: TQueryFnData, allPages: Array, lastPageParam: TPageParam, allPageParams: Array) => TPageParam | undefined | null;

하지만, 내가 발생한 에러와 공식 타입의 정의가 달라, 문제 해결이 쉽지 않았다. 결국은 클라이언트 렌더링 방식을 유지하기로 했다. 이후에 더 깊이 공부한 후에 다시 적용해볼 예정이다.

결론

대시보드 페이지에서 최근 등록한 할일 부분만 서버사이드 렌더링(SSR)을 적용하고, 나머지 부분은 클라이언트 렌더링(CSR)을 유지했다.

SSR과 SCR의 차이점인 초기 로딩 속도에서 큰 차이를 체감할 수 있었다. 각 기술의 장단점을 비교하며 프로젝트에 어떻게 적용할지에 대한 인사이트를 얻을 수 있었다.

로딩 속도를 개선한 경험은 사용자 경험의 중요성을 다시 한번 깨닫게 해주었고 문제 해결 과정에서 Tanstack Query와 SSR에 대해 더 깊이 이해할 수 있었다.

아직 해결하지 못한 에러를 수정하기 위해 더 많은 학습이 필요하다는 것을 느꼈고 문제를 해결하는 능력을 키우기 위해 지속적으로 공부해야겠다.

코드 중복 제거를 위한 공통 API 함수 설계와 활용

Wed, 22 Jan 2025 06:59:22 GMT

현재 프로젝트에서 api를 모두 Axios와 Tanstack Query를 활용해서 호출하고 있다.

과정

예를 들어 목표를 호출하는 함수를 만드려면 새로운 파일을 만들고 axiosInstance를 활용해 api를 호출하는 로직을 작성하고 있다.

apis 폴더 안에 API 호출 로직을 작성한다.

/apis/Goals/getGoals.tsx

export const getGoals = async () => {
  try {
    const response = await axiosInstance.get(API_ENDPOINTS.GOAL.GOALS);
    return response.data;
  } catch (error) {
    console.error("목표 불러오기 에러",error)
    throw error
  }
}

이후 /hooks/apis/goals/useGoalsQuery.tsx파일에서 useQuery를 사용해 API 호출을 처리하는 커스텀 훅을 만든다.

const goalsOptions: UseQueryOptions = {
  queryKey: [QUERY_KEYS.GOALS],
  queryFn: () => getGoals(),
};

export const useGoalsQuery = () => {
  const { data, ...etc } = useQuery(goalsOptions);
  const goals = data?.data ?? [];

  return { goals, ...etc };
};

현재 방식은 API 호출과 관련된 파일 구조가 복잡해지고 하나의 파일안에서 작성하기엔 가독성이 좋지 않아서 방법을 고민해보았다.

개선 방안

API 통신에서 사용되는 GET, POST, PUT, DELETE를 각각 함수로 만들어 재사용 가능하도록 만들었다.

각각의 응답 및 반환 타입을 제네릭 타입으로 설정하였고 공통된 에러처리 로직을 추가해 코드 중복을 줄이고 가독성을 높였다.

/apis/service/httpMethid.ts

import axiosInstance from '@/lib/axiosInstance';

export async function GET(url: string): Promise {
  try {
    const response = await axiosInstance.get(url);
    return response.data;
  } catch (error) {
    throw new Error(error instanceof Error ? error.message : String(error));
  }
}

export async function POST(url: string, data?: U): Promise {
  try {
    const response = await axiosInstance.post(url, data);
    return response.data;
  } catch (error) {
    throw new Error(error instanceof Error ? error.message : String(error));
  }
}

export async function PUT(url: string, data: U): Promise {
  try {
    const response = await axiosInstance.put(url, data);
    return response.data;
  } catch (error) {
    throw new Error(error instanceof Error ? error.message : String(error));
  }
}

export async function DELETE(url: string): Promise {
  try {
    const response = await axiosInstance.delete(url);
    return response.data;
  } catch (error) {
    throw new Error(error instanceof Error ? error.message : String(error));
  }
}

기존에는 동일한 로직을 여러 파일에서 반복적으로 작성해야 했던 문제를 개선하고 공통 함수로 중복 코드를 줄일 수 있었다.

/hooks/apis/goals/useGoalsQuery.tsx

const goalsOptions: UseQueryOptions = {
  queryKey: [QUERY_KEYS.GOALS],
  queryFn: () => GET(API_ENDPOINTS.GOAL.GOALS),
};

export const useGoalsQuery = () => {
  const { data, ...etc } = useQuery(goalsOptions);
  const goals = data?.data ?? [];

  return { goals, ...etc };
};

한계점

서버 사이드 렌더링(SSR)에서 API 호출이 불가능하다.

현재 구조에서는 커스텀된 axiosInstance를 사용해 요청을 보낼 때 브라우저 환경에서만 접근할 수 있는 쿠키를 활용해 토큰을 주입하고 있다. SEO가 중요한 페이지일 경우엔 서버 사이드로 데이터 패칭을 통해서 불러와야할 경우엔 새로운 인스턴스를 만들어서 사용해야하는 한계점이 있다.

결론

기존 방식은 API 호출 로직과 Tanstack Query hook을 각각 작성해야 했기 때문에 불필요한 중복 코드가 발생했다.

공통 HTTP 메서드 함수를 사용하게 되면서 API 호출 로직의 중복을 제거하고 각 도메인별로 간단하게 hook을 작성할 수 있게되었다.

결과적으로 코드의 양을 줄이고 새로운 API를 추가하는 데 필요한 시간을 단축시킬 수 있었다.

Tanstack Query 무한 스크롤

Tue, 31 Dec 2024 08:37:06 GMT

무한 스크롤이란?

콘텐츠를 한 번에 로드하지 않고, 사용자가 페이지를 아래로 스크롤할 때 필요한 만큼만 추가로 로드하는 방식

특징

스크롤 동작만으로 콘텐츠가 자동으로 로드
추가적인 조작 없이 콘텐츠 탐색 가능
데이터 로드 타이밍과 로딩 상태 표시가 중요

장점

사용자 경험 향상: 스크롤만으로 새로운 콘텐츠를 볼 수 있어 간편함
탐색 시간 단축: 여러 페이지를 오가며 데이터를 확인할 필요가 없음
모바일 친화적: 작은 화면에서 페이지 버튼 대신 자연스러운 탐색 가능

적용

목표 상세 데이터 불러오기 코드

const GoalsDetailOptions = (): UseInfiniteQueryOptions<
  GoalsDetailResponse,
  AxiosError,
  BaseInfiniteQueryResponse
> => ({
  queryKey: [QUERY_KEYS.ALL_GOALS],
  queryFn: ({ pageParam = 0 }) =>
    GET(
      `${API_ENDPOINTS.GOAL.ALL_GOALS}?lastGoalId=${pageParam}&size=5`,
    ),
  getNextPageParam: (lastPage) => {
    const nextCursor = lastPage.data.nextCursor;
    return nextCursor !== 0 ? nextCursor : undefined;
  },
  initialPageParam: 0,
});

export const useGoalsDetailQuery = () => {
  const { data, ...etc } = useInfiniteQuery(GoalsDetailOptions());
  const goals = data?.pages.flatMap((page) => page.data.content) ?? [];

  return { goals, ...etc };
};

queryFn

lastGoalId값을 포함해 5개의 데이터를 불러온다. size 값에 따라 몇 개의 목표를 가져올 것인지 설정한다.

getNextPageParam

마지막 데이터의 nextCursor 값을 가지고 pageParam 값을 설정해준다. nextCurosr의 값이 null이면 pageParam을 undefined로 설정하여 추가 요청을 불러오지 않는다.

initialPageParam

초기 pageParam값을 설정한다.

공통 무한 스크롤 custom hook

import { useEffect, useRef } from 'react';

interface InfiniteScrollProps {
  fetchNextPage: () => void;
  isLoading: boolean;
}

export const useInfiniteScroll = ({
  fetchNextPage,
  isLoading,
}: InfiniteScrollProps) => {
  const observerRef = useRef(null);

  useEffect(() => {
    if (!observerRef.current) return;

    const observerCallback: IntersectionObserverCallback = (entries) => {
      const lastEntry = entries[0];
      if (lastEntry.isIntersecting && !isLoading) {
        fetchNextPage();
      }
    };

    const observer = new IntersectionObserver(observerCallback, {
      threshold: 1.0,
    });

    if (observerRef.current) {
      observer.observe(observerRef.current);
    }

    observer.observe(observerRef.current);

    return () => observer.disconnect();
  }, [fetchNextPage, isLoading]);

  return {
    observerRef,
  };
};

Intersection Observer를 사용해 무한 스크롤을 구현하였다.

observerCallBack을 통해 마지막 요소가 뷰포트에 들어왔는지 감지
isintersecting 값이 true이고, 데이터 로드 중이 아니라면 fetchNextPage를 호출

참고

올리브영 테크블로그 https://oliveyoung.tech/2023-10-04/useInfiniteQuery-scroll/ 무한 스크롤 장단점 https://brunch.co.kr/@joohyup1001/50

스켈레톤 로딩 지연

Tue, 24 Dec 2024 08:26:46 GMT

스켈레톤 로딩이란?

빈 화면 대신, 어떤 형식으로 콘텐츠가 자리잡을지 구조적으로 미리 보여주는 로딩이다. 사용자에게 로딩을 납득할 수 있는 충분한 정보를 제공한다.

장점

체감 로딩 시간이 짧다.

스피너 로딩과의 차이점

대부분의 스피너 로딩은 짧은 로딩 시간에 사용한다.
동적인 요소로 사용자가 지루함을 느끼지 않게 한다.
체감 로딩 시간이 길다.

Progress Indicator

UX 리서치 그룹 닐슨 노먼의 지침 https://www.nngroup.com/articles/progress-indicators/

주요지침

약 1초 이상 걸리는 작업에는 Progress indicator를 사용 Loop Animation은 빠른 동작에만 사용 Percent-done Animation은 10초 이상 걸리는 작업에 사용 Static Indicator는 사용 X

이 글에서 진행 상태 표시기의 유형은 두 가지로 나누어진다.

불확정적 로딩(Indeterminate Loading)

진행 시간이 예측 불가능할 때 사용.
보통 회전하는 스피너(spinner) 형태.
사용자가 작업이 진행 중이라는 사실만 알 수 있음.
하지만 정확한 완료 예상 시간을 제공하지 않으므로 답답함을 유발할 수도 있음.

확정적 로딩(Determinate Loading)

예상 완료 시간을 제공할 수 있을 때 사용.
보통 프로그래스 바(progress bar) 형태.
완료 예상 시간을 보여줘 사용자의 기대 관리를 돕고, 신뢰감을 형성.

그중에서 스켈레톤 로딩은 불확정적 로딩에 들어간다. 왜냐하면 "현재 데이터를 불러오는 중"이라는 시각적 힌트를 제공하지만, 정확한 진행률을 보여주지는 않기 때문이다.

UX 최적화를 위해 스켈레톤 로딩을 적용하는 방법

실제 콘텐츠와 유사한 형태로 디자인할 것
너무 오래 표시되지 않도록 할 것
중요한 정보는 먼저 로딩할 것
부드러운 페이드 인 효과 적용

결론적으로 스켈레톤 로딩을 적용하게 되면 사용자가 콘텐츠의 구조를 빠르게 파악할 수 있고, 스피너보다 기다리는 시간을 짧게 느끼게 할 수 있다.

카카오페이의 스켈레톤 지연 시간

카카오페이의 어떤 서비스의 네트워크 요청 응답 시간 지표에서 평균적으로 110ms의 지연 이후 API 응답을 받고 있고, 75%의 사용자들은 192ms 이내에 응답을 받고 있다.

그렇기 때문에 200ms 정도를 지연시켜 사용자에게 노출한다면 약 75%의 사용자는 덜그럭 거리지 스켈레톤을 보여주지 않을 수 있다. 그렇지만 덜그럭거림을 느끼지 못하던 15%의 사용자는 덜그럭거리는 스켈레톤 뷰를 보게 된다는 단점이 있다.

그럼에도 카카오페이에서는 스켈레톤을 200ms를 지연시켜 사용자 경험을 향상시켰다.

내 프로젝트에 적용

위의 글을 바탕으로 사용자의 프로필을 불러오는 로딩에 조건부 스켈레톤 로딩을 적용시켰다. 네트워크 텝에서 No throttling일 경우 평균적으로 86ms,Fast 4G 일 경우 186ms정도가 나오기 때문에 로딩 지연을 200ms로 지정해두었다.

현재 Suspense가 적용되지 않는 문제가 발생해 useQuery의 isLoading을 사용해 적용시켰다. 추후에 이 문제가 해결되면 Suspense 컴포넌트로 변경할 예정이다.

export const Profile = () => {
  const { email, name, profile, isLoading } = useUserQuery();
  const [showSkeleton, setShowSkeleton] = useState(false);

  useEffect(() => {
    if (isLoading) {
      const timer = setTimeout(() => setShowSkeleton(true), 200);
      return () => clearTimeout(timer);
    }

    setShowSkeleton(false);
  }, [isLoading]);

  return (
    
      {showSkeleton ? (
        <>
          
          
            
            
          
        
      ) : (
        <>
          {!isLoading && (
            
          )}
          
            
              {name}
              {email}
            
            
          
        
      )}
    
  );
};

useEffect 내부에서 setTimeout을 사용해 스켈레톤 로딩을 200ms 지연시켜서 스켈레톤 로딩을 적용시켰다.

No throttling

Fast 4G

결론

스켈레톤 로딩은 사용자가 콘텐츠의 구조를 미리 파악할 수 있도록 도와주고, 스피너보다 체감 대기 시간을 줄여 UX를 향상시키는 효과적인 방법이다.

그러나 모든 경우에 적합한 것은 아니며, 네트워크 응답 속도와 사용자 경험을 고려해 적절한 지연 시간을 설정하는 것이 중요하다. 카카오페이처럼 로딩 지연을 적용하면 불필요한 스켈레톤 표시를 줄이면서도 원활한 사용자 경험을 제공할 수 있다.

결과적으로 스켈레톤 로딩을 적절하게 활용하면 UX를 개선할 수 있지만, 적용 방식과 시점을 신중하게 고려해야 한다.

참고

헤이딜러 UX 스터디

카카오페이 기술 블로그

스켈레톤 로딩

Tanstack Query 낙관적 업데이트

Tue, 24 Dec 2024 05:58:42 GMT

낙관적 업데이트란?

사용자가 데이터 변경 작업을 수행했을 때, 실제 서버 응답을 기다리지 않고 UI를 즉시 업데이트 하는 방법이다.

사용자 경험 개선
애플리케이션이 더 빠르고 반응성이 좋아보이게 만듬

일반적인 흐름

사용자가 데이터를 변경하는 작업 수행
UI에서 변경된 결과를 즉시 반영
서버에 변경 요청을 전송
서버 응답이 성공인 경우, UI 유지
서버 응답이 실패인 경우, 이전 상태로 롤백하거나 에러처리

적용

기존 목표 불러오기 코드

export const useSidebarGoalsMutation = () => {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: postSidebarGoals,
    onSuccess: () => {
      queryClient.invalidateQueries({ queryKey: [QUERY_KEYS.SIDEBAR_GOALS] });
      queryClient.invalidateQueries({
        queryKey: [QUERY_KEYS.TODOS_OF_GOALS],
      });
    },
    onError: (error) => {
      console.error(error.message);
      notify('error', '목표 등록에 실패했습니다.', 3000);
    },
  });
};

기존 코드에 낙관적 업데이트를 적용하기 위해서 onMutate을 작성하고 onSuccess 대신 성공, 실패 여부에 관계 없이 실행하기 위해 onSettled를 작성 그에 맞는 onError 코드도 변경하였다.

낙관적 업데이트 적용한 코드


export const useSidebarGoalsMutation = () => {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: (postData: PostGoalTypes) =>
      POST(API_ENDPOINTS.GOAL.GOALS, postData),
    onMutate: async ({ title }) => {
      const prev = queryClient.getQueriesData({ queryKey: [QUERY_KEYS.GOALS] });

      await queryClient.cancelQueries({ queryKey: [QUERY_KEYS.GOALS] });
      queryClient.setQueryData([QUERY_KEYS.GOALS], (oldData: GoalsResponse) => {
        if (!oldData?.data) return oldData;

        return {
          ...oldData,
          data: [
            ...oldData.data,
            {
              goalId: Date.now(),
              goalTitle: title,
              color: '#848484',
              createAt: new Date().toISOString(),
            },
          ],
        };
      });

      return { prev };
    },
    onSettled: () => {
      queryClient.invalidateQueries({ queryKey: [QUERY_KEYS.GOALS] });
      queryClient.invalidateQueries({
        queryKey: [QUERY_KEYS.TODOS_OF_GOALS],
      });
    },
    onError: (error, newGoal, context) => {
      queryClient.setQueriesData(
        { queryKey: [QUERY_KEYS.GOALS] },
        context?.prev,
      );
      console.error(error.message);
      notify('error', `목표 등록에 실패했습니다.\n ${newGoal.title}`, 3000);
    },
  });
};

onMutate

서버에 요청을 보내기 전에 실행한다.

해당 쿼리의 기존 데이터를 prev 로 저장 cancelQueries로 목표 관련 쿼리를 중단해 기존 데이터와 서버 응답의 충돌을 방지 기존 값 (oldData) 에 새로운 데이터를 추가해 UI를 즉시 갱신 prev를 리턴해준다.

onSettled

서버 요청이 성공하거나 실패한 후에 실행한다.

onSettled로 관련된 쿼리 키들을 invalidate하여 최신 데이터를 가져오도록 함

onError

서버의 응답이 실패하면 실행한다.

onMutate에서 저장한 prev를 사용해 쿼리를 복구한다.

context는 onMutate에서 반환된 값이다.

에러 메시지를 통해 사용자에게 알린다.

결과

PR 주소: https://github.com/slid-todo/front/pull/116

Zustand 렌더링 최적화

Sun, 15 Dec 2024 08:29:08 GMT

Zustand 의 기본 사용법

zustand는 Store를 만들어 전역변수를 간편하게 사용할 수 있는 라이브러리이다.

zustand를 사용해서 Store에서 상태를 가져오는 방식이 2가지 있다.

const { value } = useStore();
const value = useStore((state) => state.value);

Selector function이란?

기본적으로 React 컴포넌트가 상태를 가져오면 상태 변화가 있을 때마다 해당 컴포넌트가 다시 렌더링 된다. 하지만 Zustand는 상태의 특정 부분만 선택적으로 가져올 수 있기 때문에 상태 변화가 특정 부분에서만 영향을 미치도록 제한할 수 있다.

기본적인 zustand 사용


export const Sidebar = () => {
  // ...
  const { toggleIsNew } = useNewGoalsStore(); // 전체 상태를 가져온다.

  // ...

    }
      label="목표"
      addButton={
        
          새 목표
        
      }
    />

  //...

불필요한 리렌더링 방지 zustand 사용

export const Sidebar = () => {
  // ...
  const handleToggle = useNewGoalsStore((state) => state.toggleIsNew); // 특정 상태만 가져온다.

  // ...

    }
      label="목표"
      addButton={
        
          새 목표
        
      }
    />

  // ...

참고

Zustand 공식문서 https://zustand-demo.pmnd.rs/

selector 관련 zustand 공식 github https://github.com/pmndrs/zustand#Recipes

Promise 병렬처리

Wed, 11 Dec 2024 03:24:43 GMT

Promise 란?

프로미스가 생성된 시점에는 알려지지 않았을 수도 있는 값을 위한 대리자로, 비동기 연산이 종료된 이후에 결과 값과 실패 사유를 처리하기 위한 처리기이다. 프로미스를 사용하면 비동기 메서드에서 동기 메서드처럼 값을 반환할 수 있다.

Promise의 상태

대기(pending): 이행하지도, 거부하지도 않은 초기 상태.
이행(fulfilled): 연산이 성공적으로 완료됨.
거부(rejected): 연산이 실패함.

Promise.all()

순회 가능한 객체에 주어진 모든 프로미스가 이행한 후, 혹은 프로미스가 주어지지 않았을 때 이행하는 Promise를 반환한다.

예시

순회 가능한 객체에 프로미스가 들어가도 되고 프로미스가 들어가도 된다.

const p = Promise.all([1, 2, 3]); // 모든 값이 즉시 이행됨
const p2 = Promise.all([1, 2, 3, Promise.resolve(444)]); // 444 포함, 모든 값이 이행됨
const p3 = Promise.all([1, 2, 3, Promise.reject(555)]); // 555로 거부됨

setTimeout(() => {
  console.log(p);  // fulfilled: [1, 2, 3]
  console.log(p2); // fulfilled: [1, 2, 3, 444]
  console.log(p3); // rejected: 555
});

거부

하나라도 거부하면 Promise.all()은 즉시 거부한다.

var p1 = new Promise((resolve, reject) => {
  setTimeout(() => resolve("하나"), 1000);
});
var p2 = new Promise((resolve, reject) => {
  setTimeout(() => resolve("둘"), 2000);
});
var p3 = new Promise((resolve, reject) => {
  reject(new Error("거부"));
});

Promise.all([p1, p2, p3, p4, p5])
  .then((values) => {
    console.log(values);
  })
  .catch((error) => {
    console.log(error.message);
  });

// "거부"

Promise.allSettled()

주어진 모든 프로미스를 이행하거나 거부한 후에 각 프로미스의 대한 결과를 나타내는 객체 배열을 반환한다.

Promise.all() 과의 차이

Promise.all()을 사용하면 하나라도 거부 당했을 때 즉시 거부되지만 Promise.allSettedl()는 각 프로미스의 실행 결과를 보존하고 모든 프로미스를 실행한다.

예시

각각의 프로미스 결과값을 보존한다.

const p1 = Promise.resolve(1)
const p2 = new Promise((resolve, reject) =>
  setTimeout(reject, 100, 'a'),
);

Promise.allSetted([p1, p2]).then((results) => {
    results.forEach((result) => console.log(result)
})
// "fulfilled"
// "rejected"

React.forwardRef

Tue, 03 Dec 2024 09:28:23 GMT

forwardRef 란

컴포넌트가 ref를 받아 하위 컴포넌트로 전달하도록하려면 forwardRef를 사용해야한다.

예시 코드

import { forwardRef } from 'react';

const MyInput = forwardRef(function MyInput(props, ref) {
  // ...
});

사용법 (Input)

ex) input에 focus할 때 사용하는 방법

Edit 버튼을 클릭하면 자동으로 input에 focus된다

import { useRef } from 'react';
import MyInput from './MyInput.js';

export default function Form() {
  const ref = useRef(null);

  function handleClick() {
    ref.current.focus();
  }

  return (
    
      
      
    
  );
}

주의점

ref를 과도하게 사용하지 마세요. 노드로 스크롤 하기, 노드에 포커스하기, 애니메이션 트리거하기, 텍스트 선택하기 등 prop로 표현할 수 없는 필수적인 동작에만 ref를 사용해야 합니다. prop로 무언가를 표현할 수 있다면 ref를 사용해서는 안 됩니다. 예를 들어 Modal 컴포넌트에서 { open, close }와 같은 명령형 핸들을 노출하는 대신 과 같이 prop isOpen을 사용하는 것이 더 좋습니다. Effects는 props를 통해 명령형 동작을 노출하는 데 도움이 될 수 있습니다. https://ko.react.dev/reference/react/forwardRef#usage

커스텀 Input

현재 Input 컴포넌트를 만들 때 forwardRef를 사용해서 ref를 받아올 수 있는 Input으로 만들었다.

import { forwardRef } from 'react';

import { cn } from '@/utils/className';

export type InputProps = React.InputHTMLAttributes;

export const Input = forwardRef(
  ({ className, type = 'text', ...props }, ref) => {
    const inputClass = cn(
      'w-full px-24 py-12 outline-none bg-white rounded-12 text-sm-normal md:text-base-normal',
      className,
    );

    return ;
  },
);

Input.displayName = 'Input';

이때 Input.displayName을 지정해야하는 이유는

eslint-plugin-react 에서 Component definition is missing display name 에러를 내준다.

이 컴포넌트의 이름이 있어야하는데 export로만 반환하면 이름이 지정되어있지 않아서 나타내는 에러이다.

해결 방법

export default로 반환
displayName으로 이름 지정

참고

React 공식문서 (한글) https://ko.react.dev/reference/react/forwardRef#usage

Component definition is missing display name 에러 https://github.com/jsx-eslint/eslint-plugin-react/blob/master/docs/rules/display-name.md

React.FC

Tue, 03 Dec 2024 08:16:15 GMT

FC란

Function Component 타입의 줄임말이다.

React.FC

interface FunctionComponent {
    (props: PropsWithChildren
, context?: any): ReactElement | null;
    propTypes?: WeakValidationMap
;
    contextTypes?: ValidationMap;
    defaultProps?: Partial
;
    displayName?: string;
}

type FC
 = FunctionComponent;

PropsWithChildren
를 사용하여 children props를 포함한다.
defaultProps, propTypes, displayName의 prop로 포함

장점

props의 타입을 간단하게 정의 가능하다.
defaultProps, propTypes, displayName 등의 정적 속성을 쉽게 사용 가능하다.

단점

children이 항상 포함된다.
컴포넌트의 타입 선언이 더 불명확해질 수 있다.

가장 큰 단점

React.FC를 사용할 경우 props에 자동으로 children이 옵셔널로 들어가있다.

→ 단점인 이유는 children의 명확하지 않은 타입 지정이기 때문이다.

→ 모든 컴포넌트를 React.FC로 선언했을 때 children이 필요하지 않은 컴포넌트에도 명시를 해놓지 않았기 때문에 children을 사용할 수 있는 문제가 발생한다.

컴포넌트 변경

현재 만들어둔 Chip 컴포넌트는 이렇게 구성되어 있다.

export const Chip: React.FC = ({
  className,
  variant = 'default',
  size = 'sm',
  children,
  ...props
}) => {
  const chipClass = cn(
    chipStyles.base,
    chipStyles.variant[variant],
    chipStyles.size[size],
    className,
  );

  return (
    
  );
};

이러한 방식으로 바꿔야 children에 대한 명확한 타입 지정이 가능하다.

export const Chip = ({
  className,
  variant = 'default',
  size = 'sm',
  children,
  ...props
}: ChipProps) => {
  const chipClass = cn(
    chipStyles.base,
    chipStyles.variant[variant],
    chipStyles.size[size],
    className,
  );

  return (
    
  );
};

참고

React.FC 정의 https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react/index.d.ts

Jest

Tue, 26 Nov 2024 08:58:58 GMT

Jest 란

Jest는 페이스북에서 만들어서 React와 더불어 많은 자바스크립트 개발자들로 부터 좋은 반응을 얻고 있는 테스팅 라이브러리다.

toBe vs toEqual

toBe는 참조값(주소값)을 비교하는 함수이다. toEqual은 값? 을 비교하는 함수이다.

객체를 비교할 때 객체는 각자의 메모리 주소를 가지고 있기 때문에 내용이 같더라도 참조값이 다르기 때문에 toBe는 다르다고 나온다.
toEqual은 실제 값을 비교하기 때문에 객체 내부의 값이 동일하다면 같다고 나온다.
- toStrictEqual: undefined를 허용하지 않는다.
number, boolean, string에는 참조값이 정해져 있어서 차이가 없다.
배열도 객체와 동일한듯?

describe('to be vs to equal', () => {
  test('test', () => {
    const a = [1];
    expect(a).toBe([1]); // false
  });

  test('test', () => {
    const a = [1];
    expect(a).toEqual([1]); // true
  });

  test('test', () => {
    expect([1]).toBe([1]); // false
  });
});

toBe 코드

  getJasmineRequireObj().toBe = function(j$) {
    /**
     * {@link expect} the actual value to be `===` to the expected value.
     * @function
     * @name matchers#toBe
     * @since 1.3.0
     * @param {Object} expected - The expected value to compare against.
     * @example
     * expect(thing).toBe(realThing);
     */
    function toBe(matchersUtil) {
      var tip = ' Tip: To check for deep equality, use .toEqual() instead of .toBe().';

      return {
        compare: function(actual, expected) {
          var result = {
            pass: actual === expected
          };

          if (typeof expected === 'object') {
            result.message = matchersUtil.buildFailureMessage('toBe', result.pass, actual, expected) + tip;
          }

          return result;
        }
      };
    }

    return toBe;
  };

toEqual 코드

  getJasmineRequireObj().toEqual = function(j$) {
    /**
     * {@link expect} the actual value to be equal to the expected, using deep equality comparison.
     * @function
     * @name matchers#toEqual
     * @since 1.3.0
     * @param {Object} expected - Expected value
     * @example
     * expect(bigObject).toEqual({"foo": ['bar', 'baz']});
     */
    function toEqual(matchersUtil) {
      return {
        compare: function(actual, expected) {
          var result = {
              pass: false
            },
            diffBuilder = j$.DiffBuilder({prettyPrinter: matchersUtil.pp});

          result.pass = matchersUtil.equals(actual, expected, diffBuilder);

          // TODO: only set error message if test fails
          result.message = diffBuilder.getMessage();

          return result;
        }
      };
    }

    return toEqual;
  };

Jest로 Promise 테스트

1. Promise 객체로 받는 경우

test('the data is peanut butter', () => {
  return fetchData().then(data => {
    expect(data).toBe('peanut butter');
  });
});

→ return을 해야하는 이유: return을 사용해야 jest는 promise가 resolve 될 때까지 기다리기 때문이다.

.resolves/.rejects 사용하면

test('the data is peanut butter', () => {
  return expect(fetchData()).resolves.toBe('peanut butter');
});

test('the fetch fails with an error', () => {
  return expect(fetchData()).rejects.toMatch('error');
});

반드시 return을 해야한다. → return이 없으면 data를 fetch 하고 콜백을 실행하기 전에 테스트가 완료됨

2. async/await

test('the data is peanut butter', async () => {
  const data = await fetchData();
  expect(data).toBe('peanut butter');
});

test('the fetch fails with an error', async () => {
  expect.assertions(1);
  try {
    await fetchData();
  } catch (error) {
    expect(error).toMatch('error');
  }
});

test('the data is peanut butter', async () => {
  await expect(fetchData()).resolves.toBe('peanut butter');
});

test('the fetch fails with an error', async () => {
  await expect(fetchData()).rejects.toMatch('error');
});

올바른 promise는 reloves로 풀고 toBe로 비교한다. 에러 promise는 rejects로 받고 toMatch로 비교한다. → toMatch는 정규식 비교 → toBe로 비교하면 안되나? → toThrow 쓸듯

toThrow 예시 코드

test("Test description", () => {
  const t = () => {
    throw new TypeError("UNKNOWN ERROR");
  };
  // 타입에러 객체 확인
  expect(t).toThrow(TypeError);
  // 에러 메시지 확인
  expect(t).toThrow("UNKNOWN ERROR");
});

// toThrow 사용
test("test", () => {
    expect(() => {
        throw new Error("ERROR")
    }).toThrow("ERROR")
})

Mock function

jest.jn()

mockReturnValue(value)

const mockFn = jest.fn()

mockFn() // undefined
mockFn(1) // undefined

mockFn.mockReturnValue(1)
mockFn() // 1

mockFn.mockReturnValue('a')
mockFn() // a

mockInplemetation(value)

모킹 함수를 구현 (동작이 가능한)

const mockFn = jest.fn();

mockFn.mockImplementation((name) => `hi ${name}`);
console.log(mockFn('a')); // hi a

const mockFn = jest.fn((name) => `hi ${name}`) // 가능

mockResolvedValue(value) / mockRejectedValue(value)

비동기 상황에서 resolve / reject 값을 받는다

test('resolve test', async () => {
  const mockFn = jest.fn().mockResolvedValue(1);

  expect(await mockFn()).toEqual(1);
});

test('reject test', async () => {
  const mockFn = jest.fn().mockRejectedValue(new Error('error'));

  expect(mockFn()).rejects.toThrow('error');
});

toBeCalled랑 toHaveBeenCalled랑 똑같음 toHaveBeenCalled: mock 함수가 호출 되었는지 확인 toHaveBeenCalledTimes: 함수가 몇번 호출 되었는지 확인 toHqveBeenCalledWith: 함수가 특정 인자(props)를 포함해서 호출이 되었는지 확인

jest.mock

jest.fn()과 비슷하지만 그룹을 한꺼번에 모킹 처리할 때 사용한다.

Spy function

jest.spyOn

헤당 함수의 호출 여부와 어떻게 호출 되었는지 확인한다.

  test('spyOn test', () => {
    const calculator = {
      add: (a, b) => a + b,
    };

    const spyFn = jest.spyOn(calculator, 'add');

    const result = calculator.add(1, 2);

    expect(spyFn).toHaveBeenCalled();
    expect(spyFn).toHaveBeenCalledTimes(1);
    expect(spyFn).toHaveBeenCalledWith(1, 2);
    expect(result).toBe(3);
  });

추가로 학습해야될 부분

Promise https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Promise Javascript 동작 원리 https://velog.io/@rnjsrntkd95/Call-Stack-Event-loop-Task-Queue

참고

toBe, toEqual https://stackoverflow.com/questions/22413009/jasmine-javascript-testing-tobe-vs-toequal jest promise https://jestjs.io/docs/asynchronous#asyncawait jest mock https://inpa.tistory.com/entry/JEST-📚-모킹-mocking-jestfn-jestspyOn

단위 테스트

Tue, 26 Nov 2024 08:46:20 GMT

단위 테스트란

컴퓨터 프로그래밍에서 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 절차 모든 함수와 메소드에 대한 테스트 케이스(Test case)를 작성하는 절차

효과적인 단위 테스트 코드 작성법

F.I.R.S.T 원칙

Fast: 단위 테스트는 빨라야 한다. Isolated: 단위 테스트는 실행할 때마다 같은 결과를 만들어야 한다. Self-validation: 단위 테스트는 스스로 테스트를 통과했는지 아닌지 판단할 수 있어야 한다. Timely: 단위 테스트는 프로덕션 코드가 테스트에 성공하기 전에 구현되어야 한다 (TDD) Thorough: 단위 테스트는 성공적인 흐름뿐만 아니라 가능한 모든 에러나 비정상적인 흐름에 대응해 야 한다.

Given-When-Then

Given: 테스트를 하기 위해 세팅하는 주어진 환경
When: 테스트를 하기 위한 조건
Then: 예상결과를 나타내며 의도대로 동작하는지 검증 및 확인

  it('should clear the value and onClear is triggered', async () => {
    // Given
    const mockFn = jest.fn();
    render();

    // When
    const clearBtn = screen.getByRole('button');
    fireEvent.click(clearBtn);

    // Then
    const input = screen.getByLabelText('my input');
    expect(input.value).toBe('');
    expect(mockFn).toHaveBeenCalledTimes(1);
  });

테스트 케이스의 목적을 명확히

테스트의 목적: 버튼을 눌렀을 때 좋아하는 과일이 바나나로 바뀐 문구가 노출되는지 검증

// 첫 번째 테스트 코드
it('바나나 문자열로 updateWord 호출 시 word가 바나나로 변경된다', () => {
  const { result } = renderHook(() => useStore());

  act(() => {
    result.current.updateWord('바나나');
  });

  expect(result.current.word).toBe('바나나');
});

내부적으로 가지는 단어라는 상태가 올바르게 변경되는지 테스트 (내부에서 사용하는 zustand 라이브러리 동작 검증)

// 두 번째 테스트 코드
it('버튼 클릭 시 좋아하는 과일이 바나나로 바뀐다', async () => {
  const user = userEvent.setup();
  render();

  await user.click(screen.getByRole('button', { name: '좋아하는 과일 바꾸기' }));

  expect(screen.getByText(/바나나/i)).toBeInTheDocument();
});

화면 내에 ‘바나나’라는 단어가 있는지 테스트

// 세 번째 테스트 코드
it('버튼 클릭 시 heading 영역의 문구가 바나나를 좋아한다는 내용으로 변경된다', async () => {
  const user = userEvent.setup();
  render();

  await user.click(screen.getByRole('button', { name: '좋아하는 과일 바꾸기' }));

  expect(screen.getByRole('heading', { name: '나는 바나나를 좋아한다!' })).toBeInTheDocument();
});

버튼을 눌렀을 때 heading 영역의 문구가 바나나를 좋아한다는 내용으로 변경됨을 테스트

참고

배민 기술블로그 (단위 테스트) https://techblog.woowahan.com/17404/