django test하기🧐

1. test를 왜 해야되는건데?

개발 공부를 하는 사람들이라면 테스트 코드의 중요성은 다들 알고 있을 것이다. 하지만 중요한 것이랑 짜는 것은 다르지... 나도 지금까지 테스트 코드를 짜지 않았고, 중요성 또한 그렇게 느끼지 못했다. 하지만 역시 중요하다 하는 것은 중요한 이유가 있었다... 이번에 프로젝트 하나를 진행하며 테스트 코드의 중요성을 느끼게 되었다. 짧게 요약하자면

1. 프로젝트를 했다. 거의 완성단계까지 다 짰다.
2. 지금까지 잘 되던게 오류가 난다.
3. 이게 어디에서 난 오류지????
4. 모든 api 를 postman 으로 테스트해본다.
5. 드디어 오류가 나는 곳을 찾았다.
6. 엥 이게 왜 오류가 날까?
7. 다시 postman 으로 해당 부분을 여러 케이스로 테스트해본다.
8. 뚝딱뚝딱 고친다.
9. 2번부터 반복

음, 아주 멋진 경험이었다... 하지만 여기서 중요한건

1. 나는 혼자서 서버를 개발했다.
2. 그렇게 큰 프로젝트가 아니다.
3. 아직 배포도 안했다.

자, 이제 중요성이 서서히 느껴지기 시작할 것이다. 한 가지 상황을 가정해보자. 당신을 포함한 5명이서 서버를 개발했다. 세상에, 갑자기 500이 뜬다! 이제 당신은 나머지 4명을 불러 모아 옹기종기 모여 postman 으로 모든 api 를 테스트 하기 시작할 것이다...

며칠 후, 당신의 팀은 드디어 모든 오류를 고쳤다! 두근두근, 배포를 하고 실제로 서비스를 할 것이다. 사용자들이 당신의 서비스를 이용할 것이고... 이런! 500이 떴다! 대체 이유가 무엇일까? 이제 당신은 나머지 4명을 불러 모아 옹기종기...(생략)

이정도면 테스트를 해야 하는 이유는 충분히 설명했다고 생각한다. 테스트 코드를 작성하는 것은 어렵고 귀찮다. 시간도 많이 든다. 하지만 나중에 생길 버그를 찾는 것보다는 훨씬 시간이 덜 들 것이다...

2. test?

사실 나도 테스트 코드를 많이 짜보지 않았다. 아니 그냥 초보다. 그렇기 때문에 내 지식보다는 django 공식 사이트와 WikiDocs 에 있는 django 자습, 그리고 MDN 에 있는 Django 튜토리얼 파트를 참고한 것을 미리 밝힌다.

test의 종류는 무수히 많다. 이 중, 가장 중요한 것을 3가지 뽑자면

Unit tests (유닛 테스트)

독립적인 콤포넌트의 (성능이 아닌) 기능적인 동작을 검증한다. 흔히 class나 function 레벨로 수행한다.

Regression tests ( 버그수정 확인 테스트 )

기존에 보고된 버그들이 재발하는지 테스트한다. 각 테스트는, 먼저 이전에 발생했던 버그가 수정되었는지 체크한 이후에, 버그 수정으로 인해 새롭게 발생되는 버그가 없는지 확인차 재수행하게 된다.

Integration tests ( 통합 테스트 )

유닛 테스트를 완료한 각각의 독립적인 콤포넌트들이 함께 결합되어 수행하는 동작을 검증한다. 통합 테스트는 콤포넌트간에 요구되는 상호작용을 검사하며, 각 콤포넌트의 내부적인 동작까지 검증할 필요는 없다. 이 테스트는 단지 전체 웹사이트에 걸쳐 각 콤포넌트가 결합하여 수행하는 동작을 대상으로 한다.

이 세 가지가 있다. 내가 지금 배우고 있는 것은 가장 위에 있는 유닛 테스트이다. 간단하게 말하면 내가 만든 모든 기능을 테스트하는 것이다.

3. 정확히 어느 범위까지 test 해야하는가?

나도 이 부분이 헷갈렸다. 모든 기능을 테스트한다고 하지만, django에는 내가 짜는 것이 아닌 기본적으로 제공하는 기능들이 많다. 과연 어디까지 내가 테스트 해야 하는 것일까? 간단하다.

내가 디자인 한 모든 것을 테스트 하면 된다.

이해가 잘 되지 않을 것이다. 예시를 들어보자면

models.py

class Post(models.Model):
    title = models.CharField(max_length=45)
    content = models.CharField(max_length=300)
    like = models.IntegerField
    
    def __str__(self):
       return self.title

아주 간단한 model 이 하나 있다. 여기서 테스트 해야 할 부분은 무엇일까?

1. title 의 길이가 45를 넘지 않는다.
2. content 의 길이가 300을 넘지 않는다.
3. __str__()을 호출했을 때 title이 반환된다.

