어제 하던 작업을 이어하던 도중 python 버전이 안 맞는 일이 발생했다. venv 환경이 python 2.7 로 변경되어 있었는데 원인은 모르겠다. 개발하다보면 불가사의한 일들이 발생하곤 한다.. 기존 장고 버전은 5.0 이었는데 이 버전은 파이썬 3.7 환경에서 실행될 수 없었다... 어제는 어떻게 실행된 건지 또한 알 수 없다. 아무튼 django 버전을 3.2 로 다운그레이드하고 파이썬 3.7 환경에서 다시 시작했다.

그리고 가상환경 관련 파일을 한번에 핸들링하기 어려워서 디렉토리를 프로젝트 내부에 포함시키게 되었다.

기존 디렉토리 구조는 다음과 같았다.

.
├── README.md
├── requirements.txt
├── django-site
│   ├── db.sqlite3
│   ├── manage.py
│   ├── mysite
│   └── polls
├── bin
├── include
├── lib
└── pyvenv.cfg

venv 디렉토리를 삭제하기 위해 프로젝트 내부에 가상환경을 설정하게 되었다.

.
├── README.md
├── django-site
├── requirements.txt
│   ├── db.sqlite3
│   ├── manage.py
│   ├── mysite
│   └── polls
└── venv
    ├── bin
    ├── include
    ├── lib
    └── pyvenv.cfg

바뀐 구조는 venv 환경을 삭제하고 다시 실행하기 유리하다는 장점이 있다.

새로 개발환경을 구성하니 (삭제하고 다시 clone 했다) admin 계정과 저장한 데이터들이 사라져있었다. 덕분에 데이터를 dump 하는 방법을 살펴볼 수 있었다. dump 파일을 git 에 올렸다가 admin 계정정보가 노출되면 어떡하나 고민했지만 비밀번호는 해싱된 채로 저장된다고 한다. 그래도 가급적이면 db 관련정보는 노출하면 안될 것이다. data dump 하는 방법

4장까지 진도를 다시 복습해보고 5장을 시작하게 되었다. 3, 4 장은 view, template 관련 문법이라 지루했지만 5장은 관심이 많은 테스트 코드 관련 문서였다.

5장 테스트 코드

테스트 코드의 중요성은 아무리 강조해도 지나치지 않는다. 코드의 작동이 엄밀해야 할수록 (작성된 코드가 돈을 벌어 올 수록) 테스트의 중요성은 더욱 커진다. 에러 케이스를 예방하는 데 도움을 주고 테스트를 자체가 요구사항을 의미하기 때문에 요구사항을 보장한다. 그리고 테스트 가능한 코드는 그 자체로 모듈화를 보장하고 잘 모듈화된 코드는 재사용성과 기능의 가독성을 보장한다. 테스트 코드를 만드는 것은 어렵지만, 어려운 만큼 큰 보상이 있다는 뜻이다. 귀찮아도 열심히 만들자.

테스트를 위해 polls/test.py 파일을 만들었다.

django.test 모듈에서 TestCase 라는 클래스를 불러와서 사용한다.

from django.test import TestCase

여기서는 이전에 만들었던 Question 모델의 was_published_recently() 함수에 대한 테스트를 작성한다. was_published_recently() 함수는 해당 객체가 현재 날짜에서 1일 안에 작성되면 True 를 반환하는 함수이다. 여기서 작성하려는 테스트는 하루 이내에 작성된 객체는 True 를 반환 하는지, 1일 이전에 추가된 객체, 미래에 추가된 객체에 대해 False 를 반환 하는지 검사하는 코드이다.

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)

    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)

QuestionModelTests 라는 객체는 위에서 import 한 TestCase 클래스를 상속받아서 생성했다. 겸사겸사 python 상속에 대해서도 알아보면

class Country:
    ~~ 내용 ~~

class Korea(Country):
    ~~ 내용 ~~

위와 같이 사용하면 상속이 된다

TestCase 객체를 상속받았기 때문에 assertIs() 같은 함수를 이용할 수 있다.

테스트 코드를 작성하고 다음과 같이 명령어를 입력하면 polls 앱 내부의 테스트를 자동으로 수행한다.

python manage.py test polls

제대로 테스트를 작성했다면 다음과 같이 출력된다.

(venv) ➜  django-site git:(main) ✗ python manage.py test polls
Creating test database for alias 'default'...
System check identified no issues (0 silenced).
...
----------------------------------------------------------------------
Ran 3 tests in 0.001s

OK
Destroying test database for alias 'default'...

자동 실행되는 테스트 코드를 만들려면 몇 가지 사항을 유의해야 한다.

