2015-05-16 3 views
14

Я использую Python 2.7.9 в Windows.Как скомпрометировать python 2 и пока не иметь разницы в значениях в сообщении об ошибке?

У меня есть UTF-8 файл в кодировке питон скрипт со следующим содержимым:

# coding=utf-8 

def test_func(): 
    u""" 
    >>> test_func() 
    u'☃' 
    """ 
    return u'☃' 

я получаю любопытный сбой, когда я бегу doctest:

Failed example: 
    test_func() 
Expected: 
    u'\u2603' 
Got: 
    u'\u2603' 

Я вижу этот же провал выводить ли я запуск доктрин с помощью IDE, который я обычно использую (IDEA IntelliJ), или из командной строки:

> x:\my_virtualenv\Scripts\python.exe -m doctest -v hello.py 

Я скопировал строки под Expected и Got в WinMerge, чтобы исключить некоторые тонкие различия в характерах, которые я не смог обнаружить; мне сказали, что они идентичны.

Однако, если я заново запустить из командной строки, но перенаправить вывод в текстовый файл, например так:

> x:\my_virtualenv\Scripts\python.exe -m doctest -v hello.py > out.txt 

тест по-прежнему не удается, но в результате выходной провал немного отличается:

Failed example: 
    test_func() 
Expected: 
    u'☃' 
Got: 
    u'\u2603' 

Если я ставлю сбежавший юникод буквального в моем doctest:

# coding=utf-8 

def test_func(): 
    u""" 
    >>> test_func() 
    u'☃' 
    """ 
    return u'\\u2603' 

тест проходит. Но, насколько я могу судить, u'\u2603' и u'☃' должны оценивать одно и то же.

Действительно у меня есть два вопроса о неисправной случае:

  • является одним из представлений о том, что doctester дает (при Expected или Got) неправильно для значения, что doctester имеет для этого случая? (т. е. x != eval(repr(x)))
  • Если нет, то почему сбой теста?
+0

Резюмируя вопрос: doctester сравнивает результаты в области представления. Проблема на самом деле больше похожа на 'x! = Repr (eval (x))' (что происходит, поскольку существует несколько способов представления одной и той же строки в Python); докторант принимает представление фактического выхода функции, которое имеет escape-последовательности '\ u' и сравнивает его с ожидаемым представлением, которое я дал ему, которое имеет буквальный символ Юникода. Когда это терпит неудачу, оно печатает представление с помощью оператора формата, который также преобразует символы буквального Юникода в ожидаемое представление в escape-последовательности. – rakslice

+0

Испытание, которое сравнивает представления значений, а не сравнение фактических значений, не является идеальным, но, вероятно, более практично реализовать. – rakslice

ответ

7

Модуль doctest использует difflib, чтобы различать результат и ожидаемый результат. Как следующее:

>>> import difflib 
>>> variation = difflib.unified_diff('x', 'x') 
>>> list(variation) 
[] 
>>> variation = difflib.unified_diff('x', 'y') 
>>> list(variation) 
['--- \n', '+++ \n', '@@ -1 +1 @@\n', '-x', '+y'] 

Под капотом doctest модуль форматирует результат и ожидаемый результат в несколько раз. Ваша проблема, похоже, является ошибкой интерпретации, вызванной строковыми кодировками. То, что печатается на консоль, отформатировано (с использованием %s), таким образом избавляясь от любых различий; делая их посмотреть идентичный.

+0

Хорошо, я допустил ошибочное предположение, что докторант будет сравнивать возвращаемое значение со значением выражения, заданного как ожидаемый результат, так как это, вероятно, то, что вам нужно, когда вы тестируете функцию. Вместо этого они сравнивают представления, которые могут быть не идеальными в качестве теста, но упрощают реализацию (это просто текстовый diff) и позволяют им реализовать режим эллипсиса doctest ('# doctest: + ELLIPSIS' с' ... ' подстановочные) – rakslice

1

Просто бесплатно и также потому, что эта возможность не рассматривается в рабочем обсуждении: У меня была слабо подобная проблема. См

[...] 
Expected: 
    <xarray.DataArray()> 
    array(0.0) 
    Coordinates: 
     d1 |S3 'nat' 
     d2 |S3 'dat' 
     d3 |S3 'a'   
Got: 
    <xarray.DataArray()> 
    array(0.0) 
    Coordinates: 
     d1 |S3 'nat' 
     d2 |S3 'dat' 
     d3 |S3 'a' 

наверняка, не читаемого человек видимой разницы. Решение в моем тривиальном случае состояло в том, чтобы убедиться, что не было пробелов!

enter image description here