Python unittest – Gegenteil von assertRaises?

Ich möchte einen Test schreiben, um festzustellen, dass eine Ausnahme unter bestimmten Umständen nicht ausgelöst wird.

Es ist einfach zu testen, ob es sich um eine Exception handelt ist erzogen …

sInvalidPath=AlwaysSuppliesAnInvalidPath()
self.assertRaises(PathIsNotAValidOne, MyObject, sInvalidPath) 

…aber wie kann man das machen Gegenteil.

So etwas in der Art, was ich suche …

sValidPath=AlwaysSuppliesAValidPath()
self.assertNotRaises(PathIsNotAValidOne, MyObject, sValidPath) 

def run_test(self):
    try:
        myFunc()
    except ExceptionType:
        self.fail("myFunc() raised ExceptionType unexpectedly!")

Hallo – ich möchte einen Test schreiben, um festzustellen, dass eine Ausnahme unter bestimmten Umständen nicht ausgelöst wird.

Das ist die Standardannahme – Ausnahmen werden nicht ausgelöst.

Wenn Sie nichts anderes sagen, wird dies in jedem einzelnen Test vorausgesetzt.

Dafür muss man eigentlich keine Behauptung schreiben.

Rufen Sie einfach die Funktion auf. Wenn es eine Ausnahme auslöst, kennzeichnet das Unit-Test-Framework dies als Fehler. Vielleicht möchten Sie einen Kommentar hinzufügen, z.

sValidPath=AlwaysSuppliesAValidPath()
# Check PathIsNotAValidOne not thrown
MyObject(sValidPath)

Bearbeitet, um Klarstellungen aus den Kommentaren hinzuzufügen:

• Unit-Tests können 3 Ergebnisse haben: Pass, Fail, Error. (Eigentlich mehr, wenn man XPass/XFail/Skip mitzählt…)
• Wenn Sie testen, dass eine bestimmte Ausnahme nicht ausgelöst wird, und sie ausgelöst wird, sollte dies theoretisch ein Fehler sein. Aber der obige Code macht es zu einem Fehler, der theoretisch “falsch” ist.
• In der Praxis wird Ihr Testrunner bei einem Fehler wahrscheinlich den Stack-Trace drucken, was beim Debuggen des Fehlers nützlich sein kann. Bei einem Fail sehen Sie den Stack-Trace wahrscheinlich nicht.
• Praktischerweise können Sie mit einem Nichtbestehen den Test als “Erwartet fehlschlagen” markieren. Mit einem Fehler können Sie das wahrscheinlich nicht tun, obwohl Sie den Test als “Überspringen” markieren können.
• Aus praktischen Gründen ist zusätzlicher Code erforderlich, damit der Testfall einen Fehler meldet.
• Ob der Unterschied zwischen „Error“ und „Failure“ eine Rolle spielt, hängt von Ihren Prozessen ab. So wie mein Team Einheitentests verwendet, müssen sie alle bestehen. (Agile Programmierung mit einer Continuous-Integration-Maschine, die alle Unit-Tests durchführt). Was für mein Team wirklich zählt, ist: „Bestehen alle Unit-Tests?“ (dh “ist Jenkins grün?”). Für mein Team gibt es also keinen praktischen Unterschied zwischen „Fail“ und „Error“.
• Aufgrund der oben genannten Vorteile (weniger Code, Anzeigen des Stack-Trace) und der Tatsache, dass Fail/Error von meinem Team gleich behandelt werden, verwende ich diesen Ansatz.
• Möglicherweise haben Sie andere Anforderungen, wenn Sie Ihre Komponententests anders verwenden, insbesondere wenn Ihre Prozesse „Fail“ und „Error“ unterschiedlich behandeln oder wenn Sie in der Lage sein möchten, Tests als „erwarteter Fehler“ zu markieren.
• Wenn Sie diesen Test lieber als Fehler melden möchten, verwenden Sie die Antwort von DGH.

Ich bin der ursprüngliche Verfasser und habe die obige Antwort von DGH akzeptiert, ohne sie zuerst im Code verwendet zu haben.

Als ich es benutzte, wurde mir klar, dass es ein wenig Anpassung brauchte, um tatsächlich das zu tun, was ich wollte (um fair zu DGH zu sein, sagte er/sie “oder so ähnlich”!).

Ich dachte, es lohnt sich, den Tweak hier zum Nutzen anderer zu posten:

    try:
        a = Application("abcdef", "")
    except pySourceAidExceptions.PathIsNotAValidOne:
        pass
    except:
        self.assertTrue(False)