• 파일 이름이 test 로 시작해야 함

• 함수 이름이 test 로 시작해야 함

아래로는 view 를 테스트하는 부분이 있는데, 이 부분은 한번 해 보기만 하고 넘어갔다. TestCase.client 를 가지고 요청에 대한 response 를 테스트해보는 방법이었다. E2E 테스트의 일종인데 나중에 DRF 를 하며 더 상세하게 해보면 좋을 것 같다.

해당 오류를 제보하려고 했는데 오류 제보하는 방법이 너무 복잡해서 포기했다. 티켓을 발급해서 제보하는 방식인데, 제보한다고 해서 오픈소스에 기여되는 것도 아니고 시간과 정신을 쏟아서 굳이 제보할 이유를 찾지 못했다. 심지어 이전 버전에서 해당 에러에 대한 제보가 있었는데도 불구하고 변경되지 않은 오타이다.

Creating test database for alias 'default'...
System check identified no issues (0 silenced).
..........
----------------------------------------------------------------------
Ran 10 tests in 0.034s

OK
Destroying test database for alias 'default'...

모든 테스트를 따라해보고 마무리했다.

6장은 app 의 static 디렉토리 내부에 css, image file 등 정적 파일을 추가하고 불러오는 내용이다. 스킵하고 넘어갔다.

그리고 개발환경이 바뀌어서 개발환경 세팅까지 해서 깃허브에 올리기로 하였다. 깃허브 링크 다시 작성하는 문서이기 때문에 빠르게 훑어보고 지나가기로 하겠다.

Admin 페이지

여러 프레임워크를 경험해 봤지만 이런 기능 찾아보기 힘들었다. 장고의 가장 큰 장점으로 보이는 관리자 페이지이다. 다음 명령어로 관리자 계정을 생성할 수 있다.

python manage.py createsuperuser

마치 워드프레스 DB 관리 플러그인을 보는 느낌이 들 정도로 깔끔한 admin 페이지를 보여주었다. admin 계정 관리도 내장 명령어로 관리되었고 Object 로 추가한 데이터를 시각적으로 확인해볼 수 있다는 것이 큰 장점인 것 같다.

polls/admin.py 파일에 이렇게 추가하면

from django.contrib import admin

from .models import Question

admin.site.register(Question)

이렇게 멋진 edit page 를 볼 수 있다.

무려 히스토리도 보여준다.

관리자 페이지 소개라 별로 할 게 없었다. 장고의 강력한 어드민 페이지 짱짱맨

view 와 template

3장은 view 와 template 을 다루는 방법에 대해 설명하는 장이다.

MVC 패턴과 같이 동적으로 페이지를 구성해서 리턴하는 방식을 사용하는데, 역시 오래된 프레임워크 답다는 생각을 했다. Django Rest Framework(DRF) 라는 것을 발견했다. Django 자체는 MTV 패턴이라는 MVC 패턴 비스무리한 것을 사용하는데, 현대의 웹사이트는 정적 페이지와 API 서버를 이용해 구성된다. 백엔드 프레임워크로써 Restful API Server 를 구성하기 위해 관련 기능을 모아둔 프레임워크가 있다. 나중에 실제로 프로젝트를 할 때는 Vue.js 와 DRF 를 이용해서 사이트를 구성할 것이기 때문에 template 관련해서는 가볍게 살펴보고 넘어갔다.

결국 이번 장에서 배운 것은 파이썬의 기본 문법과 template 문법이다.

def detail(request, question_id):
    return HttpResponse("You're looking at question %s." % question_id)

위의 예시에서 % 연산자로 숫자나 문자열을 추가할 수 있다는 것을 알게 되었다. javascript 의 탬플릿 리터럴 와 비슷한 기능을 하는 것 같다. (템플릿 리터럴이 더 직관적이고 편한 것 같다)

template 문법은 php 의 그것과 비슷했다. php, ruby on rails, jsp 등에서 동적 웹 구성을 위한 템플릿 문법으로 자주 보아서 크게 이해하기 어렵지는 않았다.

python 에서 문법이 축약된 버전을 보고 원본을 연상하기 어려웠다는 점에서 받아들이기 힘들었다.

4장 역시 view 와 template 관련 내용이 주를 이루었다. ListView, DetailView 같은 generic View 를 이용해서 간단하게 view 를 구성하는 방법이 나왔다. 앞에서 말했다시피 view 에는 크게 관심이 없기 때문에 이런 기능이 있다는 것만 숙지하고 넘어갔다.

