외주만 돌리는 프리랜서로 산지 어언 1년,, 이제는 다시 취업이 하고싶어졌습니다.항상 실무위주로 돌려서 몰랐었는데 개발자들은 보통 깃허브 주소를 포트폴리오로 내니까 한번 둘러보게되었는데 다른분들 깃헙을 보니 본업말고도 사이드플젝이 넘넘 많은것임...저는 왜 본업만 했는

왜 디자인 시스템이 필요할까? 디자이너가 바뀌거나 하면서 디자인 파편화가 일어나므로 이를 방지하기위함이다. (각기다른 디자인과 색상등) 1.타겟설정 회사, 사용자, 만드는사람(개발자,디자이너) 2.타겟이 겪는 문제발굴 3.액션 아이템 설정 4.각 타겟에 맞는 목표설

빠져드는 기획의 필수요소 1. 어려운 이야기는 개념정리부터 하고 시작 비개발자가 보아도 이해가 쉬운것 2. 우리가 마주한 문제를 이미지와 그림으로 표시하자. 이미지와 그림은 누구나 만들기 쉽고 이해하기 쉬운 수준으로 제작하자.  3. 문제점 인지 후 해결방안으로

바퀴를 재발명 하지말자. 이미 선배들이 오랜시간 노력해서 만든 성과들이있다면 거인의 어깨에 올라타 적절히 사용하는것이 좋다. 오픈소스 깃허브 오픈api 디자인으로치면 중요한 BI 로고 정도만 직접디자인하고, 아이콘 등 중요하지않은건 이미 만들어진것을 가져다쓰자. 개

Next14버전으로 위치 기반 서비스를 개발하고있는도중 네이버크레딧이 나온다해서 네이버지도를 사용하기로 했습니다.크레딧이 안나와도 대표계정 1개는 무료니 걱정하지마세요! ( 저도 일단 개인계정으로 개발중 )나중에 까먹을까봐 적어놓는 일기라고 생각하면되고 저처럼 완전 네

✍ 프로젝트 소개 >기간 : 2024.09~2024.10 인원 : PM 1명, Design 1명, Front 2명, Backend 1명 주제 : 친구들과 함께하는 1일1다짐 두더지(Do Does Did) 프론트 스택 : react, typescript, tanstac

프론트엔드 아키텍처 중 하나.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 준비단계 테스트의 사전 조건이나 초기 상태를 설정 데이터베이스 초기화, 테스트하려는