[DRF] 공식 문서 - Testing 정리
1. Testing
- REST 프레임워크는 Django의 기존 테스트 프레임워크를 확장하고 API 요청을 보다 효과적으로 지원하는 몇 가지 도우미 클래스를 포함하고 있다.
2. APIRequestFactory
- Django의 기존 RequestFactory 클래스를 확장한다.
- Django's existing RequestFactory class : https://docs.djangoproject.com/en/stable/topics/testing/advanced/#django.test.client.RequestFactory
1) 테스트 요청 생성(Creating test requests)
- APIRequestFactory 클래스는 Django의 표준 RequestFactory 클래스와 거의 동일한 API를 지원한다. 이는 표준 .get(), .post(), .put(), .patch(), .delete(), .head(), .options() 메소드 모두 사용 가능하다는 것을 의미한다.
from rest_framework.test import APIRequestFactory
# Using the standard RequestFactory API to create a form POST request
factory = APIRequestFactory()
request = factory.post('/notes/', {'title': 'new idea'})
1. Using the format argument
- post, put, patch와 같이 요청 본문을 생성하는 메소드에는 format 인자가 포함되어 있어, multipart form data 이외의 콘텐츠 타입을 사용하여 요청을 생성하는 것을 쉽게 만든다.
# Create a JSON POST request
factory = APIRequestFactory()
request = factory.post('/notes/', {'title': 'new idea'}, format='json')
- 기본적으로 사용 가능한 형식은 'multipart'와 'json'이다. Django의 기존 RequestFactory와의 호환성을 위해 기본 형식은 'multipart'이다.
- 더 넓은 범위의 요청 형식을 지원하거나 기본 형식을 변경하려면, 구성 섹션을 참조하면 된다.
- see the configuration section : https://www.django-rest-framework.org/api-guide/testing/#configuration
2. 요청 본문을 명시적으로 인코딩하기(Explicitly encoding the request body)
- 요청 본문을 명시적으로 인코딩해야 하는 경우, content_type 플래그를 설정함으로써 그렇게 할 수 있다.
request = factory.post('/notes/', json.dumps({'title': 'new idea'}), content_type='application/json')
3. PUT and PATCH with form data
- Django의 RequestFactory와 REST 프레임워크의 APIRequestFactory 사이에 주목할 만한 차이점 중 하나는 multipart form data가 .post() 외의 메소드에 대해서도 인코딩이 되는 것이다.
- 예를 들어, APIRequestFactory를 사용하여 다음과 같이 form PUT 요청을 만들 수 있다.
factory = APIRequestFactory()
request = factory.put('/notes/547/', {'title': 'remember to email dave'})
- Django의 RequestFactory를 사용하면, 데이터를 직접 명시적으로 인코딩해야 한다.
from django.test.client import encode_multipart, RequestFactory
factory = RequestFactory()
data = {'title': 'remember to email dave'}
content = encode_multipart('BoUnDaRyStRiNg', data)
content_type = 'multipart/form-data; boundary=BoUnDaRyStRiNg'
request = factory.put('/notes/547/', content, content_type=content_type)
2) 강제 인증(Forcing authentication)
- 요청 팩토리를 사용하여 뷰를 직접 테스트할 때, 올바른 인증 자격 증명을 구성하는 것보다 요청을 직접 인증하는 것이 종종 편리하다.
- 요청을 강제로 인증하려면, force_authenticate() 메소드를 사용하면 된다.
from rest_framework.test import force_authenticate
factory = APIRequestFactory()
user = User.objects.get(username='olivia')
view = AccountDetail.as_view()
# Make an authenticated request to the view...
request = factory.get('/accounts/django-superstars/')
force_authenticate(request, user=user)
response = view(request)
- 메소드의 서명은 force_authenticate(request, user=None, token=None)이다. 호출을 할 때, user와 token 둘 중 하나 또는 둘 다 설정할 수 있다.
- 예를 들어, 토큰을 사용하여 강제 인증을 할 때, 다음과 같이 할 수 있다.
user = User.objects.get(username='olivia')
request = factory.get('/accounts/django-superstars/')
force_authenticate(request, user=user, token=user.auth_token)
- 참고: force_authenticate는 request.user를 메모리 내 사용자 인스턴스로 직접 설정한다. 저장된 사용자 상태를 업데이트하는 여러 테스트에서 동일한 사용자 인스턴스를 재사용하는 경우, 테스트 사이에 refresh_from_db()를 호출해야 할 수 있다.
- 참고: APIRequestFactory를 사용할 때 반환되는 객체는 Django의 표준 HttpRequest이며, 뷰가 호출되면서만 생성되는 REST 프레임워크의 Request 객체가 아니다.
- 이는 요청 객체에 직접 속성을 설정하는 것이 항상 예상하는 효과를 가져오지 않을 수 있다는 것을 의미한다. 예를 들어, .token을 직접 설정하면 효과가 없으며, .user를 직접 설정하는 것은 세션 인증이 사용되는 경우에만 작동한다.
# Request will only authenticate if `SessionAuthentication` is in use.
request = factory.get('/accounts/django-superstars/')
request.user = user
response = view(request)
3) CSRF 강제 인증(Forcing CSRF validation)
- 기본적으로, APIRequestFactory로 생성된 요청은 REST 프레임워크 뷰로 전달될 때 CSRF 검증이 적용되지 않는다. CSRF 검증을 명시적으로 켜야 하는 경우, 팩토리를 인스턴스화할 때 enforce_csrf_checks 플래그를 설정하여 그렇게 할 수 있다.
factory = APIRequestFactory(enforce_csrf_checks=True)
- 참고: Django의 표준 RequestFactory는 일반 Django를 사용할 때 CSRF 검증이 미들웨어에서 이루어지기 때문에 이 옵션을 포함할 필요가 없다는 점을 주목해야 한다. 뷰를 직접 테스트할 때 미들웨어는 실행되지 않는다. REST 프레임워크를 사용할 때, CSRF 검증은 뷰 내부에서 이루어지므로, 요청 팩토리는 뷰 수준의 CSRF 검사를 비활성화해야 한다.
3. APIClient
- Django의 기존 Client 클래스를 확장한다.
- Django's existing Client class : https://docs.djangoproject.com/en/5.0/topics/testing/tools/#the-test-client
1) 요청 생성(Making requests)
- APIClient 클래스는 Django의 표준 Client 클래스와 동일한 요청 인터페이스를 지원한다. 이는 표준 .get(), .post(), .put(), .patch(), .delete(), .head(), .options() 메소드 모두 사용 가능하다는 것을 의미한다.
from rest_framework.test import APIClient
client = APIClient()
client.post('/notes/', {'title': 'new idea'}, format='json')
- 더 넓은 범위의 요청 형식을 지원하거나 기본 형식을 변경하려면, 구성 섹션을 참조하면 된다.
- see the configuration section : https://www.django-rest-framework.org/api-guide/testing/#configuration
2) Authenticating
1. .login(**kwargs)
- .login(**kwargs)login 메소드는 Django의 일반 Client 클래스와 정확히 동일하게 작동한다. 이를 통해 SessionAuthentication을 포함하는 모든 뷰에 대해 요청을 인증할 수 있다.
# Make all requests in the context of a logged in session.
client = APIClient()
client.login(username='lauren', password='secret')
- 로그아웃하려면, 평소와 같이 logout 메소드를 호출하면 된다.
# Log out
client.logout()
- login 메소드는 세션 인증을 사용하는 API를 테스트하는 데 적합하다. 예를 들어, API와 AJAX 상호 작용을 포함하는 웹 사이트를 테스트하는 데 사용할 수 있다.
2. .credentials(**kwargs)
- credentials 메소드는 테스트 클라이언트에 의한 모든 후속 요청에 포함될 헤더를 설정하는 데 사용할 수 있다.
from rest_framework.authtoken.models import Token
from rest_framework.test import APIClient
# Include an appropriate `Authorization:` header on all requests.
token = Token.objects.get(user__username='lauren')
client = APIClient()
client.credentials(HTTP_AUTHORIZATION='Token ' + token.key)
- credentials를 두 번 호출하면 기존의 자격 증명이 덮어쓰여진다는 점에 유의하자. 아무 인자도 없이 메소드를 호출함으로써 기존의 자격 증명을 해제할 수 있다.
# Stop including any credentials
client.credentials()
- credentials 메소드는 기본 인증, OAuth1a 및 OAuth2 인증, 간단한 토큰 인증 체계와 같이 인증 헤더를 필요로 하는 API를 테스트하는 데 적합하다.
3. .force_authenticate(user=None, token=None)
- 간혹 테스트 클라이언트의 모든 요청을 자동으로 인증된 것으로 간주하고 인증 과정을 우회하고 싶을 수 있다.
- API를 테스트하고 있지만 테스트 요청을 만들기 위해 유효한 인증 자격 증명을 생성해야 하는 번거로움을 피하고 싶다면, 이는 유용한 단축 경로가 될 수 있다.
user = User.objects.get(username='lauren')
client = APIClient()
client.force_authenticate(user=user)
- 이후의 요청을 인증 해제하려면, user와/또는 token을 None으로 설정하여 force_authenticate를 호출하면 됩니다.
client.force_authenticate(user=None)
3) CSRF validation
- 기본적으로 APIClient를 사용할 때 CSRF 검증이 적용되지 않는다. CSRF 검증을 명시적으로 활성화해야 하는 경우, 클라이언트를 인스턴스화할 때 enforce_csrf_checks 플래그를 설정하여 그렇게 할 수 있다.
client = APIClient(enforce_csrf_checks=True)
- 평소와 같이 CSRF 검증은 세션 인증된 뷰에만 적용됩니다. 이는 클라이언트가 login()을 호출하여 로그인된 경우에만 CSRF 검증이 발생한다는 것을 의미한다.
4. RequestsClient
- REST 프레임워크는 또한 인기 있는 Python 라이브러리인 requests를 사용하여 애플리케이션과 상호 작용하는 클라이언트도 포함하고 있다. 이는 다음과 같은 경우 유용할 수 있다.
- 주로 다른 Python 서비스에서 API와 인터페이스를 할 것으로 예상하고, 클라이언트가 볼 수 있는 수준에서 서비스를 테스트하려는 경우.
- 테스트를 스테이징이나 라이브 환경에 대해서도 실행할 수 있도록 작성하려는 경우. (아래의 "Live tests" 참조)
- 이는 마치 직접 requests 세션을 사용하는 것과 정확히 동일한 인터페이스를 제공한다.
from rest_framework.test import RequestsClient
client = RequestsClient()
response = client.get('http://testserver/users/')
assert response.status_code == 200
- requests 클라이언트는 완전히 정규화된 URL을 전달해야 한다는 점에 유의해야 한다.
1) RequestsClient and working with the database
- RequestsClient 클래스는 서비스 인터페이스와만 상호 작용하는 테스트를 작성하려는 경우 유용하다. 이는 모든 상호 작용이 API를 통해 이루어져야 한다는 점에서 표준 Django 테스트 클라이언트를 사용하는 것보다 약간 더 엄격하다.
- RequestsClient를 사용하는 경우 테스트 설정과 결과 확인을 데이터베이스 모델과 직접 상호 작용하는 대신 일반 API 호출로 수행해야 한다. 예를 들어, Customer.objects.count() == 3이라고 확인하는 대신 고객 엔드포인트를 나열하고 세 개의 레코드가 포함되어 있는지 확인해야 한다.
- 예시
from django.urls import reverse
from rest_framework import status
from rest_framework.test import APIClient
# 테스트를 위한 RequestsClient 생성
client = APIClient()
# 테스트에 사용할 가상 데이터
data = {
'name': 'John Doe',
'email': 'johndoe@example.com',
'age': 30
}
# 가상의 Customer 생성을 위한 엔드포인트 URL
create_customer_url = reverse('customer-list')
# 가상의 Customer 목록 조회를 위한 엔드포인트 URL
list_customers_url = reverse('customer-list')
def test_create_customer():
# POST 요청을 통해 가상의 Customer 생성
response = client.post(create_customer_url, data, format='json')
# 응답 상태 코드 확인
assert response.status_code == status.HTTP_201_CREATED
# 응답 데이터 확인
assert response.data['name'] == data['name']
assert response.data['email'] == data['email']
assert response.data['age'] == data['age']
def test_list_customers():
# GET 요청을 통해 가상의 Customer 목록 조회
response = client.get(list_customers_url)
# 응답 상태 코드 확인
assert response.status_code == status.HTTP_200_OK
# 응답 데이터 확인
assert len(response.data) == 1 # 생성한 Customer가 1개인지 확인
def test_update_customer():
# 가상의 Customer 생성
response = client.post(create_customer_url, data, format='json')
customer_id = response.data['id']
# PUT 요청을 통해 가상의 Customer 업데이트
updated_data = {
'name': 'Jane Smith',
'email': 'janesmith@example.com',
'age': 35
}
update_customer_url = reverse('customer-detail', args=[customer_id])
response = client.put(update_customer_url, updated_data, format='json')
# 응답 상태 코드 확인
assert response.status_code == status.HTTP_200_OK
# 응답 데이터 확인
assert response.data['name'] == updated_data['name']
assert response.data['email'] == updated_data['email']
assert response.data['age'] == updated_data['age']
def test_delete_customer():
# 가상의 Customer 생성
response = client.post(create_customer_url, data, format='json')
customer_id = response.data['id']
# DELETE 요청을 통해 가상의 Customer 삭제
delete_customer_url = reverse('customer-detail', args=[customer_id])
response = client.delete(delete_customer_url)
# 응답 상태 코드 확인
assert response.status_code == status.HTTP_204_NO_CONTENT
# Customer가 실제로 삭제되었는지 확인
response = client.get(list_customers_url)
assert len(response.data) == 0 # Customer가 더 이상 존재하지 않는지 확인
- 이 코드는 DRF의 testing을 위한 가상 시나리오를 제공한다. test_create_customer() 함수는 가상의 Customer를 생성하고 응답 데이터를 확인한다.
- test_list_customers() 함수는 가상의 Customer 목록을 조회하고, 생성한 Customer가 목록에 포함되는지 확인한다. - test_update_customer() 함수는 가상의 Customer를 업데이트하고 업데이트된 데이터를 확인한다.
- test_delete_customer() 함수는 가상의 Customer를 삭제하고 삭제된 Customer가 목록에 더 이상 존재하지 않는지 확인한다.
- 이 코드를 실행하면 가상의 API 호출을 통해 테스트를 수행할 수 있다. 이때, 데이터베이스 모델에 직접 접근하는 것이 아니라 API 엔드포인트를 통해 테스트를 수행하는 점에 유의할 필요가 있다.
2) Headers & Authentication
- 표준 requests.Session 인스턴스를 사용할 때와 동일한 방식으로 사용자 정의 헤더와 인증 자격 증명을 제공할 수 있다.
from requests.auth import HTTPBasicAuth
client.auth = HTTPBasicAuth('user', 'pass')
client.headers.update({'x-test': 'true'})
3) CSRF
- 표준 requests.Session 인스턴스를 사용할 때와 동일한 방식으로 사용자 정의 헤더와 인증 자격 증명을 제공할 수 있다. SessionAuthentication을 사용하는 경우 POST, PUT, PATCH 또는 DELETE 요청에 CSRF 토큰을 포함해야 한다.
- JavaScript 기반 클라이언트가 사용하는 것과 동일한 흐름을 따라 이를 수행할 수 있다. 먼저, CSRF 토큰을 얻기 위해 GET 요청을 만든 다음, 그 토큰을 다음 요청에 제시한다.
client = RequestsClient()
# Obtain a CSRF token.
response = client.get('http://testserver/homepage/')
assert response.status_code == 200
csrftoken = response.cookies['csrftoken']
# Interact with the API.
response = client.post('http://testserver/organisations/', json={
'name': 'MegaCorp',
'status': 'active'
}, headers={'X-CSRFToken': csrftoken})
assert response.status_code == 200
4) Live tests
- 주의 깊게 사용하면 RequestsClient와 CoreAPIClient 모두 개발 중이거나 스테이징 서버 또는 프로덕션 환경에 직접 실행될 수 있는 테스트 케이스를 작성할 수 있다.
- 이 스타일을 사용하여 몇 가지 핵심 기능의 기본 테스트를 생성하는 것은 실제 서비스를 검증하는 강력한 방법이다. 이렇게 하려면 테스트가 고객 데이터에 직접 영향을 주지 않는 방식으로 실행되도록 설정과 해제에 주의를 기울여야 할 수 있다.
5. CoreAPIClient
- CoreAPIClient를 사용하면 Python coreapi 클라이언트 라이브러리를 사용하여 API와 상호 작용할 수 있다.
# Fetch the API schema
client = CoreAPIClient()
schema = client.get('http://testserver/schema/')
# Create a new organisation
params = {'name': 'MegaCorp', 'status': 'active'}
client.action(schema, ['organisations', 'create'], params)
# Ensure that the organisation exists in the listing
data = client.action(schema, ['organisations', 'list'])
assert(len(data) == 1)
assert(data == [{'name': 'MegaCorp', 'status': 'active'}])
1) Headers & Authentication
- 사용자 정의 헤더와 인증은 RequestsClient와 유사한 방식으로 CoreAPIClient와 함께 사용될 수 있다.
from requests.auth import HTTPBasicAuth
client = CoreAPIClient()
client.session.auth = HTTPBasicAuth('user', 'pass')
client.session.headers.update({'x-test': 'true'})
6. API Test cases
- 사용자 정의 헤더와 인증은 RequestsClient와 유사한 방식으로 CoreAPIClient와 함께 사용될 수 있다. REST 프레임워크는 Django의 기본 Client 대신 APIClient를 사용하는 다음의 테스트 케이스 클래스를 포함하고 있다. 이들 클래스는 Django의 기존 테스트 케이스 클래스를 반영한다.
- Django's test case classes : https://docs.djangoproject.com/en/5.0/topics/testing/tools/#provided-test-case-classes
- APISimpleTestCase :
- APISimpleTestCase는 Django의 기본 SimpleTestCase를 확장한 클래스로, 단위 테스트를 위한 가장 기본적인 테스트 케이스이다. 이 클래스는 REST framework의 API 테스트를 위한 특수한 기능을 제공하지는 않는다. 따라서 간단한 API 테스트나 독립적인 테스트 케이스를 작성할 때 사용된다. 이 클래스는 데이터베이스 접근을 하지 않으므로 테스트의 실행 속도가 빠르고, 데이터베이스 상태에 영향을 주지 않는다.
- APITransactionTestCase :
- APITransactionTestCase는 Django의 TestCase 클래스를 확장한 클래스이다. 이 클래스는 데이터베이스 트랜잭션을 사용하여 테스트를 수행한다. 각 테스트 메서드는 테스트 시작 전에 데이터베이스를 초기 상태로 되돌리고, 테스트가 끝난 후에는 롤백하여 테스트 이전의 상태를 복원한다. 이를 통해 테스트 간의 데이터 상호작용을 격리시킬 수 있다. 데이터베이스 트랜잭션을 사용하기 때문에 테스트 시간이 더 오래 걸릴 수 있다.
- APITestCase :
- APITestCase는 APITransactionTestCase를 확장한 클래스로, REST framework의 API 테스트를 위한 특수한 기능을 제공한다. APITestCase는 데이터베이스 트랜잭션을 사용하여 테스트를 수행하며, REST framework의 API 테스트 유틸리티 함수와 테스트 클라이언트를 사용할 수 있다. 이 클래스는 REST framework의 기능을 활용하여 API 요청을 보내고 응답을 검증하는 테스트를 작성하는 데 유용하다.
1. API 테스트 유틸리티 함수:
- self.client: 테스트 클라이언트 객체로, REST framework의 API 요청을 보내고 응답을 검증하는 데 사용된다.
- self.get(), self.post(), self.put(), self.patch(), self.delete(): 각각 GET, POST, PUT, PATCH, DELETE 메서드를 사용하여 API 요청을 보내고 응답을 검증한다.
- self.assertContains(), self.assertNotContains(): 응답 내용에 특정 문자열이 포함되어 있는지 여부를 검증한다.
- self.assertEqual(), self.assertNotEqual(): 응답 상태 코드, 응답 헤더, 응답 데이터와 기대값을 비교하여 검증한다.
- 기타 다양한 유틸리티 함수: self.assert...() 형태로 다양한 검증 메서드를 제공한다.
2. 인증과 권한 관련 기능:
- self.force_authenticate(user): 특정 사용자로 인증된 상태로 API 요청을 보낼 수 있다.
- self.client.login(username=username, password=password): Django의 기본 인증 시스템을 사용하여 사용자로 로그인할 수 있다.
- self.client.logout(): 사용자 로그아웃을 수행한다.
- self.client.force_authenticate(user=None): 인증된 사용자를 로그아웃 상태로 만든다.
3. 시리얼라이저 검증:
- self.serializer_class: 테스트에서 사용할 시리얼라이저 클래스를 정의할 수 있다. 이를 통해 API 요청과 응답의 시리얼라이저 검증을 수행할 수 있다.
4. 테스트 데이터 관리:
- self.setUp(), self.tearDown(): 각 테스트 메서드 실행 전후에 실행되는 메서드로, 테스트 데이터의 설정 및 정리를 담당한다.
- APILiveServerTestCase :
- APILiveServerTestCase는 APITransactionTestCase를 확장한 클래스로, 실제 서버와 통신하는 통합 테스트를 위해 사용됩니다. 이 클래스는 가상의 개발 서버를 실행하고, 테스트 클라이언트를 사용하여 실제 HTTP 요청을 보내고 응답을 검증한다. 이를 통해 실제 서버 환경에서 동작하는 API의 테스트를 수행할 수 있다. APILiveServerTestCase는 테스트 시간이 오래 걸리고, 실제 서버 환경을 구성해야 하므로 테스트 환경을 설정하는 데 추가 작업이 필요하다.
1. 실제 개발 서버 사용:
- APILiveServerTestCase는 테스트를 실행할 때 실제로 개발 서버를 실행하고 사용한다. 이를 통해 실제 환경과 유사한 상황에서 API를 테스트할 수 있다.
- 개발 서버는 임시 포트 번호를 할당하여 실행되며, 다른 테스트 케이스와 격리된 환경에서 실행된다.
2. 동작 방식:
- APILiveServerTestCase는 개발 서버를 시작하고 테스트 메서드를 실행하기 전에 setUpClass() 메서드에서 서버를 설정하고 시작한다.
- 테스트 메서드는 개발 서버의 URL을 사용하여 API 요청을 보내고 응답을 검증한다.
- 테스트가 완료되면 tearDownClass() 메서드에서 개발 서버를 종료한다.
3. 테스트 환경 설정:
- self.live_server_url: 현재 실행 중인 개발 서버의 기본 URL을 나타냅니다. self.live_server_url을 사용하여 API 요청의 URL을 구성할 수 있다.
- self.client: 테스트 클라이언트 객체로, 개발 서버의 API 요청을 보내고 응답을 검증하는 데 사용된다.
- self.get(), self.post(), self.put(), self.patch(), self.delete(): 각각 GET, POST, PUT, PATCH, DELETE 메서드를 사용하여 API 요청을 보내고 응답을 검증한다.
4. 데이터베이스 트랜잭션:
- APILiveServerTestCase는 APITransactionTestCase를 확장하므로, 데이터베이스 트랜잭션을 사용하여 각 테스트 메서드 실행 전후에 데이터베이스를 초기화한다.
- 이는 각 테스트가 독립적으로 실행되며 데이터베이스 상태가 서로 영향을 주지 않도록 한다.
1) Example
- 일반 Django 테스트 케이스 클래스와 마찬가지로 REST 프레임워크의 테스트 케이스 클래스를 사용할 수 있다. self.client 속성은 APIClient 인스턴스가 될 것이다.
from django.urls import reverse
from rest_framework import status
from rest_framework.test import APITestCase
from myproject.apps.core.models import Account
class AccountTests(APITestCase):
def test_create_account(self):
"""
Ensure we can create a new account object.
"""
url = reverse('account-list')
data = {'name': 'DabApps'}
response = self.client.post(url, data, format='json')
self.assertEqual(response.status_code, status.HTTP_201_CREATED)
self.assertEqual(Account.objects.count(), 1)
self.assertEqual(Account.objects.get().name, 'DabApps')
7. URLPatternsTestCase
- REST 프레임워크는 또한 urlpatterns를 클래스별로 격리하기 위한 테스트 케이스 클래스를 제공한다. 이는 Django의 SimpleTestCase에서 상속받으며, 대부분 다른 테스트 케이스 클래스와 혼합해야 한다.
1) Example
from django.urls import include, path, reverse
from rest_framework.test import APITestCase, URLPatternsTestCase
class AccountTests(APITestCase, URLPatternsTestCase):
urlpatterns = [
path('api/', include('api.urls')),
]
def test_create_account(self):
"""
Ensure we can create a new account object.
"""
url = reverse('account-list')
response = self.client.get(url, format='json')
self.assertEqual(response.status_code, status.HTTP_200_OK)
self.assertEqual(len(response.data), 1)
8. Testing responses
1) Checking the response data
- REST 프레임워크는 또한 urlpatterns를 클래스별로 격리하기 위한 테스트 케이스 클래스를 제공한다. 이는 Django의 SimpleTestCase에서 상속받으며, 대부분 다른 테스트 케이스 클래스와 혼합해야 한다. 테스트 응답의 유효성을 확인할 때, 완전히 렌더링된 응답을 검사하는 것보다 응답이 생성된 데이터를 검사하는 것이 종종 더 편리하다.
- 예를 들어, response.data를 검사하는 것이 더 쉽다.
response = self.client.get('/users/4/')
self.assertEqual(response.data, {'id': 4, 'username': 'lauren'})
- response.content의 파싱 결과를 검사하는 대신에,
response = self.client.get('/users/4/')
self.assertEqual(json.loads(response.content), {'id': 4, 'username': 'lauren'})
2) Rendering responses
- APIRequestFactory를 사용하여 뷰를 직접 테스트하는 경우, 반환되는 응답은 아직 렌더링되지 않는다. 템플릿 응답의 렌더링은 Django의 내부 요청-응답 사이클에 의해 수행된다. 따라서 response.content에 접근하려면 먼저 응답을 렌더링해야 한다.
view = UserDetail.as_view()
request = factory.get('/users/4')
response = view(request, pk='4')
response.render() # Cannot access `response.content` without this.
self.assertEqual(response.content, '{"username": "lauren", "id": 4}')
9. Configuration
1) Setting the default format
- 테스트 요청을 만드는 데 사용되는 기본 형식은 TEST_REQUEST_DEFAULT_FORMAT 설정 키를 사용하여 설정할 수 있다. 예를 들어, 테스트 요청에 대해 기본적으로 표준 멀티파트 폼 요청 대신 JSON을 항상 사용하려면 settings.py 파일에 다음을 설정하면 된다.
REST_FRAMEWORK = {
...
'TEST_REQUEST_DEFAULT_FORMAT': 'json'
}
2) 사용 가능한 형식 설정(Setting the available formats)
- multipart 또는 json 요청 이외의 것을 사용하여 요청을 테스트해야 하는 경우, TEST_REQUEST_RENDERER_CLASSES 설정을 설정할 수 있다.
- 예를 들어, 테스트 요청에서 format='html'을 사용하는 지원을 추가하려면, settings.py 파일에 다음과 같은 내용을 가질 수 있다.
REST_FRAMEWORK = {
...
'TEST_REQUEST_RENDERER_CLASSES': [
'rest_framework.renderers.MultiPartRenderer',
'rest_framework.renderers.JSONRenderer',
'rest_framework.renderers.TemplateHTMLRenderer'
]
}
- 공식 사이트 문서 : https://www.django-rest-framework.org/api-guide/testing/
Testing - Django REST framework
www.django-rest-framework.org
'Django REST Framework > DRF 일반' 카테고리의 다른 글
| [DRF] 공식 문서 - Throttling 정리 (1) | 2024.01.22 |
|---|---|
| [DRF] 공식 문서 - Exceptions 정리 (0) | 2024.01.22 |
| [DRF] 공식 문서 - Settings 정리 (0) | 2024.01.21 |
| [DRF] 공식 문서 - Permissions 정리 (0) | 2024.01.20 |
| [DRF] 공식 문서 - Authentication 정리 (0) | 2024.01.19 |
댓글