728x90

파이썬 장고가 제공하는 단위 테스트는 코드 배포전에 에러를 검출해 볼 수 있는 방법으로 무척 유용합니다. 젠킨스 빌드시에도 활용하여 자칫 로컬 환경과 원격 빌드/운영 환경의 차이에도 대응할 수 있어 장애를 막는 지름길이 되기도 합니다.

파이썬 장고의 단위 테스트를 구성해서 잘 사용하던 중, 갑자기 (원인은 알 수 없습니다 ㅜㅜ) TransactionManagementError와 함께 테스트가 지속적으로 실패하기 시작하여 열심히 구글링하고 삽질한 내용을 간략히 정리해 봅니다. 


장고 단위 테스트를 사용하기 위해서는 아래와 같은 코드를 만들게 됩니다. 참고로 코드는 장고 공식 문서에서 가져왔습니다. 이때, 실제 테스트를 수행하는 클래스는 매개변수로 TestCase 클래스의 인스턴스를 받게 됩니다. 아래의 코드에서는 TestCase 클래스를 가져왔네요.

import unittest
from django.test import Client

class SimpleTest(unittest.TestCase):
    def setUp(self):
        # Every test needs a client.
        self.client = Client()

    def test_details(self):
        # Issue a GET request.
        response = self.client.get('/customer/details/')

        # Check that the response is 200 OK.
        self.assertEqual(response.status_code, 200)

        # Check that the rendered context contains 5 customers.
        self.assertEqual(len(response.context['customers']), 5)

 

코드를 보면 실제 테스트 함수들이 클래스 내에 기술이 되어 있습니다. 제 경우 문제는 테스트 함수들이 데이터베이스에 대한 질의를 수행하는 코드를 호출하면서 발생했습니다. 일반적인 TestCase의 서브 클래스로는 데이터베이스 관련 코드를 수행하고 테스트 결과를 돌려주는데 문제가 있었습니다. 테스트가 수행되면서 발생한 에러는 아래와 같습니다.

raise TransactionManagementError(
django.db.transaction.TransactionManagementError: An error occurred in the current transaction. You can't execute queries until the end of the 'atomic' block.

 

이 에러 메세지가 참 얄미운게 내용이 좀 뭉뚱그려져 있습니다. 굉장히 명확한 에러이기 때문에 TestCase 클래스를 트랜잭션을 지원하는 것으로 변경하라고 하면 되었을 것을 저렇게 표현하고 있어서 애를 먹게 만들더군요. 이 문제에 대한 첫번째 접근은 장고 공식문서에서 가이드하는 TransactionTestCase 클래스의 사용입니다. 

https://docs.djangoproject.com/en/3.2/topics/testing/tools/#django.test.TransactionTestCase

 

제 경우는 장고 REST Framework 를 사용하고 있던 관계로 이쪽에서 필요한 클래스의 변경 작업을 진행했습니다. 기존에 에러가 발생하던 테스트 코드에서는 REST Framework가 제공하는 test 패키지의 APITestCase 클래스를 쓰고 있었습니다. 이 클래스를 APITransactionTestCase로 변경하니 에러가 말끔히 사라지고 테스트도 정상적으로 수행되기 시작했습니다.

# 기존
from rest_framework.test import APITestCase

# 변경
from rest_framework.test import APITransactionTestCase

 


TransactionManagementError로 검색을 하다보면 여러가지 문제 상황과 이에 대한 대처법들이 소개되고 있습니다. 가령 1) 테스트 테이블에 데이터를 피딩하는 과정에 문제였고 이를 수정하여 해결 했다는 분도 계셨고, 2) 테스트가 수행하는 코드 내에 try~except 구문이 사용되는 경우 transaction.atomic() 을 이용해서 코드를 변경해야 된다는 글도 있었습니다.

다양한 트러블슈팅 사례와 방법이 있는 것을 보면 에러 메세지가 조금 더 친절하게 출력되면서 원인을 빠르게 확인할 수 있었으면 어땠을까 하는 생각이 듭니다. 그래도 트러블슈팅을 하면서 또 파이썬에 대해, 장고에 대해 조금 더 알 수 있었기에 의미 없는 시간은 아니었던 것 같습니다!

파이썬과 관련하여 최근에 겪었던 다른 이슈들과 해결 방법은 아래의 글을 참고해 보시기 바랍니다!

 

M1 Apple silicon 맥북에서 파이썬 cryptography 패키지 설치가 안되는 문제 / python cryptography package installa

