iframe 간의 통신을 사용하는것에 MessageChannel API를 사용하고 있는데, jest에서 모킹을하려하니까 안되었다. window.MessageChannel not defined... 이런 경우는 jest코드 상단에 아래와 같은 코드를 삽입하면 해결할 수 있다. window.MessageChannel = require("worker_threads").MessageChannel; worker_threads는 nodejs에서 기본제공해준다. 마찬가지로 MessagePort같은것을 mocking할 때에도 사용할 수 있다.
앞서 고민했던, 상위 컴포넌트에서는 하위 컴포넌트에서 사용하는 함수들을 모킹해주어야 하는 문제가 있었다. 컴포넌트의 계층 구조가 높아질수록, 상위 컴포넌트에서 하위 컴포넌트에서 사용했던 mocking을 그대로 다시 선언해주어야하는 경우가 많아지는 것이다. 이를 해결하기 위해서 __mocks__ 폴더를 만들어서, 이름이 같은 hook을 모킹해주었다. 이렇게 하게되면, jest.mock()을 호출할때 __mocks__폴더내의 이름이 같은 함수를 자동으로 내가 선언한대로 모킹해준다. 이제, 하위 컴포넌트에서 사용했던 mock을 재사용할 수 있다. 하지만, 이것은 해당 hook 자체를 모킹해버리기 때문에 훅 커버리지를 높이지는 못한다. 또한, 1종류의 mocking만 가능하기 때문에, 다른 반환값을 원한다면 훅..
지금, 이 리팩터링을 하기 전에는 모든 테스트 코드가 src/__test__ 폴더 내에 통합, 단위 테스트의 단위로 저장되어 있었다. 사람도 물리적인 거리가 멀어지면, 마음이 식듯이 개인적인 느낌으로는 테스트코드도 테스트대상과 멀어지니까, 테스트 대상(여기서는 컴포넌트)이 리팩터링 또는 기능 및 인터페이스가 변경되었을 경우, "테스트 코드도 수정해야지"라는 마음이 쉽게 들지 않았다. 심지어 다른 컴포넌트와 병합되거나 삭제된 컴포넌트들도 테스트를 돌려보기 전까지 살아있던 경우도 있었다. 그래서, 모든 테스트코드를 테스트 대상과 가까운 거리로 옮겼다. 이제 테스트코드들은 해당 테스트 대상(컴포넌트)와 한몸이 되었다. 폴더가 옮겨져도 함께 변경사항이 있을때도 함께 움직이고, 어떤 테스트 코드를 확인하고 싶을때..
지금까지 코드리포트를 쓰면서, 테스터블한 컴포넌트에 대해서 작성을 했었다. 최대한 렌더링 로직만 담당하도록, 더 멍청하게 만드는 것이다. 아직 그렇게 리팩터링하지 못한 것들도 어떻게든 모킹을해서 테스트 코드를 작성해놓았다. 하지만, 위 사진의 Comment를 보자. molecule에 있지만, 곧 organism으로 이사할 거대한 컴포넌트이다. 저 안에는 CommentInput, PasswordForm, SubComment, CommentOption, CommentTextBox, UserOption 들이 들어가있고, 이 중 몇개는 비동기 담당 커스텀훅을 사용한다. 즉, Comment를 렌더링하려면, 이 하위 항목이 사용하는 비동기 커스텀훅까지 다시 모킹해주어야 정상테스트가 가능하다. .... 그건 에바다...
https://www.youtube.com/watch?v=V-JFz56_gNw&ab_channel=%ED%84%B0%EB%8B%9D%ED%8F%AC%EC%9D%B8%ED%8A%B8-%EC%9C%84%EB%8C%80%ED%95%9C%EC%84%B1%EA%B3%B5%EC%9D%98%EC%8B%9C%EC%9E%91%EC%A0%90
react를 처음시작할 때에는 컴포넌트는 UI기준으로만 분리하면되고, 사용하는 측에서 컴포넌트를 사용을 하면, 해당 컴포넌트가 다 알아서 해주는 것. 즉, 똑똑한 컴포넌트가 좋은 컴포넌트라고 생각했다. 하지만, react 철학으로나 어느 경로로든, "상태끌어올리기"와 "컴포넌트는 멍청해야한다" 등의 어휘를 들어보았을 것이다. 지금까지 그에 대한 이유를 나름 정의하고 있었는데, "상태끌어올리기"는 상태의 single of truth 를, "컴포넌트는 멍청해야한다"는 외부에서 제어하기 쉽게하기 위함이라고 생각하는 것이었다. 내 머릿속에는 이 2가지의 어휘가 따로따로 존재하고 있었다. 그리고 오늘 이 2가지가 가지는 공통적인 결을 발견했다. 바로 "테스터블한 컴포넌트가 되기 위한 조건"이었다. 이것을 깨닫기전..
이번 프로젝트에서 가져가고자 하는 것에서 테스트 코드를 견고하게 가져가려고 개인적으로 마음먹었다. 그래서 조금 시간이 남을때 test code 커버리지를 높이는 작업을 하고 있다. 또한, test파일을 컴포넌트와 가깝게 배치하는 작업도 하고있다. 심리적인 문제일수도 있겠지만 컴포넌트와 테스트코드가 멀어지니까, 기능이나 코드가 변경되었을때 test코드 수정을 까먹는 일이 많았기 떄문이다. 아무튼, 테스트 커버리지를 높이다가 1가지 깨달은게 있다. 테스트 커버리지를 높이려면 분기 커버리지도 높아야한다. 분기 커버리지가 뭐냐면, if else같은 조건문이 있을때 if도 실행하는 test code가 있어야하고, else부븐도 실행하는 test code가 있어야 분기 커버리지가 100%가 나온다. 근데, 컴포넌트..
우테코 내에서 하고있는 일이 있어서, 간단한 미션을 구현할 일이 생겼다. 아마 커밋링크를 올렸다가 추후에 문제가 있을 수 있기 때문에 적당한 코드들만 직접 첨부하겠다. 우테코 레벨1처럼 순수하게 바닐라 자바스크립트로만 작성을 해야했는데, 갑자기 예전에 다른 크루가 공유해준 유투브가 생각났다. https://www.youtube.com/watch?v=RtvSgptpfnY&ab_channel=%EC%BD%94%EB%94%A9%EC%95%A0%ED%94%8C 보면 재밌다. 그 유명한 깃허브가 react 같은거 없이 작성되어있다니! (설마, 가끔씩 comment가 2번 등록되거나 하는 버그들이 그것때문이려나? 라는 생각도 들었다.) 깃허브는 자바스크립트에서 기본적으로 제공해주는 WebComponent라는 것을 ..
