에브리타임이랑 비슷
- js, jquery -> vue, typescript [MPA -> SPA로 서비스 전환]
- TDD(테스트 주도 개발)로 프로젝트 진행
- 댓글 모듈 컴포넌트 사내 라이브러리 배포
문제들
- 페이지 전환 시 댓글 모듈 스크립트 주입
- 최상위 doc에 등록된 모든 이벤트
- 상태 추적의 어려움
- 가독성
- 파악하기 어려운 코드 덩어리
페이지 전환 시 스크립트를 브라우저에 주입하는 방식의 문제
MPA - 댓글 모듈을 사용하기 위한 일련의 작업이 필수적으로 필요
2000줄이 넘는 코드
- 시간이 지나며 복잡도는 더해졌고
- 기능 추가하며 유지보수하기 어려울 정도
- 과거에 머물러 있는 문서들로는 댓글 모듈이 포함한 기능 이해 어렵
template engine(ex. mustache) - ui 관리
여러 단점
- 같은 UI but 중복
- 스타일 변경 위한 조건문의 중첩
- 분리되지 않은 컴포넌트
- 상태 추적의 어려움
레거시 코드를 걷어내고 spa에서 사용할 수 있는 새로운 소셜 댓글 모듈 필요
어디서나 재활용할 수 있도록 개선해야
댓글 모듈의 기능이 추가되고 스타일이 바뀌는 과정에서 문서는 그대로
레거시로 남은 코드
노션에 기존의 소셜 댓글 모듈이 가지고 있는 기능 정리
작은 기능부터 하나씩
모듈로 관리
상태/ 뮤테이션/ 액션/ 게터
중복은 공통 컴포넌트로 재활용할 수 있도록
- 매번 문서를 다시 보고 이해하는 것을 피할 수 있다
- 기능 추가, 수정 시 확실히 작동한다는 확신을 얻을 수 있다
=> 불확실성을 없애고 추후의 유지보수 작업을 효율적으로 진행하고자 함
JEST
vuex-mutations, actions 중심으로 unit test
필요한 input 정보를 Mock 객체로 만든다
import texts
테스트 코드 작성 - 통과하기 위한 코드 작성 - 리팩토링
정리한 기능 목록들을 바탕으로 시나리오 작성
테스트 코드 작성하고 개발 진행
앞서 정리했던 기능 목록들을 바탕으로 시나리오 작성 후 테스트 코드 작성하고 개발 진행
불확실성 제거하고 의존성이 낮은 함수들을 만들어가며 안정성 있는 개발 가능
테스트코드를 짜지 않는다면, 지금 리팩토링하고 있는 댓글 모듈도 누군가가 기능을 파악하기 위해 코드를 뜯어보고 문서를 훑어봐야 하는 상황이 오리라 싶었습니다. 더불어, 기능을 추가하거나, 수정을 해야 하는 상황에서 댓글 모듈이 확실하게 작동된다는 확신을 얻고자 했습니다. 결론적으로, 테스트코드를 통해서 불확실성을 없애고 추후의 유지보수 작업을 효율적으로 진행하고 싶었습니다
스토어 내부에 있는 state들과 request, response값을 mock으로 만들어서 테스트
mutation test
action test
component test
테스팅 프레임워크라고 불린다
기존과 차별점이 있따
이전에는 mocha
jest는 단순한 테스팅 라이브러리가 아닌 '테스팅 프레임워크'라고 부르는 만큼 기존 자바스크립트 테스팅 라이브러리와는 차별점이 있다
jest 이전에는 자바스크립트 코드를 테스트하라면 여러 가지 테스팅 라이브러리를 조합해서 사용하곤 했다. mocha나 jasmin
test runner: mocha, jasmin
test matcher: chai, expoect
test mock 라이브러리 : sinon, Testdouble
굉장히 유사하지만 살짝씩 다른 api
jest는 라이브러리 하나만 설치하면 test runner, matcher, mock 프레임워크까지 제공해주기 때문에 상당히 편리하게 느껴진다
프로젝트 생성
mkdir my-jest
npm init -y
ls
package.json
jest 라이브러리 설치
라이브러리를 개발 의존성으로 설치
npm i -D jest
test Matcher
많이 사용하는
toEqual : 가짜 유저 객체를 리턴하는 함수 테스트
toBeTruthy, toBeFalsy
toHaveLength, toContain
toMatch
toThrow
toXxx : test Matcher
ex. toBe : 숫자나 문자처럼 객체가 아닌 기본형 값을 비교할 때 사용
npm test : 프로젝트 내 모든 테스트 파일을 찾아서 테스트 실행
jest : test.js로 끝나거나 'test' 디렉터리 안에 있는 파일들은 모드 테스트 파일로 인식
unit test
하나의 기능을 개발하고 웹 브라우저에 접ㅗ
기능
-계정당 1개 글에 이모지 공감 1번만 가능
-이모지 공감 취소 및 변경 불가 (메시지: “이미 공감한 글입니다.”)
- 공감 불가 케이스 (메시지: “공감할 수 없습니다.”)
🙋♀️ 수강하지 않는 강의의 대화 글
🙋♀️ 본인 작성 글에 공감
🙋♀️ 읽기 및 쓰기 권한 없을 때 (이용제한 등)
-이모지 공감 기능
- 공감 수 높은 순으로 정렬
- 단, 본인이 공감한 이모지를 제일 먼저 노출
- 추가 버튼 및 이모지 목록 노출 안 함
- 인기 이모지
- 3개의 행으로 노출- 하단에 그룹 선택지 노출
describe : 연관된 각 테스트를 그룹화하여 설명
it : 진행하는 유닛 테스트
expect : 들어오는 값이 특정 조건을 만족하는지 확인
.toEqual(value) : expect의 메소드로 객체의 모든 속성 값이 정확히 일치하는지 확인axios를 mocking하는 작업
실제 환경과 테스트 환경 분리
실제 api요청을 보내는 것이 아니니까
실제 요청을 테스트 도중에 보내게 되면
- 실제 데이터 값이 변경될 수 있는 위험
- 불필요하게 테스트 시간이 더 길어질 수 있다
mockMemberInfo도 가져와서 사용하며 테스트 코드를 작성한다
state들과 request, response 값을 Mock으로 만들어 테스트하는 일이 잦아진다
이때 폴더를 분리하여 파일을 관리해주면 된다
Vue Testing Handbook
https://zuminternet.github.io/zum-comment-component/
Vue test코드
- created vs mounted : API 요청에 대한 응답 값을 받아 상태에 저장해도 ㅡㅐㅕㅜㅅehls zjavhsjsxmdptj
- SPA와 맞지 않는 APU요청과 응답 : jquery를 사용한 직접적인 DOM 조작에 맞춘 것
리팩토링하는 댓글 모듈에는 맞지 않다
overfetcing 너무 많이 가져옴
cache-loader의 에러 : css extraction으로 인한 문제, 이미지 파일 용량으로 인한 문제 등 예상치 못한 버그들이 발생. Vue-cli를 통해 만들어진 환경이 어떻게 구성되어 있는지 모른다는 무지함에서 온 결과
기업 이익에 직결된 파트, 선배와 동료들에게 큰 도움, 핵심적인 역할,
전세계 반 이상을 차지, 큰 영향력, 불량을 확인해 도움
1. 영향력 - 회사 외부 한국 너머 세계의 많은 사람들에게 (시장 점유율 50%) / 내부 많은 사람들에게 품질을 보장해주는 역할 (마지막 확인 단계로 결정적인 역할 ex. 코드리뷰를 받는 것처럼 불안함을 잡아줄 수 있는,
2. h/w에 대한 관심 - 웹에 한정된 지식 / 작동 원리 등 기계에 더 가까워지고 싶다 /
어떻게 이게 가능한거지? cs50강의 0,1비트로 모든 것을 표현 무엇을 통해? CPU의 레지스터를 통해 이렇게 0 레벨까지의 해설을 듣고서야 직성이 풀림. 물리적으로 알고 싶음. 결국 소프트웨어는 하드웨어를 바탕으로 이루어지니까
공정 기술 스터디 - 수율 관리