M1 silicon 맥북에서는 안되는게 참 많습니다. 새로운 CPU 아키텍쳐라서 여기저기서 패키지들이 오동작하거나 설치가 안되는 문제들이 많이 발생합니다. 오늘의 주인공인 파이썬 cryptography 패키지

ondemand.tistory.com

 

 

애플실리콘 M1 맥북에서 파이썬 magic 패키지가 로딩되지 않는 현상

애플실리콘 기반의 맥북이 등장하면서 세상이 참 행복해졌습니다. 베터리도 오래가고 이륙하지도 않고... 이렇게 쾌적한 맥 운영체제는 간만에 느껴보는 즐거움이었습니다. 하지만 의외의 장소

ondemand.tistory.com

 

 

PIP를 통한 mysqlclient 라이브러리 설치 에러 (mysql_config not found)

새로운 개발 장비가 생기면 이전에 사용하던 장비의 환경과 동일하게 준비하는 것이 은근 번거롭습니다. 한동안 손대지 않고 있던 파이썬 Python 장고 Django 프레임웍으로 개발된 코드를 새 장비

ondemand.tistory.com

 

728x90
728x90

vscode 환경의 장점은 수많은 플러그인을 통해 개발 생산성을 극도로 향상시킬 수 있다는 점입니다. 특히 각 언어 환경에서 제공되는 플러그인의 통합이 잘되는 편이라 단일 IDE 환경에서 다양한 플러그인의 혜택을 누릴 수 있습니다.

Python으로 코드를 만들면서 구문의 오류나 스타일 문제를 잡아내기 위해 널리 사용되는 플러그인이 pylint 입니다. vscode가 아닌 파이썬 환경에서 사용할 수 있는 linter 중 하나로 넓은 사용자층을 보유하고 있습니다.

그런데 이 플러그인이 vscode에서 궁합이 잘 맞지 않을 때가 있습니다. 기존에 개발 장비에서 없던 문제가 새 개발 장비에서 하나, 둘 계속 나오니 참 환장할 노릇입니다 ^^;; 오늘은 그 중에서 vscode 환경에서 pylint가 내뿜는 no-member 에러를 없애는 방법을 살펴보겠습니다. 


 

pylint의 no-member 오류란?

pylint는 linter 도구로 코드를 분석하여 구문의 오류를 찾아내는 역할을 합니다. 구문의 오류 범주에는 사용자가 직접 만든 클래스나 함수도 당연히 포함됩니다. 제가 겪었던 문제는 Django 환경에서 클래스의 멤버 객체를 찾지 못하는 문제였습니다. 

vscode는 pylint의 도움을 받아 아래와 같이 특정한 객체에 대하여 정의되지 않은 멤버를 호출하는 코드에 빨간 물결줄을 그려주면서 존재하지 않는 멤버라는 것을 알려줍니다. 문제는 존재하지 않는 멤버가 아니라는 것입니다 ^^;;

 

빌드는 잘되지만 에러라고 pylint가 자꾸 심기를 건드립니다.

 

이 문제가 더 당혹스러운 이유는 빌드에는 문제가 없기 때문입니다. 실제로 구문에 문제가 없지만 pylint가 제대로 사용자 정의 객체를 탐색하지 못하면서 발생하는 이슈라 보면 정확합니다. 빌드에 문제가 없지만 vscode IDE 상에서는 문제가 있는 구문인 것처럼 소스코드 파일을 열때마다 시뻘건 줄과 경고 문구를 쏟아내는데 스트레스가 꽤 큽니다. 

 

해결방법 : vscode 공통 환경 설정에서 pylint 옵션 지정하기

이 문제를 해결하기 위해서는 vscode의 공통 환경 설정 settings.json 파일에서 pylint에 대한 옵션을 추가로 지정해 주어야 합니다. 기본적으로는 settings.json 파일에 pylint와 관련한 항목은 설정되어 있지 않습니다.

우리가 추가해야 할 내용은 아래와 같습니다. 이미지에는 오타가 있기 때문에 (--generated-members가 아니라 --generate-members입니다) 아래의 구문을 복사해서 settings.json 파일에 추가하는 것을 권장드립니다. 

  1. Mac에서는 Shift+Command+P를, Windows에서는 Ctrl+Shift+P를 눌러 Command Palette를 엽니다
  2. Command Palette에서 "Preferences: Open Settings (JSON)"을 입력하거나 찾아서 선택합니다
  3. Setting.json 파일에 아래의 항목을 추가합니다.
  4. vscode를 재기동하여 프로젝트를 열어 확인합니다.
"python.linting.pylintArgs": ["--generate-members", "from_json,query"],

 

 


 

