2차 Project - View의 작성
Class101 홈페이지의 클론코딩을 위한 modeling이 완료가 되고 merge가 되었다. 1차 project때 보다는 modeling이 수월하게 이루어 졌던 것 같다.
2차 project backend의 2가지의 목표
1. merge 대신 git rebase를 사용해서 commit 관리하기
2. Intergration test 대신 unit test를 사용해 test 하기
1차 project때는 홈페이지의 한 사이클을 구현하는 것이 목표였다면 2차 project의 목표는 git rebase와 unit test의 사용이 주된 목표였다.
git rebase는 2차 프로젝트를 대비해 주말에 공부 한 것이 있어 어느 정도는 자신이 있었지만, unit test는 처음 들어보는 내용이었다.
View의 작성
팀에서 product app의 modeling을 작성한 후, 프로젝트의 main기능인 클래스를 Create하는 로직을 짜게 되었다.
View를 구성하는데 있어서 고려할 점
1. unit test
아무래도 2차 project의 main 구현 기능 중 하나이기 때문에 신경이 안쓸 수가 없었다.
set up
django 공식문서를 보게 되면 'set up'은 테스트 fixture를 준비하기위해 호출 된 메소드 라고 나와 있다. 추가적으로 setUP메소드는 가상의 데이터베이스를 만들어서 test를 하기 위한 준비 단계 라고 생각하면 된다.
Create 기능을 구현하기 위해 사전에 Foreignkey로 관계설정이 되어있는 Class를 미리 선언해 test를 구현하는데 있어 가장 기본적인 데이터를 넣어 놓는다.
※ 여기서 Post를 구현 한다면 저정도만 하면 되지만 만약 GET을 구현해야 한다면, id 2개 정도는 넣고 테스트를 해야 한다. GET도 구현하기 위해 Product를 Create를 해놓았다.
Unit test - First Blocker : 로그인 데코레이터 테스트 하기
WEB에서 로그인을 해야 구현 사용할 수 있는 기능들이 있어서, 로그인 유무를 판별하기위해 login decorator를 사용했다. 하지만 app을 만들면 자동으로 있는 tests.py에서 unittest를 진행하는 방식으로는 decoretor의 test를 진행 할 수가 없었다. 그래서 POST를 진행할때 동시에 해줘야 했다.
Unit test decorator 판별 - SetUp
우선 판별을 위해 가상의 토큰을 생성한다.
self.access_token = jwt.encode({'user_id' : User.objects.get(id=1).id},SECRET_KEY, ALGORITHM)
setUP에 가상의 Token을 생성한다.
Tear down
tear down은 setUp으로 create한 test 데이터를 test가 끝나면 지운다.
이런식으로 setUP메소드로 create 해주었던 데이터들을 delete 해주었다. test가 끝났을때의 작업까지 완료!!
test_product_post_test
Unit test - Second Blocker S3 upload unit test
2차 프로젝트의 선택 사항으로 AWS S3 기능을 사용했다. 아마존 S3는 아마존 웹 서비스에서 제공하는 온라인 스토리지 웹 서비스이다. 아마존 S3는 웹 서비스 인터페이스를 통해 스토리지를 제공한다. 즉 파일을 upload를 하게 되면 url로 반환을 해주게 된다.
login decorator와 같은 맥락으로 post시에 테스트를 해주어야 했다.
그리고 준비가 끝난 후 post의 unit test
3가지의 판별 과정 - success, key_error, need_login
token도 완벽하게 들어오고 create까지 이상없이 되면 성공이다.
response = client.post('/product/create',json.dumps(product), **headers, content_type='application/json')
setup에 사전작업 만들어 놓은 token을 이용해서 login decorator에서 해주듯이 판별된 user_id를 통해 create 작업을 진행 한다.
response: 우리가 unittest를 하기를 원하는 View를 사전 준비한 data를 가지고 실행을 시킨 값을 가져온다. 그리고 assertEqual을 통해 같은지 판별 한다.!!
assertEqual(첫번째, 두번째): 첫 번째와 두번째가 같지 않게 되면 오류를 뿜는다.
그래서 reponse를 통해 나온 결과 값과, 우리가 결과값으로 보고 싶은 내용 과 같으면 성공이다.
이런 과정을 success, need_to_token, INVALD_KEY 3개를 만들어 unit test를 완성했다.
2. S3 and Formdata Handeling
ProductPostView를 짜면서 가장 힘들었던 부분이 었고, 2차 Project기간동안 최대의
Blocker였다.
그 전까지만 해서 Front에서 보내준 데이터를 'json.loads'를 통해 읽었다. 이번에는 데이터베이스에 POST 하고자 하는 data들을 Fromdata의 형식으로 보내준다고 했다.
처음에는 form데이터를 받는데 있어서 신경도 안쓰고, Integration test도 모두 끝낸 후 다른 작업들을 하면서 프론트와의 통신을 기다리고 있었다.
하지만 통신을 해보니 'JSONDCODEERROR(front가 보내준 body에 데이터가 없을때 나타나는 현상 )'와 MUlTIVLUEERROR 일어나게 되면서 생각지도 못한 'key error'를 뿜었다.
2-1 1차 수정 request.POST
다른 프로젝트팀을 돌아다니면서 form데이터를 handeling하는 방법을 수소문 하고, googling을 통해 알게된 'request.FILES'를 통해 file데이터를 받으려고 했으나 아무리해도 빈 리스트만 받아서 진전이 있지 않았다.
그때 사용한 방법이 request.POST를 통해 'QueryDict'의 형태로 받아서 바로 hadeling하는 방법이었다.
여기 까지 오기 너무 힘들고 고되었는지 오랜만에 본 200이 너무 반가웠고 우리의 handeling은 끝이 난줄 알았다. s3를 적용하지는 않았지만 중간에 s3변환 로직을 추가하면 끝날 줄 알았기 때문이다.
2-2 2차 수정 string의 반란
s3 로직을 추가한 후 받았지만, 변환이 이루어지지가 않아 엄청나게 당황했다...
해결을 위한 첫번째 방법으로 파일 경로로 오는 데이터를 파일이름.png의 슬라이싱을 통해 이름만 받기
실패!
S3로직을 우리의 입맛대로 맛게 수정!!
실패!
이유!
두 번의 실패의 원인은 지금 데이터가 오는 형식이 파일의 이미지가 오는 것이아닌 파일의 경로='string' 으로 오고 있기때문에 파일 전환 로직이 제대로 작동하지 않는 것이다.
2-3 3차 수정 handling의 완료
수십번의 'print'를 찍어보고, 저장하는 Product의 id 값이 10000이 넘어갈때 쯔음 해서, 프론트에서 오는 데이터에 경로가 아닌 image 가 담기기 시작했다......
최종 handling으로,
formdata 중 text의 파일은 'request.POST의 Querydict'로 받고, 변환된 담겨져 있는 File은 request.FILES의 Querydict 로 나누어서 받았다.
먼가 중복이 되는 부분이라서 한번에 받은 후 handling을 하려고 했으나 발표가 코앞이고 더이상 시간이 없어서 refactoring은 하지 못해서 아쉬웠다.
최종 Product Post View
