json.decoder.jsondecodeerror expecting value line 1 column 1 (char 0)
Connection Error
python에서 파일을 불러오려다 보면 자주 보이는 오류입니다. pandas를 쓰면서 excel, csv를 불러올 때도 가끔 보이는 문제인데 encoding 문제일 수도 있습니다. 그런데 이번에 google drive api ( google spreadsheet api) 를 사용하던 도중 드라이브에 있는 파일을 불러오던 도중 이런 에러가 발생했습니다. "분명 local에서 잘 읽어드린 파일인데 왜 그러지?" 라고 생각했는데 google spreadsheet api로 읽으려면 xlsx, csv 파일을 google Sheets로 한 번 변환해줘야 한다는 것을 알게 되었습니다.
보통 엑셀 파일을 드라이브에 올려 놓으면 파일 형식 그대로 들어와 파일을 열어보면 이렇게 .xlsx 형식이라고 보여주고 있습니다. 이 상태로는 python으로 잘 읽혀지지 않더라구요.
파일을 누르고 'Google Sheets로 저장' 이걸 눌러주면 Google Sheet 파일 형식으로 사본을 만들어 줍는데 그 파일을 열어보면 아래처럼 .xlsx, .xls 와 같은 표식이 지워져 있습니다.
이런 상태로 변하면 python에서도 Google api로 잘 불러와지네요... 이것 때문에 한 30분 정도는 헤멘듯...
링크드인앱을 깔아놓으면 누가 프로필을 봤다는 알람이 올 때가 있습니다. 대부분의 알람은 무음으로 설정해놔서 별 생각없이 지나가기 마련인데 가끔은 심심해서 링크드인앱에 들어가 보게 되네요. 근데 최근(?)에 보유기술의 실력을 평가해보는 기능이 생겼더라구요. 막 진지하게 본 것은 아니지만 궁금해서 보게 되었습니다.
python 실력평가는 통과!
django는 불합격;
둘 다 봐보니까 생각보다 호락호락하지는 않은 느낌이였습니다. 왜냐하면 문제가 15개 나오는데 반은 굉장히 기초적이여서 '쉬운데?'라고 생각할만 한 것들이 나오고, 반 정도는 꽤나 지엽적이고 코드나 구조를 깊게 파 본 사람만 알만한 문제가 나왔기 때문입니다. 예를 들어서 저는 django를 api 만드는데 많이 써서 template 관련해서는 잘 몰랐는데 template의 {% %} 요 태그 관련한 문제가 나와서 깜짝 놀랐습니다. python도 class의 method나 attribute 관련해서 묻는 간단한 질문이 있었다면 python이 돌아가는 작동원리를 묻는 문제도 있었습니다.
LinkedIn 실력평가에 대해 설명해 놓은 걸 보면 LinkedIn 온라인 클래스 전문가들이 문제를 냈기 때문에 신뢰할만하다고 하긴 하는데 아무데서나 볼 수 있어서 컨닝을 너무 쉽게 할 수 있는 허점이 있는게 아닌가 싶기도 합니다.
그리고 처음엔 시험을 볼 수 있는 기회가 두 번 주어지는데 탈락하면 3개월 이내에 동일한 시험을 볼 수 없게 된다고 합니다.
한 문제당 약 1~2분 정도 주는 것 같으니 굉장히 빠르게 볼 수 있어서 좋은 것 같고, python이나 django 말고도 html나 MS office들도 시험이 있을 정도로 많은 시험이 있으니 시간 남을 때 한 번 가볍게 풀어보시는 것도 추천드리고 싶습니다 :)
저번에 글을 쓸 때는 자신만만하게 '이렇게이렇게 해야한다!' 라고 말했지만 막상 만들어보려니까 assert문을 얼마나 넣어야할지 모르겠다는 생각이 들었다. 가장 작게 유닛테스트를 하는 것이 가장 기초이고, 유닛테스트부터 시작해봐야야 할 것 같다는 생각이 들었다.
먼저 가장 작게 하나의 함수나 메소드를 테스트하는 것이 가장 작은 유닛테스트가 될 것 같다. 기본적으로 내가 생각한 값이 나오는지 확인하고, 더 잘 확인하기 위해서는 어떤 범위가 나와야하는 함수라면 그 범위의 경계선도 체크하는 것도 중요하다고 알게 되었다.
그리고 최근에 Django를 이용해 api를 만드는 도중에 테스트 코드를 몇 개 짜봤는데 이런 프레임워크 안에는 단순히 python의 unittest를 사용하기엔 어려움이 있는 것 같고, 프레임워크 안에 test를 위해 만들어진 module이 있다면 그걸 사용하는 것이 맞는 것 같다. 왜냐하면 Django를 보았을 때 response를 테스트를 해야하는 것이 많은데 이걸 테스트하기 위해서 unittest를 쓰는 건 불가능하진 않지만 비효율적이고, django 또는 django rest framework 안의 test를 이용해야 client나 factory 이런 걸 활용해야 효율적으로 test 코드를 만들 수 있기 때문이다. 아래는 django, DRF의 test 코드 예시이다.
이렇게 말하고 있지만 뭘 만드는데 완벽하게 유닛테스트 코드를 짜고, 만들기엔 그렇게 큰 프로젝트를 맡고 있지 않기 때문에 간단하게 한 class에 대해 setuplcass, teardownclass 넣고, 그 다음 모든 method에 대해 하나 또는 소수의 assert문만 넣어 끝까지 오류 없이 돌아가는지 정도만 test를 하고 있다.
근데 사실 절대 버그가 생기면 안되거나 여러 곳에서 참조하는 모듈이 아니라면 완벽하게 unittest를 다 만들고 하는 하는 것보다 빠르게 ( 그리고 잘 ) 만들고 오류가 난다면 바로바로 고쳐주는 게 더 효율적이라고 생각한다...
입사 전에도 테스트코드를 짜보긴 했고, TDD(Test-Driven-Developement)라는 걸 들어보긴 했었다. 근데 이제 사수님이 TDD는 테스트코드를 먼저 짜보면서 코드를 작성하는 거라고 하시면서 한 번 해보라니까 감이 안 잡혔다. 그래서 한 번 TDD를 왜하는 거고, 어떻게 하는지 찾아보기로 했다.
그래서 TDD 왜 해야하는 거야?
전에 혼자 DRF를 이용해서 asset-dashboard라는 프로젝트를 혼자 진행했던 후기 글에서도 언급했듯이 점점 기획의 중요성을 느꼈다. 그래서 어떤 기획이 좋은 기획인가?를 찾아보면서 여러 글을 보았는데 그 중 이런 글귀가 있었다. "가설 베이스 사고를 하는 것이 논리적 사고를 하는데 있어서 중요하다. 늘 결론을 갖고 그에 대한 가설을 검증하는 방식으로 사고해야 한다" 이 글귀가 정확히 TDD가 가고자 하는 방향을 설명하는 것 같았다.
테스트코드를 먼저 짜므로서 가설을 설정하고, 내가 짠 코드로 그 가설을 검증하는 것이다.
그리고 이런 방향으로 개발하기 위해서는 "검증하고자 하는 가설은 무엇인가?" 이게 핵심 질문이였다. 즉, "테스트하고자 하는 것이 무엇인가"이다. 생각해보면 이전에 간단하게 테스트코드를 짤 때는 request를 날리고 requests.code.ok가 떴는지 이런걸 체크하기 위해 테스트코드를 짰었는데 이런게 무의식 중에 생각하게 되는 아주 작은 가설 ('내가 이렇게 request를 날리면 200이 올 것이다!") 중 하나였던 것 같다. "
이렇게 하면 테스트코드를 먼저 짜야하니까 미래에 일어날 버그들을 생각하게 되고, 코드부터 짜고 테스트를 하는 것보다 나중에 생길 버그나 개선해야 할 것들을 더 생각하게 되는 것 같았다. 그리고 결과적으로 모두가 원했던 버그는 줄고 코드는 간결해지는 clean code라는 목표에 다다르게 되는 것 같았다.
마지막으로 이런 이유로 TDD를 하는 것이고, TDD를 하면 미래에 유지보수하는 시간이 매우 줄 것이라고 생각한다. 그래서 기능이 많은 큰 프로젝트에서는 TDD가 중요할 것 같다. 근데 해보니까 TDD를 하면 개발하는 시간이 엄청나게 늘어 날 것 같다. 기획자와 의사소통이 많이 필요하니까... 그래서 프로토타입을 만들어서 기능을 실험해보거나 휘발성이 높은 코드를 짤 때는 엄청 필요할 것 같진 않아보였다.
그래서 TDD를 어떻게 해야하나...
위의 사진처럼 설계/기획하고, 테스트코드를 먼저 작성한 다음에 코드 개발을 하는 것이다. 그리고 더 나아가서 TDD 방식이란 테스트코드를 짜면서 발생하는 예외사항들을 계속 테스트케이스에 추가하면서 설계를 개선하고 마지막에 테스트를 통과한 코드만 실제 코드로 작성하는 방식이라고 한다. 이론적으론 그렇다... :)
사실 이런 부분은 ' 아 그렇구나... 일단 이렇게 해야하는 거 같다...' 이렇게 감을 잡고 하다보면 아 '왜 이런 방식으로 하라고 가르쳐주셨구나...' 라는 걸 더 느끼게 되는 것 같다. 그래서 회사 내부에서 누군가 unittest로 짜놓은 test코드를 보면서 공부하고, 이전에 써보았던 pytest도 생각하면서 일단 어떻게든 해보고 있다. 꼭 알아두면 좋은 setup, setupclass나 teardown, teardownclass와 더불어서 @patch 이런 것도 다음에 글 쓰면서 정리해봐야겠다.