튜토리얼 이어서
- 5장을 보고 6장을 이어가길 바란다. 공식 문서 튜토리얼에 내 입맛과 부족한 정보를 담아서 정리하는 것에 가깝다.
완성된 것을 테스트하는 것도 개발의 일부이다. 사용자 테스트, 단위 테스트(Unit test) 등의 많은 테스트 단위가 있다. Junit, Jest 등의 라이브러리도 존재한다. Django에서는 어떻게 그런 테스트를 진행하는지 살펴보자.
- 단위 테스트는 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 절차다. 즉, 모든 함수와 메소드에 대한 테스트 케이스(Test case)를 작성하는 절차를 말한다. 이를 통해서 언제라도 코드 변경으로 인해 문제가 발생할 경우, 단시간 내에 이를 파악하고 바로 잡을 수 있도록 해준다. 이상적으로, 각 테스트 케이스는 서로 분리되어야 한다. 이를 위해 가짜 객체(Mock object)를 생성하는 것도 좋은 방법이다.
Django 자동화 테스트
-
테스트는 다양한 수준에서 작동합니다. 일부 테스트는 작은 세부 사항에 적용될 수 있습니다 (특정 모델 메서드는 예상대로 값을 반환합니까?) 또 다른 테스트는 소프트웨어의 전반적인 작동을 검사합니다 (사이트에서 사용자 입력 시퀀스가 원하는 결과를 생성합니까?). 이것은 이전 튜토리얼 2장에서 shell을 사용하여 메소드의 동작을 검사하거나 애플리케이션을 실행하고 어떻게 작동하는지 확인하기 위해 데이터를 입력해서 테스트했던 것과 다르지 않습니다.
-
자동화 된 테스트에서 다른 점은 테스트 작업이 시스템에서 수행된다는 것입니다. 한 번 테스트 세트를 작성한 이후에는 앱을 변경할 때 수동 테스트를 수행하지 않아도 원래 의도대로 코드가 작동하는지 확인할 수 있습니다.
테스트하는 이유
-
아마 당신은 Python/Django를 배우는 것 만으로도 충분하다고 느낄수 있고 또 다른것을 배우고 써보는것은 지나치거나 불필요해 보일수 있습니다. 어쨋든 간에 우리의 설문조사 어플리케이션은 지금 꽤 잘 돌아고 있습니다. 문제들을 해쳐 나가며 자동화된 테스트를 만드는게 이 어플리케이션을 작동하게 하거나 더 좋게 하지는 않습니다.
-
만약 투표 어플리케이션을 만드는게 Django 프로그래밍의 최종 단계라면, 자동화된 테스트를 어떻게 만드는지 알 필요는 없습니다. 하지만 아직 더 많은것을 하려 한다면 지금이 자동화된 테스트 작성을 배우기 딱 좋은 시간입니다.
테스트를 통해 시간을 절약 할 수 있습니다.
-
특정 시점까지는 〈제대로 작동하는지 확인〉 하는것이 테스트로서 충분할 것 입니다. 더 정교한 어플리케이션에서는 구성 요소간에 수십 개의 복잡한 상호 작용이있을 수 있습니다.
-
수동 테스트 작업을 자동화된 테스트가 몇초만에 해낼수 있다면 귀한시간을 많이 아낄수 있겠죠?. 무언가가 잘못되어도 테스트를 통해 예기치 않은 동작을 일으키는 코드를 식별하는 데 도움이됩니다.
-
때로는 코드가 제대로 작동하고 있음을 알 때 테스트를 작성하는 것은 허드렛일로 보여서 당신의 생산적이고 창의적인 프로그래밍 작업에서 떠나 매력적이지도 흥분되지도 않는 테스트 작성이라는 일을 하는게 어려울수도 있습니다. 그러나 테스트를 작성하는 작업은 어플리케이션을 수동으로 테스트하거나 새로 발견된 문제의 원인을 확인하는 데 많은 시간을 투자하는 것보다 훨씬 더 효과적입니다.
테스트는 문제를 그저 식별하는 것이 아니라 예방합니다.
-
테스트를 그저 개발의 부정적 측면으로 생각하는 것은 실수입니다. 테스트가 없으면 어플리케이션의 목적 또는 의도 된 동작이 다소 불투명 할 수 있습니다. 심지어 자신의 코드 일 때도, 정확히 무엇을하고 있는지 알아 내려고 노력하게 됩니다.
-
테스트는 이 불투명함을 바꿉니다. 그들은 내부에서 코드를 밝혀 내고, 어떤 것이 잘못 될 때, 그것이 잘못되었다는 것을 깨닫지 못했다고 할지라도, 잘못된 부분에 빛을 집중시킵니다.
테스트가 코드를 더 매력적으로 만듭니다.
- 테스트 작성을 시작해야하는 또다른 이유는 다른 개발자들이 당신의 소프트웨어를 사용하는것을 진지하게 고려하기 전에 테스트 코드를 보기를 원하기 때문입니다.
테스트는 팀이 함께 일하는것을 돕습니다.
- 이전의 내용은 어플리케이션을 유지 관리하는 단일 개발자의 관점에서 작성되었습니다. 복잡한 애플리케이션은 팀별로 유지 관리됩니다. 테스트는 동료가 실수로 코드를 손상시키지 않는다는 것을 보증합니다 (그리고 당신이 동료의 코드를 모르는새에 망가트리는것도). 장고 프로그래머로서 생계를 꾸려 나가려면 테스트를 잘해야합니다!
기초 테스팅 전략
-
테스트 작성에 대한 많은 접근법이 있습니다. 위키 문서 참고
-
더 흔하게는, 테스팅 입문자들은 코드를 작성하고 시간이 흐른 뒤에 테스트들이 필요하다고 판단할 것입니다. 아마도 몇몇의 테스트는 더 빨리 작성하는 것이 나을지도 모릅니다. 하지만 시작하기에 너무 늦어서는 안 됩니다.
-
어디서부터 테스트를 작성해야 할지 종잡을 수 없을 때가 있습니다. 당신이 수천 줄의 파이썬 코드를 작성해 놓았다면, 테스트할 것을 고르는 것이 쉽지 않을지도 모릅니다. 그럴 때는 다음에 새로운 기능을 넣거나 버그를 수정하는 등, 코드를 변경할 일이 있을 때, 당신의 첫 테스트를 작성하는 것이 유익할 것입니다.
버그 식별하기
-
다행스럽게도 polls 어플리케이션에는 우리가 즉시 해결할 수있는 약간의 버그가 있습니다. Question.was_published_recently() 메소드는 Question이 어제 게시된 경우 True를 반환(올바른 동작)할 뿐만 아니라 Question의 pub_date 필드가 미래로 설정되어 있을 때도 그렇습니다(틀린 동작).
-
shell을 사용해 미래의 날짜로 메소드를 실행해 버그를 확인합니다.
python manage.py shell
>>> import datetime
>>> from django.utils import timezone
>>> from polls.models import Question
>>> # create a Question instance with pub_date 30 days in the future
>>> future_question = Question(pub_date=timezone.now() + datetime.timedelta(days=30))
>>> # was it published recently?
>>> future_question.was_published_recently()
True- 미래는 〈최근(recent)〉이 아니기 때문에 이는 분명히 잘못된 것입니다.
버그를 그대로 실행시키는 테스트 만들기
-
문제를 테스트하기 위해 shell 에서 방금 수행한 작업은 자동화된 테스트에서 수행할 수 있는 작업이므로 자동화된 테스트로 바꾸도록 합시다.
-
애플리케이션 테스트는 일반적으로 애플리케이션의 tests.py 파일에 있습니다. 테스트 시스템은 test 로 시작하는 파일에서 테스트를 자동으로 찾습니다.
-
polls 어플리케이션의 tests.py 파일에 다음을 입력하십시오!
import datetime
from django.test import TestCase
from django.utils import timezone
from .models import Question
class QuestionModelTests(TestCase):
def test_was_published_recently_with_future_question(self):
"""
was_published_recently() returns False for questions whose pub_date
is in the future.
"""
time = timezone.now() + datetime.timedelta(days=30)
future_question = Question(pub_date=time)
self.assertIs(future_question.was_published_recently(), False)- 우리는 미래의 pub_date를 가진 Question 인스턴스를 생성하는 메소드를 가진 django.test.TestCase 하위 클래스를 생성했습니다. 그런 다음 was_published_recently()의 출력이 False가 되는지 확인했습니다.
테스트 실행
-
python manage.py test polls=> 혹시 권한 관련 issue가 있다면, 생성한 db user (여기 시리즈 경우 django)에게 test_django를 접근할 권한을 줘야한다. -
mysql 8+ 버전 기준으로
GRANT ALL ON test_django.* TO 'django'@'%'; flush privileges;를 진행해주자!
-
test를 통해 아래와 같은 액션들이 일어났다.
manage.py test polls는 polls 애플리케이션에서 테스트를 찾습니다.- django.test.TestCase 클래스의 서브 클래스를 찾았습니다.
- 테스트 목적으로 "특별한 데이터베이스를 만들었습니다." => 여기서 DB 접근 권한 필요
- 테스트 메소드 - 이름이 test로 시작하는 것들을 찾습니다.
- test_was_published_recently_with_future_question에서 pub_date필드가 30일 미래인 Question 인스턴스를 생성했습니다
- … assertIs() 메소드를 사용하여, 우리가 False가 반환되기를 원함에도 불구하고 was_published_recently() 가 True를 반환한다는 것을 발견했습니다.
-
테스트는 어떤 테스트가 실패했는지와 실패가 발생한 행까지 알려줍니다.
-
만약 위 오류 대신 NameError가 발생한다면, 당신은 Part 2의 한 단계를 놓쳤던 것일지도 모릅니다. 이 단계에서 우리는 datetime과 timezone의 import를 polls/models.py에 추가하였습니다. 해당 섹션에서 임포트를 복사한 후, 테스트를 다시 돌려보시길 바랍니다.
테스트 결과 기반으로 버그 수정
- 우리는 이미 문제가 무엇인지 알고 있습니다: Question.was_published_recently()는 pub_date가 미래에 있다면 False를 반환해야 합니다. models.py에서 날짜가 과거에 있을 때에만 True를 반환하도록 메소드를 수정하십시오.
# polls/models.py
def was_published_recently(self):
now = timezone.now()
return now - datetime.timedelta(days=1) <= self.pub_date <= now
- 버그를 확인한 후에 우리는 이를 드러내는 테스트를 작성 하였으며 코드에서 버그를 수정하고 테스트를 통과했습니다.
포괄적인 테스트
-
우리는 was_published_recently()메소드를 고정하는것 이상을 할수 있습니다. 사실 하나의 버그를 고치면서 다른 새로운 버그를 만들어 낸다면 분명 곤란할것입니다.
-
메소드의 동작을보다 포괄적으로 테스트하기 위해 동일한 클래스에 아래 두 가지 테스트 메소드를 추가하십시오. => 즉, 총 3가지 형태의 테스트 진행. 미래 / 과거 / 최근의 경우로 진행하는 테스트를 추가!
# polls/tests.py
... # 생략
def test_was_published_recently_with_old_question(self):
"""
was_published_recently() returns False for questions whose pub_date
is older than 1 day.
"""
time = timezone.now() - datetime.timedelta(days=1, seconds=1)
old_question = Question(pub_date=time)
self.assertIs(old_question.was_published_recently(), False)
def test_was_published_recently_with_recent_question(self):
"""
was_published_recently() returns True for questions whose pub_date
is within the last day.
"""
time = timezone.now() - datetime.timedelta(hours=23, minutes=59, seconds=59)
recent_question = Question(pub_date=time)
self.assertIs(recent_question.was_published_recently(), True)
... # 생략- 다시
python manage.py test polls해보면 3가지 테스트를 통과하는 것을 볼 수 있습니다. 이제 우리는 Question.was_published_recently()가 과거, 최근, 미래의 질문에 대해 올바른 값을 반환한다는걸 확인시켜주는 세가지 테스트를 가졌습니다.
assertIs?
-
assert로 시작하는 함수들은 '가정 설정문' 이라고 불리는 함수들이다. 주로 '테스팅'을 목적으로 많이 사용한다. 또는, 예를 들어, 어떤 함수는 성능을 높이기 위해 반드시 정수만을 입력받아 처리하도록 만들 수 있다. 이런 함수를 만들기 위해서는 반드시 함수에 정수만 들어오는지 확인할 필요가 있다. 이를 위해 if문을 사용할 수도 있고 '예외 처리'를 사용할 수도 있지만 '가정 설정문'을 사용하는 방법도 있다.
-
assert 함수 만 두고 보면
assert <표현식> [, '진단 메시지']와 같은 구조를 가진다. 예를 들면assert isinstance(10, int), 'Expected int'와 같다. 표현식이 참이 아니면 AssertionError 예외가 발생한다. -
Django에서 테스트하기 문서를 참조하자. 유닛테스트 등의 다양한 함수가 존재한다.
View 테스트
-
설문조사 어플리케이션은 상당히 대충대충 만들어져 있습니다. 이 어플리케이션은 pub_date필드가 미래에있는 질문 까지도 포함하여 게시합니다. 이것을 개선 해야합니다. 미래로 pub_date를 설정하는 것은 그 시기가 되면 질문이 게시되지만 그때까지는 보이지 않는 것을 의미 해야 합니다.
-
Django MVT구조에서 request에 대응하는 response로 SSR된 view(doc, html)파일이 오는데, 해당 FE를 테스트하기 위해서는 "테스트 전용 클라이언트 뷰"가 필요하다.
장고 테스트 클라이언트
- Django는 뷰 레벨에서 코드와 상호 작용하는 사용자를 시뮬레이트하기위해 테스트 클라이언트 클래스 Client를 제공합니다. 이 테스트 클라이언트를 tests.py또는 shell에서 사용할 수 있습니다.
= Django는 뷰 레벨에서 코드와 상호 작용하는 사용자를 시뮬레이트하기위해 테스트 클라이언트 클래스 Client를 제공합니다. 이 테스트 클라이언트를 tests.py또는 shell에서 사용할 수 있습니다.
- 우리는 또다시 shell에서 시작할 것인데, tests.py에서 필요하지 않았던 두 가지 일을 해야 합니다. 첫 번째는 shell에서 테스트 환경을 구성하는 것입니다.
python manage.py shell
>>> from django.test.utils import setup_test_environment
>>> setup_test_environment()-
response.context와 같은 response의 추가적인 속성을 사용할수 있게 하기위해서 setup_test_environment()를 사용하여 템플릿 렌더러를 설치합니다.
-
이 메소드는 테스트 데이터베이스를 셋업하지 않습니다. 그렇기 때문에 테스트는 현재 사용중인 데이터베이스 위에서 돌게되며 결과는 데이터베이스에 이미 만들어져있는 질문들에 따라서 조금씩 달라질 수 있습니다. 또한 settings.py의 TIME_ZONE이 올바르지 않으면 예기치 않은 결과가 발생할 수 있습니다. 초기에 어떻게 설정해놨는지 기억나지 않는다면 진행하기 전에 먼저 확인하십시오.
-
다음으로 우리는 테스트 클라이언트 클래스를 import 해야합니다. (나중에 tests.py에서는 django.test.TestCase 클래스에 같이 딸려오는 클라이언트를 사용할 것이므로 이것은 필요하지 않을 것입니다):
>>> from django.test import Client
>>> # create an instance of the client for our use
>>> client = Client()
# 이런것들이 준비가 되었다면 이제 우리는 클라이언트에세 우리를 위해 일을 하라고 시킬수 있습니다.
>>> # get a response from '/'
>>> response = client.get('/')
Not Found: /
>>> # we should expect a 404 from that address; if you instead see an
>>> # "Invalid HTTP_HOST header" error and a 400 response, you probably
>>> # omitted the setup_test_environment() call described earlier.
>>> response.status_code
404
>>> # on the other hand we should expect to find something at '/polls/'
>>> # we'll use 'reverse()' rather than a hardcoded URL
>>> from django.urls import reverse
>>> response = client.get(reverse('polls:index'))
>>> response.status_code
200
>>> response.content
b'\n<ul>\n\n<li><a href="/polls/1/">What's up?</a></li>\n\n</ul>\n\n'
>>> response.context['latest_question_list']
<QuerySet [<Question: How was Ur day?>, <Question: admin_question_text_add>, <Question: What's up?>]>
# 위 queryset은 테스트를 위해서 많이 만들어 둔 것임- setup_test_environment로 템플릿 렌더러를 불러왔다 -> 템플릿을 get했을때 SSR되는 것 까지 포함해서 볼 수 있게 된다. 차라리 requests모듈을 생각하면 편하다. SSR되는 내용을 get으로 가져올 수 있다.
뷰 개선하기
- 설문 조사 목록에는 아직 게시되지 않은 설문 조사 (즉, 장래에 pub_date가 있는 설문 조사)가 표시됩니다. 그것을 수정합시다. -> IndexView에서 get_queryset을 할 때 now와 날짜를 비교해서 가져올 수 있도록!
# polls/views.py
from django.utils import timezone
... # 생략
def get_queryset(self):
"""
Return the last five published questions (not including those set to be
published in the future).
"""
return Question.objects.filter(
pub_date__lte=timezone.now()
).order_by('-pub_date')[:5]
... # 생략- Question.objects.filter (pub_date__lte = timezone.now ())는 timezone.now보다 pub_date가 작거나 같은 Question을 포함하는 queryset을 반환합니다. -> 장고 ORM을 살펴보고, filter와 같이 Model Object에 query하는 공식문서를 살펴보자! queryset 검색 기초는 django - queryset과 기본 검색 방법 보면 된다.
개선 한 뷰 test
- 우리는 개선 한 뷰에 대한 test와 question을 만들어 보는, 그리고 question이 없을때 상황 등의 가능한 경우의 수에 대한 test를 진행할 것이다!
import datetime
from django.test import TestCase
from django.utils import timezone
from django.urls import reverse
from .models import Question
def create_question(question_text, days):
"""
Create a question with the given `question_text` and published the
given number of `days` offset to now (negative for questions published
in the past, positive for questions that have yet to be published).
"""
time = timezone.now() + datetime.timedelta(days=days)
return Question.objects.create(question_text=question_text, pub_date=time)
class QuestionIndexViewTests(TestCase):
def test_no_questions(self):
"""
If no questions exist, an appropriate message is displayed.
"""
response = self.client.get(reverse('polls:index'))
self.assertEqual(response.status_code, 200)
self.assertContains(response, "No polls are available.")
self.assertQuerysetEqual(response.context['latest_question_list'], [])
def test_past_question(self):
"""
Questions with a pub_date in the past are displayed on the
index page.
"""
question = create_question(question_text="Past question.", days=-30)
response = self.client.get(reverse('polls:index'))
self.assertQuerysetEqual(
response.context['latest_question_list'],
[question],
)
# 포괄적인 테스트 진행을 위해서
# 총 3가지 형태의 테스트 진행. 미래 / 과거 / 최근의 경우
def test_future_question(self):
"""
Questions with a pub_date in the future aren't displayed on
the index page.
"""
create_question(question_text="Future question.", days=30)
response = self.client.get(reverse('polls:index'))
self.assertContains(response, "No polls are available.")
self.assertQuerysetEqual(response.context['latest_question_list'], [])
def test_future_question_and_past_question(self):
"""
Even if both past and future questions exist, only past questions
are displayed.
"""
question = create_question(question_text="Past question.", days=-30)
create_question(question_text="Future question.", days=30)
response = self.client.get(reverse('polls:index'))
self.assertQuerysetEqual(
response.context['latest_question_list'],
[question],
)
def test_two_past_questions(self):
"""
The questions index page may display multiple questions.
"""
question1 = create_question(question_text="Past question 1.", days=-30)
question2 = create_question(question_text="Past question 2.", days=-5)
response = self.client.get(reverse('polls:index'))
self.assertQuerysetEqual(
response.context['latest_question_list'],
[question2, question1],
)-
python manage.py test polls -
질문 생성 함수인 create_question은 테스트 과정 중 설문을 생성하는 부분에서 반복 사용합니다.
-
test_no_questions는 질문을 생성하지는 않지만 《사용가능한 투표가 없습니다.》라는 메시지 및 latest_question_list가 비어 있음을 확인합니다. django.test.TestCase 클래스는 몇 가지 추가적인 선언 메소드를 제공합니다. 이 예제에서 우리는 assertContains()와 assertQuerysetEqual()을 사용합니다.
-
test_past_question에서 우리는 질문을 생성하고 그 질문이 리스트에 나타나는지 확인합니다.
-
test_future_question에서 우리는 미래의 pub_date로 질문을 만듭니다. 데이터베이스는 각 테스트 메소드마다 재설정되므로 첫 번째 질문은 더 이상 존재하지 않으므로 다시 인덱스에 질문이 없어야 합니다.
-
요컨데, 사이트에서 관리자 입력 및 사용자 경험에 대한 이야기를 하는 테스트를 만들었고, 모든 상태와 시스템 상태의 모든 새로운 변경 사항에 대해 예상하는 결과가 출력되는지 확인합니다.
DeatilView Test
- 우리가 만든 것이 잘 작동합니다. 그러나 미래의 설문들은 목록에 나타나지는 않지만, 사용자가 URL을 알고 있거나, 추측하면 접근할 수 있습니다. 그래서 우리는 DetailView에 비슷한 제약 조건을 추가할 필요가 있습니다. -> 즉, 무지성으로 url에 id값 넣어서 마구마구 접근할 수 있으니, 제약조건 (query에 filter / SQL기준으로 where조건)으로 now와 비교하는 걸 넣는다.
... #생략
# polls/views.py
class DetailView(generic.DetailView):
model = Question
template_name = 'polls/detail.html'
def get_queryset(self):
"""
Excludes any questions that aren't published yet.
"""
return Question.objects.filter(pub_date__lte=timezone.now())
... #생략
# polls/tests.py
... #생략
class QuestionDetailViewTests(TestCase):
def test_future_question(self):
"""
The detail view of a question with a pub_date in the future
returns a 404 not found.
"""
future_question = create_question(question_text='Future question.', days=5)
url = reverse('polls:detail', args=(future_question.id,))
response = self.client.get(url)
self.assertEqual(response.status_code, 404)
def test_past_question(self):
"""
The detail view of a question with a pub_date in the past
displays the question's text.
"""
past_question = create_question(question_text='Past Question.', days=-5)
url = reverse('polls:detail', args=(past_question.id,))
response = self.client.get(url)
self.assertContains(response, past_question.question_text)- 그런 다음 pub_date가 과거인 질문이 표시될 수 있는지, pub_date가 미래인 질문은 표시되지 않는지 확인하기 위해 몇 가지 테스트를 추가해야 합니다. -> DetailView도 위와같이 테스트 추가해주자!
유저 테스트
- 실제로 내가 client(접속자, 유저)라고 생각하고,
python manage.py runserver를 통해 위 시나리오들을 체크해보자!
- 테스트를 위해 미래 질문을 만들고, id : 4 접근을 해보면, 아래와 같이 뜬다. filter가 아주 잘 작동했다는 의미다.
결론
테스트 할 때는, 많이 할 수록 좋습니다!
-
우리의 테스트가 통제 불능으로 성장하고있는 것처럼 보일 수 있습니다. 이 속도라면 곧 우리의 어플리케이션에서 보다 우리의 테스트의 코드가 더 많아질 것이고, 나머지 코드의 우아한 간결함과 비교했을 때, 반복하는 것은 미학적입니다.
-
사실 비대해지는것은 중요하지 않습니다. 테스트 코드들이 늘어나게 하십시오. 대부분의 경우 테스트를 한 번 작성한 다음 신경을 끄게 됩니다. 그래도 이 테스트 코드의 유용한 기능들은 프로그램을 개발하는 동안 계속 해서 작동할것입니다.
-
때로는 테스트를 업데이트해야합니다. 우리가 선택지를 가진 설문들만 출력되도록 뷰를 수정한다고 가정 해 보겠습니다. 이 경우 기존 테스트 중 상당수가 실패 할 것입니다. 테스트 결과를 최신으로 유지하기 위해 어떤 테스트를 수정해야하는지 정확하게 알려주므로 테스트가 스스로를 돌보는 데 도움이됩니다.
-
최악의 경우 개발을 계속할 때 중복되는 테스트가 있을 수 있습니다. 그것은 문제가 아닙니다. 테스팅에서 반복하는 것은 좋은 일입니다.
-
테스트들이 현명하게 배열되어있는 한 관리가 어려워지지 않을 것입니다. 경험에 근거한 좋은 방법 중에는 다음과 같은 내용이 있습니다.
- 각 모델이나 뷰에 대한 별도의 TestClass
- 테스트하려는 각 조건 집합에 대해 분리된 테스트 방법
- 기능를 설명하는 테스트 메소드 이름
추가 테스팅
-
위에서는 테스트의 기본 사항에 대해서만 소개합니다. 여러분은 더 많은 것을 할 수도 있고, 또 사용할 수 있는 똑똑한 도구들이 많이 있습니다.
-
예를 들어, 이 전에 수행 한 테스트에서는 모델의 내부 로직과 뷰에서 정보를 게시하는 방법을 다루었지만 Selenium 같은 《브라우저 내》 프레임 워크를 사용하여 HTML이 브라우저에서 실제로 렌더링되는 방식을 테스트 할 수 있습니다.
-
셀리니움(혹은 셀레니움)은 자동화 테스트 도구로 많이 사용한다. 간단하게 말하면, 브라우저 엔진만 받아서 headless(즉 실제창은 띄우지않고)로 실행하여 CSR(Client-Side-rendering)까지 체크가 가능하다. 왜냐면 실제로 브라우저를 띄운 것 이기 때문이다. 콘솔창에 입력, 매크로 성격 등 모든 것이 테스트를 위해 가능하다!
-
이러한 도구를 사용하면 장고 코드의 동작뿐만 아니라 JavaScript도 확인할 수 있습니다. 테스트가 브라우저를 시작하고 인간이 그것을 다루는 것처럼 사이트와 상호 작용 것은 매우 중요합니다! Django에는 LiveServerTestCase가 포함되어있어 Selenium과 같은 도구와 쉽게 통합할 수 있게 해줍니다.
-
복잡한 어플리케이션을 사용하는 경우 연속적으로 통합하기 위해 모든 커밋마다 자동으로 테스트를 실행하여 품질 제어가 적어도 부분적으로 자동화되도록 할 수 있습니다.
-
어플리케이션에서 테스트되지 않은 부분을 탐지하는 좋은 방법은 코드 커버리지를 확인하는 것입니다. 이것은 또한 깨지기 쉬운 코드나 심지어는 죽은 코드를 식별하는 데 도움이됩니다. 코드를 테스트 할 수 없다는 것은 대개 코드가 리팩터링해야하거나 제거해야 함을 의미합니다. 커버리지는 죽은 코드를 확인하는 데 도움이됩니다. 자세한 내용은 Integration with coverage.py 를 참조하십시오.
Coverage 실행
-
Django에서 커버리지는 타 프레임워크에서 사용하는 커버리스와 동일하다. 나는 nestjs와 성격이 가장 비슷하게 느껴졌다. => 단순하게 말하면 코드가 테스트 된 정도를 말한다.
-
장고는 파이썬 프로그램의 코드 적용 범위를 측정하기 위한 도구인 coverage.py과 쉽게 통합될 수 있다.
-
pip install coverage를 하고 해당 coverage모듈 설정을 위해 ".coveragerc"라는 파일을 생성해주자 ->vi .coveragerc보통 project의 manage.py가 있는 경로에 둔다. -
".coveragerc" 파일에 아래와 같은 설정값을 넣어준다. [run] 이 헤더, 이후에 설정을 적어주면 된다.
- include = 테스트를 포함할 경로
- omit = 테스트를 제외할 경로
[run]
omit = ../virtualenvs/landlord_reputation_venv/*
-
coverage run manage.py test을 통해 django coverage를 체크할 수 있다. 우린 위에서 test도 작성해 두었기때문에 해당 test도 진행된다. offical한 full 명령어는coverage run --source='.' manage.py test myapp와 같다. -
순서를 간략하게 크게 보면,
- manage.py를 통해 전체 test 진행하고
- test된 함수에 대한 flow 체크하고 -> 커버리지 체크하고
- 결과 output해주는 흐름이다.
System check identified no issues (0 silenced).
----------------------------------------------------------------------
Ran 5 tests in 0.054s
OKcoverage report를 통해 각 파일의 커버리지를 체크할 수 있다.coverage html을 사용하면 coverage 결과를 html파일로 받을 수 있다. 진짜 QA할때 편해진다.htmlcov/index.html파일을 확인해보자!
> coverage report
Name Stmts Miss Cover
------------------------------------------------------
db_config.py 1 0 100%
manage.py 12 2 83%
mysite/__init__.py 0 0 100%
mysite/settings.py 20 0 100%
mysite/urls.py 3 0 100%
polls/__init__.py 0 0 100%
polls/admin.py 4 0 100%
polls/apps.py 4 0 100%
polls/migrations/0001_initial.py 6 0 100%
polls/migrations/__init__.py 0 0 100%
polls/models.py 17 4 76%
polls/tests.py 33 0 100%
polls/urls.py 4 0 100%
polls/views.py 28 9 68%
------------------------------------------------------
TOTAL 132 15 89%
- 이제 어디를 테스트해야할지, 죽은 곳은 어딘지, 체크해야할 곳은 어딘지 한 눈에 살펴볼 수 있다!
좋은 글 감사합니다 :) 너무 정리가 잘 되어 있어요 👍
궁금한게 있습니다, 첨부 이미지에 다크모드는 css를 수정하신 건가요? 아니면 따로 옵션이 있는건가요?