장고 튜토리얼 따라하기. 시작하면서 써놓지 않았지만 로컬 기기는 맥북이다. 튜토리얼 따라하는 것이기 때문에 개발환경은 간편하게 venv 를 사용했다.

가상환경 설정 및 장고 세팅

가상환경 설정방법

python3 -m venv ./django-tutorial

가상환경 실행

source django-tutorial/bin/activate

장고 설치하기

python -m pip install Django

장고 설치 확인하기

python -m django --version

가상환경 설정, 장고 설치가 잘 된것을 확인했다. 튜토리얼을 따라 쭉 진행하며 어떤 일을 할 수 있는지 파악했다.

장고 프로젝트 생성

django-admin startproject mysite

mysite 라는 프로젝트가 생성되는 명령어이다.

django-admin 과 manage.py

django-admin 은 NestJs 의 nest 명령어처럼 프레임워크의 기능을 CLI 로 실행할 수 있는 명령어같다. 잠깐 살펴보니 django-admin 에는 기능이 상당히 많은 것 같았다. 역시 프레임워크라 불리는 이유가 있다. node 의 npm 같은 느낌. DB migrate, 데이터베이스 셸, 디버깅 기능, 서버 실행, 테스트 기능들이 내장되어 있다.

기본환경

mysite 라는 프로젝트를 생성하면 디렉토리 내부에 기본 파일들이 생성된다.

manage.py
mysite/
    __init__.py
    settings.py
    urls.py
    asgi.py
    wsgi.py

manage.py 는 django-admin 과 같은 기능을 한다고 한다. manage.py 는 django-admin 과 같은 동작을 하지만 프로젝트의 settings.py 파일의 환경변수를 사용할 수 있다고 써있다. 처음 프로젝트 생성만 하고 이후에는 manage.py 명령어를 사용하게 된다고 생각하고 넘어갔다. 아래와 같이 사용한다고 한다. 같은 명령어인듯

$ django-admin <command> [options]
$ manage.py <command> [options]
$ python -m django <command> [options]

• _init__.py 파일은 모듈(파일) 별 import export 를 위한 빈 파일

• settings.py 는 Node 의 setting.json 처럼 외부 라이브러리, 명령어, 환경 변수 등 manage.py 를 사용하기 위한 환경설정 파일.

• urls.py 는 Node 의 router 처럼 URL 을 지정해주기 위한 파일

• asgi.py 와 wsgi.py 는 장고의 cgi 모듈이라고 이해하고 넘어갔다. wsgi 는 STDIN 을 이용하

  는 cgi 와는 다르게 object 단위로 전송한다고 하고 asgi 는 비동기 IO 를 지원한다고 한다.

프로젝트 실행

manage.py 로 서버를 실행할 수 있다.

python manage.py runserver

서버를 실행하면 마이그레이션이 안되었다는 경고문이 나오는데,

일단 무시하고 넘어가라는 친절한 튜토리얼 localhost:8000 으로 접속하면...

잘됐네~ 잘됐어~

runserver 명령어에 대한 설명은 django-admin 문서에 자세히 나와있다. 주소나 포트를 변경할 수 있고 이런저런 기능이 있다.

앱 추가하기

여기서 끝이 아니다~~ 일주일만에 해야해서 튜토리얼 2까지는 해야한다.

polls 라는 설문조사 앱을 추가하는 예제가 나온다. manage.py 파일이 있는 곳에서 아래 명령어를 실행하자.

python manage.py startapp polls

polls/ 디렉토리가 생기고 아래와 같이 구성된다.

polls/
    __init__.py
    admin.py
    apps.py
    migrations/
        __init__.py
    models.py
    tests.py
    views.py

...일단 넘어가자 튜토리얼이 하라는 대로 파일들을 변경하자. views.py

