과제 링크
위는 과제 설명들입니다. 아래는 제출한 레포지토리입니다.
제출 레포지토리 - arch-spatula / wanted-pre-onboarding-frontend
테스트 코드 작성하면서 느낀점
- 리팩토링이 쉽습니다. 코드를 변경하면서 어디가 오작동하는지 피드백을 받으면서 바꾸기 때문에 안정적입니다. 상수명의 역할을 더 분리하고 또 axios client를 팩토리함수로 리팩토링할 때 변경이 쉬웠습니다.
- 코드 퀄리티를 올릴 수 있는 환경이 생깁니다. 물론 좋은 아키텍쳐와 더 좋은 코드 기준을 모르기 때문에 한계가 많습니다.
- custom hook을 테스트하기가 어렵습니다. 이것은 저의 개인적인 지식의 부족입니다. 많은 지식이 부족하지만 컴포넌트와 유틸함수에는 테스트 코드를 작성할 수 있었습니다.
- 완전한 TDD로 코드를 작성하기는 어렵습니다. 하지만 기능을 먼저 작성하고 테스트를 걸어두면서 작성은 가능했습니다.
- 코드 작성시간이 더 오래걸립니다. 빠르게 구현하는 코드가 아닙니다. 이터레이션이 더 중요하면 테스트가 후순위가 될 수 있는 이유를 알 것 같습니다. 구현을 위한 코드도 작성하고 테스트코드도 작성하면서 더 오래걸립니다. 또 프론트엔드는 요구사항의 가변성이 큽니다. 테스트의 의미가 금방 퇴색 될 수 있습니다.
- 테스트로 코드의 부분은 설계할 수 있습니다. 하지만 크게 아키텍쳐를 설계하거나 어느 방향으로 유도하는 방법은 저의 역량 부족입니다.
- 과제 자체는 간단한 Todo-App인데 코드 퀄리티를 최대한 높이는 것이 관건이었습니다. 테스트를 활용하면 코드퀄리티를 쉽게 높일 수 있다고 했습니다. 모든 부분에서 공감하는 것은 아니지만 어느정도 이해가 갑니다.
- 테스트 툴자체를 공부도 해야 하고 테스트 방법론도 공부해야 합니다. span 태그는 role이 없다는 것도 알게 된 것처럼 알아야 할 것들이 많이 필요합니다. 도구적으로 알아야 하는 것도 부족하고 테스트가 중복과 누락없이 버그가 없음을 검증해야 합니다. 테스트 방법론 자체를 공부하는 시간이 필요합니다.
다음
- 이번주는 잠시 자료구조와 알고리즘 유데미 강의와 코테를 꾸준히 풀고 가끔 만드는 cook-book을 배포를 생각하고 있습니다.
- 더닝크루거 효과답게 괜찮게 작성했다고 착각하고 있습니다. 일단 테스트 코드 작성경험을 포트폴리오를 리팩토링에 활용할 것 같습니다.