프론트엔드 아키텍처 중 하나.FSD는 앱을 기능단위로 분할하고, 각 기능을 독립적으로 개발,테스트,유지보수 할 수 있도록 하는것이 목표이다. 기능중심설계 : 기능단위로 구성계층화 : 코드를 여러계층으로 구분하여관리 (통일성) 단방향의존성 : 상위계층은 하위계층에만 의존

storybook이란? storybook은 'UI'를 테스트하는 도구로, '동작'을 테스트하는 jest cypress와는 다르다. 쉽게말하면 api명세서처럼 ui를 명세화 하여 디자이너와 다른 프론트엔드 개발자와의 협업을 원활하게 도와준다. 아래 그림을 보며 설명을

버셀은 무료버전은 개인 연습용 프로젝트만 지원하기때문에, organization 레포지토리는 무료버전으로 배포할 수 없다.그런데 사이드프로젝트같은것을 하다보면 organization으로 팀을 결속하여 다같이 소스를 공유하기때문에 연습용인데도 불구하고 무료버전을 사용하지

우선 jest와 cypress를 같이 사용하는것은 좋은 방법은 아니다.type도 다르고, 2가지 테스트 스택을 사용하는것은 너무 무의미한 일이다. 그치만 나는 두개를 다 학습하는 단계여서 같이 사용하고싶었다.cypress 공식문서를 보면 jest와 같이 사용하면 typ

cypress가 생성해준 폴더중에 fixtures라는 폴더가 있는데 이건 과연 무엇일까? fixtures는 일반적으로 테스트코드에서 여러곳에서 사용되는 고정 값을 뜻한다.예를들면 mocking시 response body가 길어질 경우 fistures를 사용하면 좋다.

그냥 태그에는 data-cy로 접근할 수 있지만, 공용 컴포넌트일때는 어떻게할까? 공용 컴포넌트는 한 곳이 아닌 여러곳에서 쓰이기 때문에 그냥 data-cy로 접근하면 여러곳에서 쓰인 컴포넌트가 다 호출된다.따라서 공용컴포넌트는 props로 data-cy를 받아 사용하

js파일로 테스트케이스 만들때는 에러가 안뜨는데 ts로 테스트케이스를 만들면 오류가 뜨는 경험이 있었는데, 예전에 어떻게어떻게 구글찾아서 해결했었는데 다시 에러를 마주하니 당황스러웠다.오늘은 내 기록을 남겨보려고한다.앞서 말한거처럼 js는 괜찮다가 ts로만 만들면 에러

이때까지는 코드내에서 테스트케이스파일을 만들어 테스트를 했는데, cypress를 실행할때 열리는 크롬 GUI에서도 테스트케이스를 생성하여 흐름을 테스트 할 수 있다. 근데, 파일생성은 되나 세세한 테스트작성은 결국 코드에서 하는거라 의미가 있는 기능인지는 모르겠음 아시

테스트코드가 실제 서버에 HTTP통신을 하는것은 비효율적이므로, 가짜 request를 보내는것처럼 보이게하는것 cypress에서 테스트케이스를 작성하다보니 로그인 등은 실제 서버로 HTTP통신이 이뤄졌다.이건 테스트코드이기때문에 실제 통신이 이뤄지는것은 비효율적이다.

cypress는 jest랑 다르게 e2e테스트로 실제 사용자가 행동하는것처럼 테스트한다.예를들면 로그인을 테스트하면 given 로그인 페이지에 접근한다when 아이디,비번을 입력하고 로그인버튼을 클릭한다then 로그인에 성공한다이때, 처음 페이지에 접근할때 cy.vis

jest는 유닛테스트를 위해 나온 테스트이고, cypress는 e2e테스트를 위해 나온 테스트라는게 우리가 일반적으로 알고있는 개념이다. 그런데, 프론트관점에서 함수하나만 검증하고, 버튼하나만 검증하고 하는게 테스트를위한 테스트코드를 작성하는 느낌이 든다. cypres

전체 코드 중 어떤 부분이 테스트되어있고, 어떤 부분이 테스트가 안되어있는지 알려준다. 전체 코드를 다 테스트할수록 신뢰성있는 코드라고 볼 수 있어 100%를 채우면 좋을것같다. package.json scripts에 다음과 같이 추가한다. "coverage": "je

expect.뒤에 붙는 기능들을 정리할 생각이다.기대한 값이랑 실제 반환된 값이 일치하는지 확인하는 작업이다.객체의 내용이 같은지 객체의 내용이 같은지, 단 undefined를 고려한다. 값 비교toBe는 문자열이 정확한지만체크, toMatch는 정규식 확인에 쓰임to

테스트코드 구조 한 테스트코드 내에서 given when then으로 나눠서 작성하면 테스트의 가독성과 이해도를 높이고, 명확한 테스트* 흐름*을 유지하기 좋다. given 준비단계 테스트의 사전 조건이나 초기 상태를 설정 데이터베이스 초기화, 테스트하려는

jest를 사용하기위한 필요한 패키지를 설치해준다.두가지방법이 있는데, package.json에 jest에 대한 환경설정을 같이 넣어줘도되고, 아니면 루트에 별도의 파일을 생성해 환경설정을 해주는 방법이있다.나는 가독성 및 분리를 위해 루트에 jest.config.cj

describe : 테스트케이스 컴포넌트 ( it test의 묶음, 관련있는 테스트들을 하나로 묶어 응집도를 높일 수 있음 ) it test : 테스트케이스 작성 (영/한 => 가독성이좋다.)beforeEach : 각각의 테스트케이스전에 각각 한번씩돈다.beforeA

정확성 및 신뢰성 확보 \- 올바르게 작동하는지, 예상대로 작동하는지 확인할 수 있다.리팩토링리팩토링 전 테스트 코드를 작성하면 최소한의 기준이 만들어진다.프로젝트 초반부터 테스트코드를 작성하면 좋지만 시간이 부족하기때문에, 리팩토링 전에 테스트코드를 작성하는게 좋다

구글 애널리틱스로 통계와 유입양을 보며 프로젝트 유지보수를 해야겠다고 생각했습니다.근데 SPA방식인데 singlepage인데 어떻게 page넘어가는걸 구분할까? 하고 의문이 들었습니다.방법은 router의 페이지 이동을 감지하는것입니다. 리액트는 useLocation

모든 과정을 혼자 해봄으로써, 협업 구조와 프로세스의 전체적인 흐름을 이해한다.개발을 하다보니 백엔드를 해보지않아 프론트로 오기까지의 과정이 이해가 잘 되지않았다.이론으로 어느정도 공부가 되기는 하지만 쏙쏙 이해가 가지는 않는 느낌,,그래서 이번 프로젝트의 목표는 "나

안녕하세요 프론트엔드 개발자 김소현입니다 :) 스위프(SWYP) 6기에 참여하여 서비스를 출시하고, 오늘은 그 6주간의 회고를 진행해보려고 합니다! 저또한 처음 신청하기전에 구글에서 후기를 엄청 찾아봤기때문에, 다음 기수분들이 후기를 찾아본다고 생각하고 어떻게 진행되는