[2팀 박소연] Chapter 3-2 프런트엔드 테스트 코드#32
Open
soyalattee wants to merge 30 commits intohanghae-plus:mainfrom
Open
Conversation
- 반복 일정 생성
|
소연님! 지호님께 e2e ci관련해서 job 트리깅이 되지 않는 문제가 있으셨다고 들어서...! 제꺼 참고차 올려둡니다..! 늦지 않았길 🥹 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
8주차 과제 체크포인트
기본 과제
필수
선택
심화 과제
각 팀원들의 테스트 전략은?
피그마 주소
페어팀이 모여 각자 유닛, 통합, e2e, 시각적 회귀 테스트를 어떤 상황에 쓰면 좋을지, 과제에서 어떤 테스트가 추가되면 좋을지 얘기 나누었습니다. 그리고 어떤 테스트전략을 가져가는게 좋을지에 대해서도 얘기 나누었습니다.
그 중 이번 과제의 추가 테스트코드에 대해 제일 화두로 논의했던 것은
"간단한 일정 추가 프로젝트에 E2E는 과하다" vs "일정 관리는 유저 입장에서의 실제 브라우저단 동작이 중요하니 E2E를 해봐도 좋다" 였습니다.
그외에 테스트는 필요하며 시각적 회귀 테스트는 과하다가 만장일치였습니다ㅎ.
팀 테스트 전략
팀원들과 토의 끝에 결정된 테스트전략입니다.
도은님 PR 발췌
합의된 테스트 전략과 그 이유는 무엇인가요?
통합 테스트와 약간의 E2E 테스트를 병행하는 전략을 선택했습니다.
페어2팀의 멤버중 도은,태영, 소연 이렇게 셋이서 팀을 이루어 진행하였고, 함께 통합 테스트는 큰 시나리오 3개(알림, 달력과 일정 싱크, 일정 등록), E2E 테스트 시나리오 3개 중 각각 선택해 구현하는 방식으로 진행했습니다.
통합테스트로 서비스의 전반적인 기능 검증, E2E 테스트로 기본적인 플로우를 검증하여 사용자 경험 보장할 수 있도록하였습니다.
추가로 작성된 테스트 코드는 어떤 것들이 있나요?
페어2팀의 정도은,이태영,박소연 모두 동일한 테스트코드로 작성되어있습니다.
통합테스트
기본 알림 워크플로우
뷰 간 데이터 동기화
form 생성, 수정 플로우
E2E
기본 일정 관리: 생성 → 조회 → 수정 → 삭제 전체 플로우
뷰 전환: 월/주 뷰 전환 및 날짜 네비게이션
검색/필터링
다른분들 PR에도 써있을텐데... CI에 E2E를 추가하고싶은데 못해서 한시간넘게 헤매다가 할 수 없음으로 결론지었습니다. 하지만 영서님(라고 쓰고 구세주라고 부름)께서 방법이 있다고 코멘트 남겨주셔서 추후 적용해보도록 하겠습니다!!
과제 셀프회고
TDD로 개발하기 위해 다음과 같은 방법으로 진행했습니다.
이렇게 구현 후 리팩토링하고 끝이 났어야 했으나.. 통합 테스트코드를 잘못짜서 구현 후 통합테스트 수정 -> 리팩토링 순으로 진행되었습니다.
'/event-list' API가 추가되었다는것을 잊고 API 목킹핸들러가 추가하지 않은채 기존 목킹핸들러를 사용해 테스트코드를 작성하였던게 문제였습니다. 그래서 구현 이후 통합테스트의 테스트코드를 재작성하는 과정을 거치게 되었습니다.
API목킹 뿐만아니라 테스트검증 자체도 잘못된 부분이 많아 대부분 갈아엎게 되어.. 이게 TDD가 맞나...? 싶은 과정이였어요
반복일정에 관한 테스트는 유닛테스트케이스 8개, 통합테스트 6개로 총 14개 작성했습니다.
유닛 테스트
expandRepeats 함수에 대한 검증
통합 테스트
반복테스트에서는 기존 제공해주셨던 saveSchedule을 수정하여 saveRepeatSchedule 을 만들어 테스트에 활용했습니다.
그후 심화과제에서는 폼 쪽을 맡게되어 또 반복스케줄 등록 검증도 추가해야해서 saveSchedule 함수를 repeat 값도 받을 수 있도록 변형해서 사용했습니다.
기술적 성장
TDD 로 개발하며 유닛테스트 같은경우는 구현이 더 수월하다고 느꼈습니다. 테스트코드를 작성해두니 AI를 활용할때 구현할 코드를 설명하기도 좀 더 수월했고, 미리 테스트케이스를 짜며 예외케이스들에 대한 고민을 깊게 하고 개발하게되어 내가 짠 코드를 재수정 할 일이 적었습니다.
통합테스트는 심화과제를 위해 팀원들과 시나리오를 같이 작성하고, 분담하여 해결하고 나니 '아, 백지장도 맞들면 낫구나'라고 생각이 들었습니다. 테스트코드가 처음이다보니 헤메는곳도 많고, 실수도 많았는데 함께 통합테스트를 짜며 대화 나누고, 완성하고 나서 코드리뷰를 진행하니 더 좋은 테스트코드방법에 대해서 대화 나누며 더 나은 코드를 짤 수 있었고 같이 고민을 나누고 해결할 수 있어과제도 더 빨리 끝낼 수 있었습니다.
코드 품질
테스트코드위주로 진행된 과제 였는데, 만족스럽게 구현한 곳은 없는것 같습니다 ㅎㅎㅎ..ㅠ
아쉬운 부분은.. 반복일정등록 로직을 추가할때 addOrUpdateEvent 함수에 그대로 if else 처리해서 구현해서 이부분 리팩토링을 해야할것 같습니다.
학습 효과 분석
현재 회사에 QA팀이 없고 기획자와 개발자가 함께 QA를 진행하고 있습니다.
e2e테스트가 준일코치님이 추천해준 Playwrite CRX 사용해서 활용하니 생각!!! 보다 빠르게 작성하게 되어서, 실무에서 필요한 플로우 몇개는 적용해두면 좋을것 같다고 생각했습니다. QA부분을 어느정도 해소할 수 있지않을까라는 생각이 듭니다.
과제 피드백
TDD를 해볼 수 있어 좋았습니다!
리뷰 받고 싶은 내용