```python
from django.http import HttpResponse


def index(request):
    return HttpResponse("Hello, world. You're at the polls index.")

urls.py 파일이 기본적으로 없는데 생성하고 복붙하자

from django.urls import path

from . import views

urlpatterns = [
    path("", views.index, name="index"),
]

그리고 mysite/ 내부의 urls.py 도 수정해줘야 한다.

from django.contrib import admin
from django.urls import include, path

urlpatterns = [
    path("polls/", include("polls.urls")),
    path("admin/", admin.site.urls),
]

튜토리얼에서 urls.py 와 include() 함수가 왜 좋은지 설명한다. include() 함수는 접두어 떼고 넘겨줘서 파싱할 때 편할것 같기는 하다. 찾아보니 DRY 원칙을 url 에 적용한 듯 한데, 복잡한 url 을 다뤄봐야 실감할 수 있을 것 같다. 일단 넘어가자

python manage.py runserver

다시 서버를 실행하고 localhost:8000/polls 로 접속하면 아까 복붙했던 polls/views 에 적어둔 메시지가 보인다. 튜토리얼 1장 끝!

Database 세팅

2장 시작! 연결되는 내용이다

드디어 settings.py 파일을 건드린다. 디폴트로 SQLite 인 게 좋았다. 여러 DB 환경마다 세팅하고 migrate 하는게 은근히 스트레스받다보니 간단하게 튜토리얼하기에는 이만한 DB 가 없는 것같다. 파일로 관리하니 눈에 잘 보이기도 하고. express 유저로써 DB 연결하려면 라이브러리 설치하고 설정파일 만들어서 연동해야 했었는데 세팅파일에서 모두 설정하게 해주니 편하다는 생각이 들었다. 이게 프레임워크지. 약간 검색해보니 설정만 변경하면 RDBMS 간에 migrate 도 간단하다는 것 같다. 직접 해봐야 알겠지만.

python manage.py migrate

migrate 를 하면 뭔가 된 것 같다. auth, admin 관련된 기본 DB 정보가 migarte 되었을거라 추정해보고 넘어갔다.

polls/models.py 파일에 아래와 같이 추가하고

from django.db import models


class Question(models.Model):
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField("date published")


class Choice(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    choice_text = models.CharField(max_length=200)
    votes = models.IntegerField(default=0)

settings.py 에 아래와 같이 추가하면

INSTALLED_APPS = [
    "polls.apps.PollsConfig", # 이 한줄만 추가하면 된다.
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
]

Migration

makemigrations 명령어로 뭔가 마이그레이션한다.

python manage.py makemigrations polls

실행 결과

Migrations for 'polls':
  polls/migrations/0001_initial.py
    - Create model Question
    - Create model Choice

클래스 만들어서 마이그레이션하는 건 orm 사용할 때 써봤지만 프레임워크 기본 기능으로 제공하니 신기했다.

python manage.py sqlmigrate polls 0001

이렇게 하면 polls/migration/ 디렉토리 안에 migrate 파일도 만들어준다.

튜토리얼 예시에서는 PostgreSQL 로 설정한 예시를 보여주는데 장고 ORM 에서 설정한 데이터 형식으로 저장한 후 데이터베이스마다 알맞은 형식으로 변경해서 제공해주는 것 같았다.

python manage.py migrate

이렇게 하면 현재 프로젝트의 migration 파일들을 실행해주는 것 같다.

Django shell

그 다음 어마어마한 기능이 나왔다. 무려 셸을 실행시키는 기능.

python manage.py shell

그러면 이런 거 할 수 있구요

>>> from polls.models import Choice, Question  # Import the model classes we just wrote.

# No questions are in the system yet.
>>> Question.objects.all()
<QuerySet []>

# Create a new Question.
# Support for time zones is enabled in the default settings file, so
# Django expects a datetime with tzinfo for pub_date. Use timezone.now()
# instead of datetime.datetime.now() and it will do the right thing.
>>> from django.utils import timezone
>>> q = Question(question_text="What's new?", pub_date=timezone.now())

# Save the object into the database. You have to call save() explicitly.
>>> q.save()

# Now it has an ID.
>>> q.id
1

manage.py 는 신이라서 다 해줍니다.

그 다음 Choice, Question 클래스에 출력함수 추가하고 커스텀 함수 추가하는 일을 하는데 해보고 넘어갔다. 셸에서 DB 에 저장 삭제하는 기능은 테스트코드 작성할 때 유용할 것 같다는 느낌을 받았다.

Node.js 신입 개발자 공고가 가뭄에 콩 나듯 하는 현상 때문에 웹 백엔드 공고면 무조건 지원서를 넣기 시작했다.

Node.js 의 ExpressJs 나 NestJs 에 비해서 Django 는 어떤 특징이 있을지 궁금하기도 하고

개발하는 데 있어서 언어나 프레임워크는 중요하지 않다는 이유없는 신념도 있었으며

그래도 Django 개발자를 뽑는데 튜토리얼 정도는 경험해봐야 하지 않을까 하는 마음에

설을 맞이해서 1주일 동안 한 번도 경험해보지 못했던 Django 에 대해 학습을 해보기로 했다.

3일 정도 간단하게 공식 튜토리얼을 따라가며 기능을 알아보고

3일 정도는 사이드 프로젝트로 하고자 하는 Todo API 서버를 만들어보도록 할 것이다.

하루는 마진.. ㅎ..

사실 포트폴리오로 사용할 것이기 때문에 블로그 포스팅이 더 중요하다.

시작해보자