728x90 반응형 source-code/FrontEnd48 지속 가능한 프론트엔드 단위 테스트 작성법 1. 프론트엔드는 테스트가 필요 없다?!프론트엔드 단위 테스트는 항상 논쟁의 중심에 있습니다. 프론트엔드 애플리케이션의 복잡성과 중요성이 증가하면서 단위 테스트의 필요성을 주장하는 목소리가 점점 늘어나고 있습니다. 하지만 자주 변경되는 UI와 그로 인해 쉽게 깨져버리는 테스트 코드들을 보며 프론트엔드에서의 단위 테스트가 불필요하고 비효율적이라는 비판도 여전히 거셉니다. 저는 여러 프론트엔드 프로젝트 경험을 바탕으로 단위 테스트는 반드시 필요하다는 결론에 도달했습니다. 단위 테스트는 코드를 안전하게 리팩토링하고, 코드 품질을 유지하며, 오류를 사전에 예방할 수 있는 중요한 수단입니다. 코드베이스가 커지고 협업 인원이 늘어날수록 단위 테스트를 통해 코드 수정 시 발생할 수 있는 문제를 사전에 방지해야만 하며.. 2024. 10. 9. next.js에 FSD 폴더 구조 패턴 적용하기 Backgrounds최근 Next.js 프로젝트에 Feature-Sliced Design(FSD) 패턴을 도입하게 되었습니다. FSD는 프론트엔드 프로젝트에서 모듈들의 레이어(layer)를 명확히 구분하고, 상위 레이어와 하위 레이어 간의 의존성 방향을 명확히 하여 모듈 간 결합도를 낮추고 변경 사항이 어디까지 영향을 미칠지 예측 가능하게 만들어줍니다. 이를 통해 유지 보수성이 크게 향상된다는 장점이 있습니다.(자세한 설명은 이전 글을 참고해주세요) 하지만 Next.js와 FSD 패턴을 함께 사용하다 보니, 일부 컨벤션에서 충돌이 발생하게 되었고, 그 과정에서 몇 가지 문제점과 해결책을 찾아야 했습니다. 이번 글에서는 제가 겪었던 문제들과 이를 해결한 방법을 공유하려 합니다. 1. app 폴더 네이밍 충.. 2024. 9. 24. FrontEnd 개발자가 가장 빠르게 서비스를 구축하는 방법 Introduction웹 애플리케이션을 구축하는 것은 복잡한 작업이 될 수 있지만, 최근 몇 년간 등장한 기술 스택 덕분에 개발 속도를 크게 향상할 수 있는 방법들이 많아졌습니다. 프론트엔드 개발자들은 주로 JavaScript 또는 TypeScript에 익숙한데, 최근에는 서버와 클라이언트 모두 JavaScript로 통합할 수 있는 환경이 마련되면서 프론트엔드 개발자가 웹 전체를 빠르게 구축할 수 있는 강점을 갖추게 되었습니다. 실제로 얼마 전, 저는 부산 지역의 사설 도서관들의 도서 관리 서비스를 구축해야 했습니다. 각 사용자 별 계정을 생성하고, 해당 계정이 속한 도서관에 접근해 도서를 추가하고 삭제할 수 있어야 했으며, 사용자들이 저장된 도서 정보들을 검색할 수 있어야 했죠. 즉 웹 애플리케이션의 .. 2024. 9. 8. [chrome extension] 이미지 파일 안전하게 불러오기 Backgrounds일반적인 웹개발 환경에서는, 아래와 같이 이미지를 불러올 수 있습니다.import someImg from "./some-img.png";만약 이 상황에서 해당 경로에 파일이 존재하지 않는다면, 빌드 시 Module not found 발생합니다.대부분의 번들러들은 소스코드를 분석할 때 require, import로 참조된 모든 모듈과 자원을 탐지하며,이 덕분에 존재하지 않는 파일을 불러오는 등의 실수를 미연에 방지할 수 있습니다. chrome extension에서는 이미지를 불러오기 위해 조금 다른 방법을 사용해야 합니다.익스텐션의 content_scripts는 현재 실행되는 웹페이지를 기본 context로 가지기 때문에위와 같이 작성할 경우, 현재 웹페이지/some-img.png 경로.. 2024. 8. 9. Feature-Sliced Design(FSD) 도입기 최근 사내 core-package의 FE 파트 폴더 아키텍처에 Feature-Sliced Design(FSD)를 도입했습니다. 해당 FE 서비스는 1) 전통적인 React 폴더 구조 → 2) 클린 아키텍처(헥사고날 아키텍처) → 3) FSD 지금까지 이렇게 총 3번의 구조 변경을 겪었으며, 각 단계에서 느꼈던 문제점과 해결 방안을 공유하고자 합니다. 1. 전통적 폴더 구조처음 프로젝트를 구성할 당시, 가장 일반적이고 전통적인 폴더 구조 형태를 따랐습니다.src/├── api/│ ├── userApi.ts│ └── productApi.ts├── components/│ ├── Header.tsx│ ├── Footer.tsx│ ├── UserProfile.tsx│ └── ProductLi.. 2024. 8. 3. [chrome extension] dynamic import시 Cannot find module 에러 해결하기 Backgroundchrome extension의 content script에서, 다른 모듈을 동적으로 import하고자 했습니다.https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import import() - JavaScript | MDNThe import() syntax, commonly called dynamic import, is a function-like expression that allows loading an ECMAScript module asynchronously and dynamically into a potentially non-module environment.developer.mozilla... 2024. 7. 26. WebComponent에서 styled-components 사용하기 Backgrounds현재 회사에서 개발 중인 제품은 고객사 웹 페이지 위에서 동작하는 다양한 모듈들을 제공하는 형태입니다.이때 고객사 페이지와 독립적인 스타일을 유지하기 위해,별도의 웹 컴포넌트를 생성한 뒤 그 안에서 자체적으로 정의한 스타일이 동작하도록 구현했습니다. https://developer.mozilla.org/en-US/docs/Web/API/Web_components Web Components - Web APIs | MDNWeb Components is a suite of different technologies allowing you to create reusable custom elements — with their functionality encapsulated away from th.. 2024. 7. 10. [jest] waitFor을 통한 비동기 함수 테스트 Backgrounds비동기 함수에 대한 단위 테스트를 작성해야 할 때가 있습니다.function someTask(): Promise { return new Promise((resolve) => resolve(true));}it('비동기 함수 테스트', () => { const result = someTask(); expect(result).toBe(true);}); 위와 같이 테스트 코드를 작성하면... 당연히 실패합니다! someTask는 Promise를 반환하는 비동기 함수이므로expect 구문이 실행되는 시점에는, 해당 값은 Promise이기 때문이죠. function someTask(): Promise { return new Promise((resolve) => resolve(true));.. 2024. 6. 23. [jest] test.each를 통해 여러 입력값 테스트 간결하게 구현하기 Backgrounds동일한 테스트를, 입력값만 바꾸어서 실행해야 할 때가 있습니다. 데이터를 특정 형태로 변환하는 함수들이 대표적인 경우겠죠. 예를 들어, 입력받은 ms를 시간과 분 으로 분리하는 함수가 있습니다.import { convertMsToHoursAndMinutes } from '@/utils/time'; it('ms => 시간/분 변환 함수 동작 테스트', () => { const ms = 1800000; // 30분 const { hours, minutes } = convertMsToHoursAndMinutes(ms); expect(hours).toBe(0); expect(minutes).toBe(30); }); 1800000ms(30분)을 입력받으면, 0시간 30분 을 반환하는지 테스트 .. 2024. 6. 13. 이전 1 2 3 4 ··· 6 다음 728x90 반응형
