오늘 한 일
오늘은 하루종일 바로인턴 백엔드 온보딩 테스트를 보았다.
문제 자체는 기본적인 구현이었지만, 세세하게 파고들면 파고 들 수도 있는 문제들이었다.
우선 현재는 기본구현은 완료가 된 상태이고, 처음으로 pytest를 이용해서 테스트까지 실행 후,
failed한 부분을 수정하는 것 까지 진행하였다.
pytest의 작성법이나 , CBV로 구현한것은 따른 글을 통해서 설명하겠다.
오늘 한 작업중, pytest에 failed를 passed 로 변경 및 수정을 한 트러블 슈팅에 대해서 적어보겠다.
트러블슈팅
- Signup의 테스트 케이스가 통과되지 못함 1
- 원인 : Signup의 response가 테스트 케이스와 일치 하지 않음을 파악. 리스트로 딕셔너리를 감짜는 형태로 딕셔너리 안에 유저의 데이터가 print되야하는데, 문제는 views 에서 signup response가 ' Response("user":serializer.data) `로 되어있어서 user로 한번더 감싸게 되어서 테스트 케이스와 다른 response를 하기 때문.
- 해결방법 : Response에서 user로 감싸지 않고 바로 serializer.data로 바로 데이터를 반환. 이때 serializer의 데이터 response형태는 model에서 설정한 그 형태로 나오기 때문에 원하는 response의 형태가 model에 제대로 설정이 되어있는지 파악을 해야함.
- 1. 문제 파악 (repsonse의 형태가 다름을 파악)
- 2. 해결방법 모색 : 테스트 케이스에서 signup의 then(에러검증)은 reponse의 기반으로 되어 있기 때문에, response비교 > response의 형태가 테스트케이스와 다름을 파악 > views에서 response의 형태를 변환 > model에서 원하는 형태로 데이터가 설계되어있는지 확인 > 테스트
- 3. response의 형태는 맞는데 아직 signup 테스트 failed > 다음 문제 파악
- Signup의 테스트 케이스가 통과되지 못함 2
- 원인 : 다양한 테스트를 진행한 결과, 주어진 테스트 비밀번호가 너무 심플해서 생긴 문제. serializers 에서 설정한 비밀번호는 최소한의 검증을 위해서 django의 password validator를 통해서 검증이 되는데, 이떄 주어진 비밀번호 "12341234" 가 validation을 통과하지못하여 생긴 오류.
- 해결방법 : settings의 auth_password_validation의 numericpassword를 삭제 (숫자만 있는 비밀번호를 제한), 그 후 테스트 결과로 failed를 또한번 받게됨. 이때의 문제점은 commonpassword를 통과하지못하였음. commonpassword의 validator코드를 제거 후 테스트 하 결과 통과함.
- 1. 문제 파악 (비밀번호 검증 통과 실패)
- 2. 해결방법 모색 : password 코드 확인 > validator 확인 > 문제가 될거 같은 validator코드 제거 후 테스트
- 3. 완료
회고
생각보다 문제는 쉽다고 생각했지만, 생각을 해봐야하는 부분이 매우 많았다.
비밀번호의 검증을 아예 풀수는 없기 때문에, validator를 적절히 사용하는 법을 확인.
또한 테스트 케이스에서 response만을 넣었기 때문에 생기는, 즉 model에서 검증을 하는 부분에 대해서는 제외를 시켜서 문제 파악에 늦은것을 확인.
다음부터는 조금더 디테일하게 테스트 케이스를 짜야겠다.
내일 테스트 케이스 추가하고, 코드전반적으로 체크 후, rds 랑 redis 적용법 한번 시도 해보고 안될거 같으면 바로 배포로 넘어가는 선택을 하겠다.
'TIL and WIL > TIL' 카테고리의 다른 글
2025년 02월 24일 TIL (0) | 2025.02.24 |
---|---|
2025년 02월 14일 TIL (0) | 2025.02.16 |
2025년 02월 12일 TIL (0) | 2025.02.12 |
2025년 01월 9일 TIL (0) | 2025.01.10 |
2025년 01월 08일 TIL (0) | 2025.01.09 |