바로 이 세가지이다. title 과 content 가 CharField 인 것과 like 가 IntegerField 인 것은 테스트할 필요가 없다. 이 기능들은 django 에 의해 정의된 것이기 때문이다. 하지만 max_length 와 __str__() 는 당신이 디자인한 부분이고, 추후에 변경될 수 있기 때문에 test 해야한다.

### 4. test 준비하기

django 에서 test 를 하는 방법은 간단하다. 짜는 것은 어렵지만
django 에서 app 을 만들면 기본적으로 tests.py 라는 파일이 생긴다. 이곳에 테스트 코드를 작성한 뒤 python manage.py test 를 하면 테스트가 시작된다. 하지만 우리는 수많은 기능을 테스트해야 하고, 테스트 코드를 아주아주 길어질 수 있다. 그렇기 때문에 test 파일을 분할하는 것을 추천한다.

python manage.py test 로 실행시키는 테스트 코드의 조건은 간단하다.

1. 파일명이 test 로 시작한다(tests.py, test_models.py)
2. TestCase 를 상속받는 class 이다.
3. 메소드 이름이 test로 시작한다(또는 TestCase가 지원해주는 메소드이다.)

즉, 우리는 tests.py 파일을 이렇게 분할할 수 있다.

(조금 알록달록하지만 넘어가면 된다.)

조금 더 깔끔하게 정리해보자.

아주 깔끔해졌다.

자, 이제 정말 코드를 짜보자.

5. test code 작성

models.py

from django.db import models
from django.contrib.auth.models import BaseUserManager, AbstractBaseUser, PermissionsMixin
from django.utils import timezone
from django.utils.translation import ugettext_lazy as _


class UserManager(BaseUserManager):

    use_in_migrations = True

    def _create_user(self, username, password, **extra_fields):
        user = self.model(username=username, **extra_fields)
        user.set_password(password)
        user.save(using=self._db)
        return user
        

class User(AbstractBaseUser, PermissionsMixin):

    username = models.CharField(
        max_length=45,
        unique=True,
    )

    nickname = models.CharField(
        max_length=45
    )

    objects = UserManager()

    USERNAME_FIELD = 'username'

    class Meta:
        verbose_name = _('user')
        verbose_name_plural = _('users')

    def __str__(self):
        return self.username

    def get_short_name(self):
        return self.username

위와 같은 user model이 있을 때 우리가 테스트 해야 할 것은 대략 아래와 같다.

1. username, nickname 의 길이
2. username 이 겹치면 안됨
3. __str__(), get_short_name의 return 값

tests/test_models.py

from django.test import TestCase

from user_system.models import User


class UserModelTests(TestCase):

    @classmethod
    def setUpTestData(cls):
        User.objects.create_user(username="testuser", password="12345", nickname="testnickname")

    def test_username_label(self):
        user = User.objects.get(id=1)
        field_label = user._meta.get_field('username').verbose_name
        self.assertEquals(field_label, 'username')

    def test_username_max_length(self):
        user = User.objects.get(id=1)
        max_length = user._meta.get_field('username').max_length
        self.assertEquals(max_length, 45)

    def test_nickname_label(self):
        user = User.objects.get(id=1)
        field_label = user._meta.get_field('nickname').verbose_name
        self.assertEquals(field_label, 'nickname')

    def test_nickname_max_length(self):
        user = User.objects.get(id=1)
        max_length = user._meta.get_field('nickname').max_length
        self.assertEquals(max_length, 45)

    def test_object_name_is_username(self):
        user = User.objects.get(id=1)
        expected_object_name = user.username
        self.assertEquals(expected_object_name, str(user))

이렇게 될 것이다. 생소한 코드들이 많을 것이다 간단히 설명을 하자면

1.def setUpTestData()

클래스 전체에서 사용되는 설정을 위해서 테스트 시작 때 딱 한 번만 실행됨. 테스트 메소드가 실행되면서 수정되거나 변경되지 않을 객체들을 이곳에서 생성할 수 있다. = 객체 생성

setUpTestData는 테스트를 실행하며 변경하지 않을 객체를 생성할 때 이용한다. 만약 변경이 필요하다면? setUp()을 사용하면 된다.

-> setUp은 각각의 테스트 메소드가 실행될 때마다 실행됨. setUpTestData는 클래스 전체에서 사용되는 설정을 위해서 테스트 시작 때 딱 한 번만 실행됨.

2. field_label = user._meta.get_field('username').verbose_name

Get the metadata for the required field and use it to query the required field data // 필드 값 확인하기

여기서 verbose_name이란 사람이 읽기 좋은 필드 이름을 말한다. verbose name은 직접 설정하지 않는 한 필드명의 소문자로 설정된다.

여기서 특이한 점은 user.username.verbose_name 으로 verbose name을 얻는 것이 아닌 _meta 를 이용한 것이다. user.username 은 우리가 접근할 수 있는 개체가 아닌 문자열이기 때문이다.

3. assertEquals(field_label, 'username')

field_label 값이 username 인지 비교하는 것이다. 단, assertTrue()와 달리 그냥 True, False 값만 알려주는 것이 아니라 오류가 나면 값까지 알려준다는 차이가 있다.