vscode를 사용하지 않는 환경에서는 pip를 이용해 pylint-django 플러그인을 설치하면 에러를 해결할 수 있다는 글도 검색하면서 봤던 것 같습니다. vscode가 아닌 환경에서 문제를 겪고 있다면 pylint-django 공식 가이드 문서에 따라 패키지 설치후 django 환경 변수를 지정해 보시기 바랍니다!

 

pylint-django

A Pylint plugin to help Pylint understand the Django web framework

pypi.org

 

그외에 vscode 환경에서 python 개발을 하면서 겪을 수 있는 다른 문제들에 대해서는 아래의 글들을 참고하시면 도움이 되실지도 모르겠습니다. 변수가 많은 vscode 환경에서의 개발에서 꼭 승리하시길 기원하겠습니다!

 

Visual Studio Code 에서 Python 패키지의 Unresolved Import Error 를 처리하는 방법

코드를 만들 필요가 있을때 왠만하면 Node.js 를 이용하는 편입니다. 아무래도 익숙하기도 하거니와 자유로운 자바스크립트의 DNA 가 살아 있기 때문에 "대략 이렇게 돌아갈까?" 하는 것들이 동작

ondemand.tistory.com

 

728x90
728x90

이제 본격적으로 프로젝트의 내용물을 채워보도록 하겠습니다. 별도의 외부 데이터베이스를 사용하지 않고 기본적으로 제공되는 파일 기반의 데이터베이스인 Sqlite 를 그대로 사용하도록 하겠습니다. 데이터베이스를 쓰기 위해서 먼저 기본 테이블을 생성해야 하는데요, Django 는 데이터베이스를 이용하는 것을 전제로 사용자와 사용자 권한 그룹 테이블을 알아서 만들어 주도록 되어있습니다. 

 

기본 테이블의 생성

기본 테이블을 생성하거나 프로젝트에 필요한 테이블을 생성하는 것 모두 manage.py 가 제공하는 명령어를 이용할 수 있습니다. 기본 테이블의 구조는 미리 정의가 되어 있기 때문에 모델을 만드는 작업을 하지 않고 사용이 가능합니다. 프로젝트의 루트 경로에서 manage.py migrate 명령을 사용하여 기본 테이블인 admin, auth, contenttypes, sessions 의 4개 테이블을 생성할 수 있습니다. 

% python3 manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, sessions
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying auth.0010_alter_group_name_max_length... OK
  Applying auth.0011_update_proxy_permissions... OK
  Applying sessions.0001_initial... OK

migrate 명령이 수행되고 나면 settings.py 에 지정된 기본 데이터베이스 정보에 따라 Sqlite 용 파일이 프로젝트 루트 경로에 생성된 것을 보실 수 있습니다. 추후 Django 에 익숙해져 외부 데이터베이스를 사용하는 경우에는, 해당 데이터베이스 인스턴스에 4가지 테이블이 생성된다고 보시면 되겠습니다. 

 

프로젝트용 테이블의 생성 

기본 테이블은 Django 를 이용한 과제의 공통 테이블의 성격입니다. 수퍼 유저의 정보와 같은 것들이 이곳에 저장되는 것이지요. 실제 프로젝트에서 사용할 테이블을 정의하고 생성해야 하겠죠? 지난 포스팅 이후 뭘 만들어 볼까 고민하다가... 인터넷 서핑을 하면서 마음에 드는 이미지를 모아두는 서비스를 만들어 보면 어떨까 생각을 해보았습니다. (그닥 재미있어 보이진 않는군요...)

이미지의 이름 (Title) 과 이미지의 경로 (URL) 이고, 추후 검색 기능등을 넣기 위해 태그 (Tags) 정보를 입력받아 저장해보겠습니다. 지난 시간에 추가한 어플리케이션인 myfirstapp 폴더에 생성된 여러 파일들 중 models.py 를 열겠습니다. 이 파일에는 어플리케이션이 사용할 데이터, 테이블의 구조가 기술되며 이를 기반으로 manage.py 가 데이터베이스에 테이블 생성 작업을 대행해주기도 합니다. 

물론 별도로 데이터베이스를 수정하고 내용을 models.py 에 반영하는 것도 가능하지만 models.py 를 먼저 수정하고 manage.py 를 이용해서 데이터베이스 작업을 하는 것이 초보자에게는 좋다고 생각합니다. 사실 회사에서 과제를 진행하면서 migrate 과정에 대한 의문이 좀 많았는데 원격지의 리얼 데이터베이스를 쓰는 경우에는 migrate 을 잘 활용하는 것이 DBA 의 눈도 피할 수 있어서 좋을 것 같군? 하는 생각도 좀 들긴 합니다. 

 

