2015-05-16 9 views
14

Sto usando Python 2.7.9 in Windows.Come può un python 2 doctest fallire e tuttavia non avere alcuna differenza nei valori nel messaggio di errore?

Ho un file script python UTF-8-encoded con il seguente contenuto:

# coding=utf-8 

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

ottengo un errore curioso quando corro il doctest:

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

vedo questa stessa fallimento uscita se lancio i doctest attraverso l'IDE che uso solitamente (IDEA IntelliJ), o dalla riga di comando:

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

Ho copiato le righe sotto Expected e Got in WinMerge per escludere una sottile differenza nei caratteri che non riuscivo a individuare; mi ha detto che erano identici.

Tuttavia, se rifare la corsa riga di comando, ma reindirizzare l'output in un file di testo, in questo modo:

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

il test fallisce ancora, ma l'uscita fallimento risultante è un po 'diverso:

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

Se metto l'unicode sfuggito letterale nel mio doctest:

# coding=utf-8 

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

il test viene superato. Ma per quanto posso dire, u'\u2603' e u'☃' dovrebbero valutare la stessa cosa.

Davvero Ho due domande circa il caso non andato:

  • è una delle rappresentazioni che il doctester sta dando (sotto Expected o Got) non corretta per il valore che il doctester ha per questo caso? (ad esempio x != eval(repr(x)))
  • In caso negativo, perché il test ha esito negativo?
+0

Per riassumere la questione: il doctester confronta i risultati nel settore di rappresentazione. Il problema è in realtà più simile a 'x! = Repr (eval (x))' (che accade, in quanto esiste più di un modo per rappresentare la stessa stringa in Python); il doctester prende la rappresentazione dell'effettivo output della funzione, che ha '\ u' le sequenze di escape e la confronta con la rappresentazione attesa che gli ho dato che ha il carattere unicode letterale. Quando questo fallisce, stampa la rappresentazione usando un operatore di formato che converte anche i caratteri unicode letterali nella rappresentazione prevista in escape. – rakslice

+0

Avere un test che confronta le rappresentazioni dei valori piuttosto che confrontare i valori effettivi non è l'ideale, ma è probabilmente più pratico da implementare. – rakslice

risposta

7

Il modulo doctest utilizza difflib per distinguere tra il risultato e il risultato previsto. Come il seguente:

>>> 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'] 

Sotto il cofano, il modulo doctest formatta il risultato e attesi risultato più volte. Il tuo problema sembra essere un errore di interpretazione causato dalle codifiche delle stringhe. Ciò che viene stampato sulla console è stato formattato (utilizzando %s), eliminando così le eventuali differenze visibili; rendendoli look identici.

+0

Ok, ho assunto il presupposto errato che il doctester avrebbe confrontato il valore restituito con il valore dell'espressione fornita come output previsto, poiché probabilmente è ciò che ti interessa quando stai testando una funzione. Invece stanno confrontando le rappresentazioni, che potrebbero non essere ideali come test, ma semplifica l'implementazione (è solo una diff di testo), e consente loro di implementare la modalità ellittica doctest ('# doctest: + ELLIPSIS' con' ... ' jolly) – rakslice

1

Semplicemente gratuito e anche perché questa possibilità non è considerata nella discussione di lavoro: Ho avuto un problema debolmente simile. Vedere

[...] 
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' 

Di sicuro, nessun uomo-visibile differenza. La soluzione nel mio caso banale era di assicurarsi che non ci fossero spazi bianchi!

enter image description here

Problemi correlati