Seite 1 von 1

unittest und eigene Fehlermeldungen...

Verfasst: Donnerstag 14. Dezember 2006, 17:19
von jens
Ich bastel gerade an einem unitest rum... Dabei bearbeite ich eine Fehlerausgabe noch ein bisschen. Wenn innerhalb von textileFailure(Exception).__str__() aber ein Fehler aufkommt, sehe ich nur:
textileFailure: <unprintable instance object>
Deswegen fange ich in __str__ generell alle Fehler ab und schicke den Traceback manuell zurück, damit ich eine gescheite Fehlerausgabe habe.

Also so:

Code: Alles auswählen

import unittest, traceback

class textileFailure(Exception):
    def __str__(self):
        try:
            msg = self.args[0]

            # Hier bastel ich an der 'msg' rum und es kommt zu einem Fehler...
            
        except Exception, e:
            # Fange hier pauschal alle Fehler ab
            # und mache mir manuell einen Traceback und schicke den zurück
            
            etype, value, tb = sys.exc_info()
            msg = traceback.format_exc(tb)
            return msg


class tinyTextileTest(unittest.TestCase):

    # Eigene Fehlermeldung
    failureException = textileFailure

    ...
Geht das auch irgendwie einfacher???

Re: unittest und eigene Fehlermeldungen...

Verfasst: Freitag 15. Dezember 2006, 09:59
von CM
jens hat geschrieben:Ich bastel gerade an einem unitest rum... Dabei bearbeite ich eine Fehlerausgabe noch ein bisschen. Wenn innerhalb von textileFailure(Exception).__str__() aber ein Fehler aufkommt, sehe ich nur:
Hoi Jens,

mir ist leider nicht klar, was genau Du da basteln willst. (mal wieder ;-) ) Aber vielleicht hilft das weiter:

Code: Alles auswählen

def testRead_Attributes(self):
            """read_attributes should return SAXSIOError, if invalid filename is given"""
            self.assertRaises(SAXSIOError,self.test1.read_attributes,fname='bla')
Was Teil meines aktuellen Test-Codes ist (SAXSIOError ist eine selbst definierte Exception. Wenn der Fehler natürlich abgefangen wird, darf er auch nicht also solcher beim unittest ankommen. Das müßtest Du dann entsprechend kontrollieren. Aber ein eigenes Traceback zu definieren ist IMHO ein Overkill. Ich jedenfalls wähle eher den Weg, wenn ein eine mir bekannte Fehlerquelle auftritt (beispielsweise ein ValueError mit einer nichtssagenden Fehlermeldung, weil die Objekte auf die er zutrifft Teil einer komplexen Datenstruktur sind), die Nachricht (nicht die Exception) zu überschreiben. Und nur genau das im unittest zu testen und in der Applikation abzufangen. Tritt ein anderer Fehler auf, weiß ich, daß ich diese Funktion noch nicht ausreichend debuggt habe: Zurück zum Testen.

HTH
Christian

Verfasst: Freitag 15. Dezember 2006, 10:58
von jens
Das ganze ist dazu da, tinyTextile (Markup) zu testen.

Der Unitest: http://pylucid.net/trac/browser/trunk/t ... Textile.py

Ohne meine Eigene Fehlermeldung, sieht ein Fehler z.B. so aus:

Code: Alles auswählen

AssertionError: '<p>text block 1<br />\ntext block 1 line 2</p>\n<p>text block 2<br />\ntext block 2 line 2</p>\n<p>windows 1<br />\nwindows 2</p>\n<p>mac 1<br />\nmac 2</p>\n' != '<p>text block 1<br />\ntext block 1 line 2</p>\n<p>text block 2<br />\ntext block 2 line 2</p>\n<p>windows 1<br />\nwindows 2</p>\n<p>mac 1<br />\nmac 2</p>X\n'
Damit kann man ja nix anfangen, in dem Fall...
Meine eigene Fehlermeldung nimmt diesen Text auseinander und macht das daraus:

Code: Alles auswählen

textileFailure: 

---[Output:]---
<p>text block 1<br />
text block 1 line 2</p>
<p>text block 2<br />
text block 2 line 2</p>
<p>windows 1<br />
windows 2</p>
<p>mac 1<br />
mac 2</p>


---[not equal to:]---
<p>text block 1<br />
text block 1 line 2</p>
<p>text block 2<br />
text block 2 line 2</p>
<p>windows 1<br />
windows 2</p>
<p>mac 1<br />
mac 2</p>X


---[diff:]---
 0   <p>text block 1<br />\n
 1   text block 1 line 2</p>\n
 2   <p>text block 2<br />\n
 3   text block 2 line 2</p>\n
 4   <p>windows 1<br />\n
 5   windows 2</p>\n
 6   <p>mac 1<br />\n
 7 - mac 2</p>\n
 8 + mac 2</p>X\n
 9 ?          +

10   
Damit kann ich schon mehr anfangen ;)

Verfasst: Freitag 15. Dezember 2006, 11:03
von CM
Hoi,

Ja, und? Dann gehst Du halt in und überprüfst im unittest zwei Dinge: 1. Gibt es einen AssertionError bei falschen Daten? Und 2. gibt es einen mit der richtigen Nachricht? Die kannst Du doch von der Originalexception übernehmen und überschreiben (wie auch immer). Ich würde dann ggf. aber statt

Code: Alles auswählen

return Exception, msg
ein

Code: Alles auswählen

raise Exception(msg)
machen.

Gruß,
Christian

Re: unittest und eigene Fehlermeldungen...

Verfasst: Freitag 15. Dezember 2006, 12:37
von birkenfeld
jens hat geschrieben:Ich bastel gerade an einem unitest rum... Dabei bearbeite ich eine Fehlerausgabe noch ein bisschen. Wenn innerhalb von textileFailure(Exception).__str__() aber ein Fehler aufkommt, sehe ich nur:
textileFailure: <unprintable instance object>
Geht das auch irgendwie einfacher???
Nun, innerhalb von __str__() sollte kein Fehler aufkommen, die Methode sollte mit allen möglichen Werten der Argumente zurechtkommen.

Insofern würde ich sagen: Nein, es geht nicht einfacher.

Verfasst: Freitag 15. Dezember 2006, 21:41
von Leonidas
Warum hat der Modulname bitte Leerzeichen? Wie um Himmels Willen soll man sowas importieren?