이번 포스팅에서는 테이블 구조를 기술할 때 사용하는 django.db.models.Model 클래스를 자세히 살펴보지는 않겠습니다. 아직 공부를 못한 것도 있고 (퍽퍽...) 일단은 과제 하나를 잘 수행해 보는 것이 좋다고 생각하기 때문입니다 (후훗). 눈으로 보더라도 최대 길이라던가 빈 값의 허용, null 도 허용할 것인가와 같은 우리가 데이터베이스에서 테이블을 만들때 입력하는 정보들이 대부분 기술된다고 보시면 되겠습니다. 

Admin 사이트에 생성한 테이블 반영

admin.py 를 수정하면 생성한 테이블 정보를 django 가 제공하는 기본 어드민 페이지 (0.0.0.0:8000/admin) 에서 관리하거나 간단한 데이터 입출력 작업을 할 수 있게 됩니다. 지난 포스팅에서 이야기 했는지 기억이 잘 안납니다만 php 에서 쓰는 phpmyadmin 과 같은 역할이라고 생각하시면 편합니다. 우리가 생성한 어플리케이션인 myfirstapp 폴더 하위의 admin.py 를 열어서 아래와 같이 수정해 보겠습니다. 

 

테이블을 Sqlite 데이터베이스에 반영하려면 manage.py 가 제공하는 makemigrations 와 migrate 명령을 사용하게 됩니다. makemigrations 는 migrate 명령이 이해할 수 있도록 models.py 에 기술된 내용을 확인하고 현재의 데이터베이스와 비교하여 변경이 필요한 부분을 추출, python 코드로 만드는 역할을 수행합니다. migrate 은 이렇게 정리된 내용을 실제로 데이터베이스에 반영하는 역할을 하는 것이겠죠?

명령을 수행하기전에 어플리케이션 폴더인 myfirstapp 하위의 migrations 폴더를 살펴보면 __init__.py 파일만 존재하고 아무런 내용이 없는 것을 확인할 수 있습니다. makemigrations 명령을 수행한 후에 해당 폴더의 내용들이 어떻게 바뀌는지 살펴보도록 하겠습니다. 

 

명령을 수행하고 나면 myfirstapp/migrations 폴더에 0001_initial.py 라는 파일이 생성된 것을 볼 수 있습니다. 느낌은 첫번째 마이그레이션 작업이라는 느낌이죠? 이 파일을 열고 내용을 살펴보면 데이터베이스 작업에 필요한 파일로 조금전에 models.py 에 업데이트 했던 내용들이 들어가 있는 것을 확인할 수 있습니다. 

% python3 manage.py makemigrations
Migrations for 'myfirstapp':
  myfirstapp/migrations/0001_initial.py
    - Create model ImageCollector

 

이제 manage.py 의 migrate 명령으로 생성된 마이그레이션 작업 파일을 수행하여 데이터베이스에 반영되도록 하겠습니다. 기본 테이블로 생성한 admin, auth, contenttypes, sessions 에 대해서도 변경 사항이 있는지 점검하는 것을 볼 수 있습니다. ImageCollector 모델을 만들면서 지정한 max_length 지정 값은 auth 테이블에도 업데이트가 필요한 모양입니다. 알아서 잘 챙겨주니 참 고맙습니다. :-)

% python3 manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, myfirstapp, sessions
Running migrations:
  Applying auth.0012_alter_user_first_name_max_length... OK
  Applying myfirstapp.0001_initial... OK

 

이렇게 이번 포스팅에서는 기본 테이블을 생성하고 프로젝트에서 사용할 테이블을 생성해 보았습니다. 이렇게 만든 테이블을 확인하는 쉬운 방법은 장고가 제공하는 Admin 사이트를 이용하는 것입니다. 다음 포스팅에서는 Admin 사이트 접근을 위한 수퍼유저 계정의 생성을 해보고 생성된 ImageCollector 테이블에 간단한 샘플 데이터를 넣어보도록 하겠습니다. 

728x90
728x90

프로젝트도 만들었고 프로젝트와 어플리케이션의 차이도 살펴보았다. 이번 포스팅에서는 프로젝트 안에 어플리케이션을 생성해 보도록 하자. 딱히 무엇을 만들겠다는 계획이 있는 것은 아니지만, 프로젝트가 큰 개념이고 어플리케이션은 프로젝트 안에 들어가 있는 기능집합의 개념이니, 그 컨셉을 따라가 보자는 것이다. 

