2016-04-06 2 views
1

При запуске/отладке отдельных тестов с использованием django.test.TestCase в сообщениях PyCharm logging.logger не отображаются. Я пробовал установить logging.basicConfig(level=logging.DEBUG), как предложил How can I see log messages when unit testing in PyCharm?, но это тоже не помогло. Я подозреваю, что установка django's TestCase будет интерферирующей.Входной выход, выполняющий тесты django под Pycharm

Есть ли другой способ настройки теста или конфигурации бегунов, чтобы я мог включить отладочный журнал для тестового прогона?

Каротаж я поставил в моем settings.py прямо сейчас:

LOGGING = { 
    'version': 1, 
    'disable_existing_loggers': False, 
    'handlers': { 
     'console': { 
      'class': 'logging.StreamHandler', 
      'formatter': 'verbose' 
     }, 
     'file': { 
      'level': 'DEBUG', 
      'class': 'logging.handlers.TimedRotatingFileHandler', 
      'filename': '/var/log/em/mcqueen-dev.log', 
      'when': 'midnight', 
      'formatter': 'verbose', 
     }, 
    }, 
    'formatters': { 
     'verbose': { 
      'format': '%(asctime)s.%(msecs).03d - %(process)d - %(thread)d - %(levelname)8s - %(filename)s:%(lineno)d - %(funcName)s - %(message)s' 
     }, 
     'simple': { 
      'format': '%(asctime)s - %(levelname)s %(message)s' 
     }, 
    }, 
    'loggers': { 
     'mcqueen_api': { 
      'handlers': ['console', 'file'], 
      'level': os.getenv('DJANGO_LOG_LEVEL', 'DEBUG') 
     }, 
     'mcqueen_app': { 
      'handlers': ['console', 'file'], 
      'level': os.getenv('DJANGO_LOG_LEVEL', 'DEBUG') 
     }, 
     'mcqueen_base': { 
      'handlers': ['console', 'file'], 
      'level': os.getenv('DJANGO_LOG_LEVEL', 'DEBUG') 
     }, 
    }, 
} 
+0

, пожалуйста, покажите свой файл settings.py? –

+1

Можете ли вы поделиться конфигурацией django_test в своем случае, который я предложил? –

ответ

0

Я думаю, что он будет работать

Вход в Кoнфигурировании на settings.py

LOGGING = { 
     'version': 1, 
     'disable_existing_loggers': False, 
     'formatters': { 
      'verbose': { 
    'format': "[%(asctime)s] %(levelname)s %(message)s", 
       'datefmt': "%d/%b/%Y %H:%M:%S" 
      } 
     }, 
     'handlers': { 
      'file': { 
       'level': 'DEBUG', 
       'class': 'logging.FileHandler', 
       'filename': '/var/log/django_practices.log', 
       'formatter': 'verbose' 
      }, 
      'console': { 
       'level': 'DEBUG', 
       'class': 'logging.StreamHandler', 
       'stream': sys.stdout, 
       'formatter': 'verbose' 
      }, 
     }, 
     'loggers': { 

      'django_test': { 
       'handlers': ['file', 'console'], 
       'level': 'DEBUG', 
      }, 
      'name_your_app': { 
       'handlers': ['file', 'console'], 
       'level': 'DEBUG', 
      } 

     } 
    } 

В UnitTest файл

import logging 
logger = logging.getLogger('django_test') 
logger.info('test_log') 

И журнал будет внешним видом.

+0

Не повезло. По-прежнему не выводится вывод журнала на выход теста PyCharm –

+0

Вы добавили конфигурацию журнала для 'django_test' в файл настроек? –

+0

Да.Вывод всегда просто показывает сообщения django о создании тестовой базы данных, а затем уничтожает ее, не регистрирует. Однако, если я помещаю print() в свой тест, он появляется там, поэтому это определенно окно консоли –

1

This thread в stackoverflow объясняет, почему ваш выход в журнал не отображается на консоли. По-видимому, unittest runner django заменяет глобальный sys.stdout/sys.stderr, но StreamHandler, указанный в настройках django, по-прежнему связан с исходным sys.stdout/sys.stderr. Исправление состоит в том, чтобы добавить обработчик потока в ваш регистратор в тестовом модуле на основе значений sys.stdout/sys.stderr во время выполнения.

Если вы хотите, чтобы регистратор регистрировался в консоли для всех методов вашего тестового примера, вам, вероятно, лучше всего использовать специальный базовый класс (см. Ссылку на поток для более подробной информации), чтобы обернуть логику добавления/удаления на установки/демонтажа.

Я предпочитаю использовать декораторы по отдельным методам испытаний для упаковки. Например (с помощью «» django_test регистратор конфигурации предоставленного ответа SON Лам):

import logging 
import sys 
from contextlib import contextmanager 

from django.test import TestCase 

@contextmanager 
def streamhandler_to_console(lggr): 
    # Use 'up to date' value of sys.stdout for StreamHandler, 
    # as set by test runner. 
    stream_handler = logging.StreamHandler(sys.stdout) 
    lggr.addHandler(stream_handler) 
    yield 
    lggr.removeHandler(stream_handler) 

def testcase_log_console(lggr): 
    def testcase_decorator(func): 
     def testcase_log_console(*args, **kwargs): 
      with streamhandler_to_console(lggr): 
       return func(*args, **kwargs) 
     return testcase_log_console 
    return testcase_decorator 

logger = logging.getLogger('django_test') 

class SomeTestCase(TestCase): 
    @testcase_log_console(logger) 
    def test_something(self):  
     logger.info('show something to console.') 
0

Я думаю, что это делать с испытательным бегуном, который вы используете - если вы с помощью встроенного Django проверяет настройку в PyCharm тогда уже должна быть установлена ​​переменная окружения PYTHONUNBUFFERED=1, которая, по моему мнению, делает вывод печати напрямую без буферизации и только показывается в конце (что, как я полагаю, происходит). Убедитесь, что это установлено в тестовой конфигурации, и если это не так, попробуйте это.

Смотрите также: Pycharm unit test interactive debug command line doesn't work (особенно, если вы используете другой тест бегун)

0

Когда я хочу видеть журналы во время работы на тестах для проекта Django в PyCharm я помещаю этот фрагмент кода в файле с тест:

import logging 
logger = logging.getLogger(__name__) 
logging.disable(logging.NOTSET) 
logger.setLevel(logging.DEBUG) 

во время работы Django проверяет уровень для отключения журналов устанавливается высокий уровень (до 50), понижая его (как в строке # 3 в коде выше) приведет к тому, что будут отображаться журналы (или сохранить в файл - в зависимости от используемого обработчика журнала).

Смежные вопросы