Was ich hier versuchen wollte, war sicherzustellen, dass bei einem Versuch, ein Anwendungsobjekt mit einem zweiten Argument aus Leerzeichen zu instanziieren, pySourceAidExceptions.PathIsNotAValidOne ausgelöst würde.

Ich glaube, dass die Verwendung des obigen Codes (basierend auf der Antwort von DGH) dies tun wird.

Sie können definieren assertNotRaises durch die Wiederverwendung von etwa 90 % der ursprünglichen Implementierung von assertRaises in dem unittest Modul. Mit diesem Ansatz erhalten Sie am Ende eine assertNotRaises Methode, die sich abgesehen von ihrer umgekehrten Fehlerbedingung identisch verhält assertRaises.

TLDR und Live-Demo

Es erweist sich als überraschend einfach, ein hinzuzufügen assertNotRaises Methode zu unittest.TestCase (Ich habe ungefähr viermal so lange gebraucht, um diese Antwort zu schreiben, als den Code). Hier ist eine Live-Demo der assertNotRaises Methode in Aktion. Gerade wie assertRaiseskönnen Sie entweder ein Callable und Argumente an übergeben assertNotRaisesoder Sie können es in a verwenden with Aussage. Die Live-Demo enthält einen Testfall, der dies demonstriert assertNotRaises funktioniert wie vorgesehen.

Einzelheiten

Die Implementierung von assertRaises in unittest ist ziemlich kompliziert, aber mit ein wenig cleverer Unterklassenbildung können Sie die Fehlerbedingung überschreiben und umkehren.

assertRaises ist eine kurze Methode, die im Grunde nur eine Instanz von erstellt unittest.case._AssertRaisesContext Klasse und gibt sie zurück (siehe ihre Definition in der unittest.case Modul). Sie können Ihre eigenen definieren _AssertNotRaisesContext Klasse durch Unterklassen _AssertRaisesContext und überschreibt seine __exit__ Methode:

import traceback
from unittest.case import _AssertRaisesContext

class _AssertNotRaisesContext(_AssertRaisesContext):
    def __exit__(self, exc_type, exc_value, tb):
        if exc_type is not None:
            self.exception = exc_value.with_traceback(None)

            try:
                exc_name = self.expected.__name__
            except AttributeError:
                exc_name = str(self.expected)

            if self.obj_name:
                self._raiseFailure("{} raised by {}".format(exc_name,
                    self.obj_name))
            else:
                self._raiseFailure("{} raised".format(exc_name))

        else:
            traceback.clear_frames(tb)

        return True

Normalerweise definieren Sie Testfallklassen, indem Sie sie erben lassen TestCase. Wenn Sie stattdessen von einer Unterklasse erben MyTestCase:

class MyTestCase(unittest.TestCase):
    def assertNotRaises(self, expected_exception, *args, **kwargs):
        context = _AssertNotRaisesContext(expected_exception, self)
        try:
            return context.handle('assertNotRaises', args, kwargs)
        finally:
            context = None

Alle Ihre Testfälle haben jetzt die assertNotRaises Methode, die ihnen zur Verfügung steht.

Ich fand es nützlich, Monkey-Patch zu machen unittest folgendermaßen:

def assertMayRaise(self, exception, expr):
  if exception is None:
    try:
      expr()
    except:
      info = sys.exc_info()
      self.fail('%s raised' % repr(info[0]))
  else:
    self.assertRaises(exception, expr)

unittest.TestCase.assertMayRaise = assertMayRaise

Dies verdeutlicht die Absicht beim Testen auf das Fehlen einer Ausnahme:

self.assertMayRaise(None, does_not_raise)

Dies vereinfacht auch das Testen in einer Schleife, was ich oft tue:

# ValueError is raised only for op(x,x), op(y,y) and op(z,z).
for i,(a,b) in enumerate(itertools.product([x,y,z], [x,y,z])):
  self.assertMayRaise(None if i%4 else ValueError, lambda: op(a, b))

def _assertNotRaises(self, exception, obj, attr):                                                                                                                              
     try:                                                                                                                                                                       
         result = getattr(obj, attr)                                                                                                                                            
         if hasattr(result, '__call__'):                                                                                                                                        
             result()                                                                                                                                                           
     except Exception as e:                                                                                                                                                     
         if isinstance(e, exception):                                                                                                                                           
            raise AssertionError('{}.{} raises {}.'.format(obj, attr, exception)) 

könnte geändert werden, wenn Sie Parameter akzeptieren müssen.

anrufen wie

self._assertNotRaises(IndexError, array, 'sort')