유닛 테스트는 프로젝트에서 중요한 역할을 한다. 각 기능이 올바르게 동작하는지 확인하고, 코드의 변경이 기존 기능에 부정적은 영향을 미치진 않았는지 학인 및 기존 코드의 동작을 보장해 준다. 일반적으로 Django의 유닛 테스트는 별도의 테스트 데이터 베이스를 사용하여 진행되지만 개인적으로 불편하고 데이터 베이스 없이 테스트를 수행하는 것이 더 효율적일 수도 있다는 이야기가 있어서 진행해 보았다. TEST DB를 사용하지 않았을 때의 장점속도 향상 - 데이터베이스 없이 테스트를 실행하면 테스트 속도가 향상된다.환경 구성 단순화 - 별도의 데이터베이스 구성이 필요 없어, 테스트 환경을 쉽게 설정할 수 있다.데이터 베이스의 독립성 - 데이터베이스 의존성 없이 테스트를 구성함으로써 독립적인 단위 효과를 효과..
BackEnd/Django, DRF
API호출을 하면서 발생할 수 있는 문제중 하나로 CORS 관련 문제가 있다. CORS에 대한 개념 뿐만아니라 안전하게 설정하고 테스트하는 방법을 알고 있어야한다. CORS에 대한 개념 및 DRF에서 설정하는 방법에 대해서는 여러 공식문서 외에도 블로그 글로 잘 정리되어 있었는데, 잘 적용되었는지 테스트하는 방법에 대해서는 자세히 안나와 있고, 프로젝트를하면서 cors에러가 발생해서 어떻게해서 해결했다. 라는 글만 있어서 직접 삽질하면서 알아낸 방법에 대해서도 이야기 해보려고한다. CORS란?개념에 관해서는 자세히 정리된 글이 있어 굳이 따로 정리하진 않았지만 CORS를 간단히 설명하자면, 웹 페이지가 다른 도메인의 리소스에 접근할 수 있도록 허용하는 보안 기능이다. 브라우저는 보안 상의 이유로 스크..
Response에 이어서 exception_handler를 이용하여 기본 예외 포맷이나 응답 구조를 사용자화 하려고한다. 들어가기에 앞서 exception_handler란 무엇인가?'exception_handler'는 DRF의 예외처리 기능으로 API에서 발생한 예외를 처리하고 사용자 지정 응답을 생성하는 역할을 한다. 기본적으로 exception_handler를 사용하여 예외처리를해도 아무런 문제가 없지만 이를 재정의해서 사용자 지정 로직을 적용시켜 보려고한다. 예외처리를 커스터마이징 하기 위한 절차로는1. exception_handler를 재 정의한다.2. 예외를 처리하고 사용자 지정 응답을 생성하는 로직을 구현한다.3. 설정 파일에서 재정의한 핸들러를 등록한다. 아래는 1번 exception_han..
지난 Renderer에 이어서 Custom Response를 구현한 내용에 대해 작성해 보려고한다. 먼저 이야기하자면, Response를 구현하는것은 어렵지 않았지만, renderer과 response를 커스터마이징해서 구현했는데 data가 중복되어 매핑되는 문제가 생겼었다. 이런 저런 방법을 사용하고 수정해봐도 2번 매핑이되어서 settings에서 renderer 디폴트값을 주석처리해두고 진행하였다. 추후 알게된 사실은 Response 클래스는 renderer 메서드를 내부적으로 호출하고 있기 때문에 하나만 사용하면 되는 것이였다. 그럼 둘의 차이점은 무엇일까?우선 Response는 응답 객체를 생성할때마다 해당 클래스를 인스턴스화 하여 사용해야한다. 즉, 생성할때마다 Response 객체를 만들어줘..
DRF는 Django를 이용하여 API를 쉽게 만들 수 있도록 도와주는 프레임워크이다. 다른 프레임워크나 언어에 비해 배우기 쉽다는 장점이 있어 많은 사람들이 처음 시작하는데 자주 사용하는데 조금만 깊게 공부를 하면 할수록 커스텀이 필요하다는 말을 들었다. 특정 프로젝트에서는 요구사항에 맞게 JSONRenderer를 커스터마이징해서 사용해야 할 경우도 생긴다고 한다. 이번 포스트에서는 DRF에서의 JSONRenderer를 커스터마이징 하는 방법에 대해서 작성해 보려고 한다.DRF의 기본적인 Response의 경우에는 왼쪽 사진처럼, 커스터마이징한 결과는 오른쪽처럼 표시가 되도록 하려고 한다.우선 rest_framework.renderers에서 JSONRenderer를 상속받아 오버라이딩해 주었다.# c..