어플리케이션의 생성도 프로젝트의 생성과 비슷하다. 사용하는 도구가 약간 달라지는 점에 주의하자. 프로젝트 생성시에는 django-admin 이라는 장고가 제공하는 도구를 사용했다면, 이번에는 프로젝트 안에 생성된 manage.py 를 이용하게 된다. manage.py 는 프로젝트를 브라우저에 한번 띄워볼때 사용했던 바로 그 도구다.


manage.py 를 이용하여
어플리케이션 생성하기

// 별 문제 없이 생성에 성공하면 아무런 메세지도 나오지 않는다. 당황하지 말자.
% python3 manage.py startapp myfirstapp

성공적으로 어플리케이션이 만들어지면 프로젝트 루트 경로에 어플리케이션 이름으로 디렉토리가 생성된 것이 보인다. 디렉토리 안에는 여러가지 장고와 관련된 파이썬 파일들과 디렉토리가 자동으로 생성된 것이 보인다. 각 파일이 무슨 역할을 하는지 알아보아야 하는데 머리가 지끈지끈 아파오는 것 같다.

 

프로젝트의 settings.py 를 편집하여
어플리케이션을 추가해보자

NoPD 는 친절하기 때문에 다시 한 번 이미지를 첨부했다. 처음 프로젝트를 생성했을때 프로젝트 이름과 동일한 디렉토리가 하위에 하나 더 만들어졌던 것을 기억 할 것이다. 기억이 안나도 기억 난다고 생각하자. 이 경로에 들어가면 settings.py 가 보인다. 대략 자동 생성된 파일들의 위치로 유추해 보건데, (필자 기준으로) nopd 경로 하위에는 프로젝트의 구성요소나 자원에 대한 정보들이 담기고, 각 어플리케이션 하위에는 어플리케이션과 관련된 설정 등이 들어가는 모양이다. (이렇게 자신있게 말하면 안되는데...)

settings.py

이 파일 안에는 여러가지 설정 값들이 있다. 쉽게 생각하면 장고 웹 프로젝트가 구동되는데 필요한 각종 값들 (경로, 패키지 네임스페이스 등) 을 가지고 있는 파일이다. 새로 추가한 어플리케이션을 프로젝트가 인식하려면 settings.py 에 추가되어야 하는 것이라는 감이 왔을 것이다. 빈 줄과 주석을 모두 제거하면 위와 같은 형태가 되는데, 11행에 있는 <INSTALLED_APPS> 가 우리의 퀘스트다.

INSTALLED_APPS 에는 프로젝트가 사용하는 어플리케이션들이 등록되어 있다. 기본적으로 장고가 제공하는 admin, auth 등 6가지가 추가되어 있는 것이 보인다. 마지막에 한줄을 추가하여 우리의 어플리케이션을 추가해주고 싶은데... 어떤 값을 넣어야 하는 것일까? 다시 우리가 만든 어플리케이션 디렉토리로 이동하여 하위에 생성된 apps.py 를 열면 답이 있다. 

자동으로 생성된 클래스에 name 이 지정되어 있는 것을 볼 수 있다. 이 이름을 가져다가 마지막에 추가해주는 것이 우리의 할일이다. 어렵지 않을테니 들여쓰기에 신경쓰고, 각 아이템을 나누어주는 콤마가 잘 들어갔는지 챙겨주자. 프로젝트의 코드 수정이라니... 뭔가 손에 땀이 나면서 흥미진진하다. 

추가된 우리의 첫 어플리케이션

오늘은 여기까지이다. 아직 갈길이 멀다. 이 프로젝트, 어플리케이션에서 뭘 할지를 정하지 못했기 때문이다 ;;;

장고는 프로젝트에서 데이터베이스를 다룰 수 있도록 Admin 페이지를 제공해준다. php 를 다루어 보았다면 들어보았을, 그리고 크래커들이 기본적으로 외부에 열려 있는지 탐색해보는 phpmyadmin 과 같은 역할을 해준다고 생각하면 된다. 여튼, 뭔가를 하려면 데이터베이스가 꼭 필요한데 우리는 아직 아무런 작업을 하지 않았다. 

다음 포스팅에서는 수퍼유저를 만들기 위해 데이터베이스를 초기화하고 기본 테이블을 만들어 보겠다. 그리고 혹시나 myfirstapp 이 무슨일을 할지 재미있는 아이디어가 떠오르게 되면, 구현에 필요한 테이블도 생성해 보도록 <최선을 다하겠다> 

728x90

+ Recent posts