2009-11-01 2 views
4

Django의 단위 테스트 장치 (manage.py test)를 사용하고 있는데, 이것은 오류를 던지고 코드가 경고를 생성 할 때 정지합니다. 이 표준 코드는 표준 Python unittest 모듈에서 테스트 할 때 경고를 생성하지만 코드를 통해 코드 실행을 계속합니다.Django의 단위 테스트에서 경고가 예외로 발생합니까?

약간의 연구에 따르면 파이썬이 경고에 예외를 발생 시키도록 설정할 수 있습니다. 이는 테스트 프레임 워크에서 오류가 발생했다고 생각할 수 있다고 생각합니다. 유감스럽게도, 테스트에 대한 장고 문서는 "오류"의 정의 또는 경고 처리를 수정하는 방법에 대해 약간의 빛을 보입니다.

So : Django 유닛 테스트 프레임 워크가 기본적으로 경고를 발생시키는 설정입니까? 장고에이 동작을 변경하는 기능이 있습니까? 그렇지 않다면 장고가 오류를 출력하지만 코드 실행을 계속할 수있는 방법에 대한 제안은 누구나 가지고 있습니까? 아니면 문제를 완전히 잘못 진단 했습니까?

업데이트 : MySQLdb를 호출 할 때 경고가 표시되면 테스트 코드가 중단됩니다. 이러한 호출은 Python unittest 프레임 워크에서 테스트 할 때 동일한 경고를 던지지만 중단하지는 않는 모듈에 의해 수행됩니다. 나는 코드의 상황을 복제 할 수있는 효율적인 방법에 대해 생각할 것이다.

답변 :

/usr/...django/.../mysql/base.py :

조금 더 연구는이 문제가 장고의 MySQL의 백엔드와 관련된 계시

if settings.DEBUG: 
    ... 
    filterwarnings("error", category=Database.Warning) 

DEBUG = False로 settings.py를 변경하면 코드가 경고를 throw하지만 멈추지 않습니다.

내 데이터베이스 호출이 내 자신의 백엔드에 의해 생성되기 때문에 이전에 장고에서이 문제가 발생하지 않았습니다. 장고 백엔드를 호출하지 않았기 때문에 나는 경고 처리를 재설정하지 않았으며 경고 메시지에도 불구하고 코드는 계속되었다. Django 테스트 프레임 워크는 장고 백엔드를 확실히 호출합니다. 데이터베이스를 사용하여 모든 일을 처리합니다. 코드가 호출되기 전에 호출이 경고 처리를 재설정합니다.

+0

이 동작을 트리거 할 수 없습니다. 의도적으로 경고를 발행하는 코드를 추가하면 경고 메시지가 인쇄되지만 테스트는 계속 진행됩니다. 당신이하고있는 일과 당신이보고있는 결과에 대한 좀 더 많은 정보가 도움이 될 것입니다. –

+0

문서에서 Django 테스트는 디버그 모드를 실행하지 않습니다. http://docs.djangoproject.com/en/dev/topics/testing/#other-test-conditions, 그래서 당신이 참조한 코드 경고/오류가 발생합니다. ./manage.py 테스트 프로세스의 일부로 '테이블이 존재하지 않습니다'SQL을 어떻게 트리거하고 있습니까? – michaeljoseph

답변

2

업데이트 된 정보가 주어지면, 이것이 장고가해야 할 일이라고 말할 수 있습니다. MySQL의 경고는 데이터 손실까지 포함하여 여러 가지를 나타낼 수 있습니다 (예를 들어, 열이 보유 할 수있는 값보다 큰 값을 삽입하려고하면 MySQL이 경고하고 자동으로 자릅니다). 테스트시기에 대해 알아보십시오. 따라서 가장 좋은 방법은 생성되는 경고를보고 더 이상 경고가 발생하지 않도록 코드를 변경하는 것입니다.

+0

행동은 나에게 합리적인 것처럼 보이지만 자신을 충분히 전문가라고 생각하지 마십시오. 내가 얻는 경고는 "테이블이 존재하면"테이블에 대한 응답으로 "테이블이 존재하지 않습니다"입니다. SQL을 작성하여이를 피하는 방법을 모르겠습니다. 내 노트가 상황을 버그라고 생각하는 것이 아니라 내 특정 상황에 맞지 않는 행동으로 논의하기를 바랍니다. – chernevik

+0

MySQL은 잘라 내기를 경고하고 삽입을 계속할지라도 기본적으로 ok로 간주합니다.나는 개인적으로 Django가 이러한 경우 DB 공급자에게 연기해야한다고 생각한다. Django가 경고 (잘린 데이터)를 오류 (악의적 인 방식으로 영향을받는 데이터)로 에스컬레이션해야한다고 생각하면 SQLMODE를 전통적으로 설정하거나 시작 중에 MySQL이 전통적인 모드가 아니라는 것을 사용자에게 알려 주거나 문제가 문서에 있습니다. http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html#sqlmode_traditional –

+0

아담, 장고이며 올바른 동작하지 무엇인지에 대한 표준, DB에 독립적 인 자체가 (예를 들어, MySQL 스토리지 엔진의 수행 여부와 관계없이 참조 무결성을 보장하기 위해 몇 가지 길이로 이동합니다.) DB 공급 업체가 데이터 손실/손상을 용납 할 수 있다고 생각하는지에 관계없이 실제로 올바른 방법입니다. –

관련 문제