Programming Is Hard

🎯 이번 챕터를 시작하며 꼭 해내고 싶었던 목표 테스트코드 작성에 대한 두려움 극복TDD 개발론 적용다양한 기능 테스트 시도MSW 고수가 되기 🏆 이번 챕터를 마무리하며 가장 기억에 남는 성취사실 기능이 대부분 구현된 상태에서 "추가 기능을 구현하면서 테스트 코드를 작성할 수 있을까?"라는 고민이 있었는데, 8주차 과제를 통해 그 부분이 많이 해소된 것 같아요. TDD를 활용하면서 수많은 오류를 보며 통과시켰던 경험이 유익했습니다.또한, MSW를 처음부터 직접 적용해볼 기회를 가졌던 것도 좋았습니다. 기능 구현뿐 아니라 테스트코드 작성에서도 MSW를 활용해 mocking을 해볼 수 있었고, utils나 커스텀 훅 단위 테스트도 자연스럽게 진행할 수 있었습니다. 덕분에 이제는 "MSW, 두렵지 않아!"..

이번 주차 목표 (프런트엔드 테스트 코드)(1) 테스트의 필요성을 이해한다.(2) 기본적인 테스트를 작성할 수 있다. 1. 고민했던 문제- 통합 테스트를 진행하면서 mock 데이터를 생성하고 리스트에 반영하는 흐름이 자연스럽게 연결되었는지 판단하기 어려웠고, 실제로 테스트가 여러 번 실패하면서 디버깅에 시간을 많이 썼다.하지만 그 과정에서 비동기 렌더링 타이밍, 상태 반영 시점 등을 파악하게 되면서 테스트에 대한 이해도가 확실히 높아졌다. 2. 시도 및 해결- 이전에는 렌더링 안정화를 위해 waitFor를 사용했지만, 비동기 로직이 없는 경우에는 await act(() => null)처럼 최소한의 act 호출만으로도 충분하다는 점을 멘토링을 통해 알게 되었고, 이를 코드에 반영해 개선했다.// 개선..

이번 주차 목표 (관심사 분리와 폴더구조)(1) 단일책임원칙이 적용된 좋은 폴더 구조를 안다. 1. 문제 (과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제)- Jotai와 Tanstack query를 함께 사용할 때의 일관성TanStack Query가 “요청 → 캐싱 → 로딩/에러 관리”의 역할을 해준다는 점은 이해했지만, 기존 상태 관리의 actions 역할을 어디까지 위임할 수 있는지가 애매하게 느껴졌다.예를 들어 기존에는 addComment, updatePost 등의 상태 변경 로직을 Jotai 기반으로 직접 관리했는데, 이런 동작들을 이제는 mutation으로 옮겨야 하나? 아니면 여전히 Jotai로 관리해야 하나?로컬 상태와 서버 상태의 책임 분리가 뚜렷하지 않아서 혼란스러웠다. 2. 시..