Überprüfen des Frameworks
Um das Schreiben von Tests zu vereinfachen, stellt TAEF das Framework "Verify" bereit, das den WexLogger nutzt, um detaillierte Protokolle mit einer minimalen Codemenge zu melden. Das Verify-Framework hilft Tests bei der Bereitstellung einer strukturierten Protokollausgabe. Es gibt ein erfolgreiches Protokoll aus, wenn eine bestimmte Überprüfung erfolgreich ist, und es gibt detaillierte Informationen aus, wenn eine Überprüfung fehlschlägt.
Verwenden von Verify from C++
Die Verify-API wird in C++ als Satz von Makros angezeigt, die in der Headerdatei "Verify.h" definiert sind (Hinweis: Sie müssen Verify.h nicht explizit einschließen, sie sollten "WexTestClass.h" einschließen, die alles enthält, was Sie zum Markieren von C++-Tests und zur Interaktion mit den Verify- und WexLogger-API benötigen).
Die folgenden Überprüfungsmakros sind für native C++-Tests verfügbar:
| Makro | Funktionalität |
|---|---|
| VERIFY_ARE_EQUAL(erwartet, tatsächlich, [optionale Nachricht]) | Überprüft, ob zwei angegebene Objekte gleich sind. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_ARE_NOT_EQUAL(erwartet, tatsächlich, [optionale Meldung]) | Überprüft, ob zwei angegebene Objekte ungleich sind. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_IS_GREATER_THAN(expectedGreater, expectedLess, [optional message]) | Überprüft, ob der erste Parameter größer als der zweite Parameter ist. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_IS_GREATER_THAN_OR_EQUAL(expectedGreater, expectedLess, [optional message]) | Überprüft, ob der erste Parameter größer oder gleich dem zweiten Parameter ist. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_IS_LESS_THAN(expectedLess, expectedGreater, [optional message]) | Überprüft, ob der erste Parameter kleiner als der zweite Parameter ist. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_IS_LESS_THAN_OR_EQUAL(expectedLess, expectedGreater, [optional message]) | Überprüft, ob der erste Parameter kleiner oder gleich dem zweiten Parameter ist. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_ARE_SAME(erwartet, tatsächlich, [optionale Meldung]) | Überprüft, ob die beiden angegebenen Parameter auf dasselbe Objekt verweisen. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_ARE_NOT_SAME(erwartet, tatsächlich, [optionale Nachricht]) | Überprüft, ob die beiden angegebenen Parameter nicht auf dasselbe Objekt verweisen. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_FAIL ([optionale Meldung]) | Schlägt fehl, ohne Bedingungen zu überprüfen. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_IS_TRUE(bedingung, [optionale Meldung]) | Überprüft, ob der angegebene Bool true ist. Rufen Sie VERIFY_IS_TRUE(!! __condition) oder VERIFY_WIN32_BOOL_SUCCEEDED (__condition), um eine Win32-BOOL zu testen. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_IS_FALSE(bedingung, [optionale Meldung]) | Überprüft, ob der angegebene Bool false ist. Rufen Sie VERIFY_IS_FALSE(!! __condition) oder VERIFY_WIN32_BOOL_FAILED(__condition), um eine Win32-BOOL zu testen. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_IS_NULL(object; [optional message]) | Überprüft, ob der angegebene Parameter NULL ist. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_IS_NOT_NULL(object; [optional message]) | Überprüft, ob der angegebene Parameter nicht NULL ist. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_SUCCEEDED(hresult; [optionale Meldung]) | Überprüft, ob das angegebene HRESULT erfolgreich ist. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_SUCCEEDED_RETURN(hresult; [optionale Nachricht]) | Überprüft, ob das angegebene HRESULT erfolgreich ist, und gibt das HRESULT zurück, das an das Makro übergeben wurde. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_FAILED(hresult; [optionale Meldung]) | Überprüft, ob das angegebene HRESULT nicht erfolgreich ist. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_FAILED_RETURN(hresult; [optionale Meldung]) | Überprüft, ob das angegebene HRESULT nicht erfolgreich ist, und gibt das HRESULT zurück, das an das Makro übergeben wurde. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_THROWS(operation, exception, [optional message]) | Überprüft, ob der angegebene Vorgang den angegebenen Ausnahmetyp auslöst. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_NO_THROW(Operation; [optionale Meldung]) | Überprüft, ob der angegebene Vorgang keine Ausnahme auslöst. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_WIN32_SUCCEEDED(win32Result; [optionale Meldung]) | Überprüft, ob das angegebene Win32-Ergebnis erfolgreich war. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_WIN32_SUCCEEDED_RETURN(win32Result; [optionale Meldung]) | Überprüft, ob das angegebene Win32-Ergebnis erfolgreich war, und gibt den LONG-Wert zurück, der an das Makro übergeben wurde. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_WIN32_FAILED(win32Result, [optionale Meldung]) | Überprüft, ob das angegebene Win32-Ergebnis fehlgeschlagen ist. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_WIN32_FAILED_RETURN(win32Result, [optionale Meldung]) | Überprüft, ob das angegebene Win32-Ergebnis fehlgeschlagen ist, und gibt den LONG-Wert zurück, der an das Makro übergeben wurde. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_WIN32_BOOL_SUCCEEDED(win32Bool, [optionale Meldung]) | Überprüft, ob die angegebene Win32-BOOL erfolgreich war (!= FALSE). Protokolliert das Ergebnis von GetLastError(), wenn die Überprüfung fehlschlägt. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_WIN32_BOOL_SUCCEEDED_RETURN(win32Bool, [optionale Meldung]) | Überprüft, ob die angegebene Win32-BOOL erfolgreich war (!= FALSE) und gibt den BOOL zurück, der an das Makro übergeben wurde. Protokolliert das Ergebnis von GetLastError(), wenn die Überprüfung fehlschlägt. Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_WIN32_BOOL_FAILED(win32Bool, [optionale Meldung]) | Überprüft, ob für die angegebene Win32-BOOL ein Fehler aufgetreten ist (== FALSE). Protokolliert nicht das Ergebnis von GetLastError(). Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
| VERIFY_WIN32_BOOL_FAILED_RETURN(win32Bool, [optionale Meldung]) | Überprüft, ob die angegebene Win32-BOOL fehlgeschlagen ist (== FALSE) und gibt die BOOL zurück, die an das Makro übergeben wurde. Protokolliert nicht das Ergebnis von GetLastError(). Protokolliert auch eine benutzerdefinierte Nachricht, sofern angegeben. |
Ausnahmebasierte Überprüfung der Nutzung
Wenn Ihr Quellcode mit aktivierten C++-Ausnahmen kompiliert wird (durch Angabe des Befehlszeilenschalters "/EHsc" oder des Makros "USE_NATIVE_EH=1" in einer Quelldatei), dann wird für Makros überprüfen standardmäßig ein Fehler protokolliert, gefolgt von einer nativen C++-Ausnahme. Die ausgelöste Ausnahme ist eine WEX::TestExecution::VerifyFailureException. Sie müssen diese Ausnahme nicht abfangen – das TAEF-Framework erfasst sie für Sie und geht mit dem nächsten Testfall fort.
Optional können Sie die DisableVerifyExceptions-Klasse verwenden, wenn Sie eine Reihe von Überprüfungen in einer Reihe durchführen möchten, anstatt den Test beim ersten Überprüfungsfehler abzubrechen. Die Lebensdauer des Objekts steuert die Zeitspanne, in der Ausnahmen deaktiviert werden.
if (NULL != m_key)
{
DisableVerifyExceptions disable;
VERIFY_WIN32_SUCCEEDED(::RegDeleteKey(HKEY_CURRENT_USER, zTempName));
VERIFY_WIN32_SUCCEEDED(::RegCloseKey(m_key));
}
Im obigen Beispiel werden Ausnahmen nur im Block "if (NULL != m_key)" deaktiviert, und wenn der erste Überprüfungsaufruf fehlschlägt, wird der zweite Überprüfungsaufruf weiterhin ausgeführt.
Die DisableVerifyExceptions-Klasse ist ref-counted und funktioniert auch pro Thread.
Nicht ausnahmebasierte Nutzung überprüfen
Wenn Ihr Quellcode nicht mit aktivierten C++-Ausnahmen kompiliert ist, löst die Überprüfungsmakro kein natives C++ aus, wenn Überprüfungen fehlschlagen. Wenn Ihr Quellcode mit aktivierten C++-Ausnahmen kompiliert ist, Sie aber Ausnahmen überprüfen deaktivieren möchten, #define NO_VERIFY_EXCEPTIONS Sie einfach, bevor Sie "WexTestClass.h" einschließen.
In diesem Modell müssen Sie eine Reihe geschachtelter if-Anweisungen ausführen, um den Ablauf Ihres Testfalls zu steuern, anstatt sich auf C++-Ausnahmen zu verlassen.
if (VERIFY_WIN32_SUCCEEDED(::RegDeleteKey(HKEY_CURRENT_USER, zTempName)))
{
...
}
Überprüfen der Ausgabeeinstellungen
Wenn Sie die Ausgabe anpassen möchten, die von den Verify-APIs generiert wird, können Sie die SetVerifyOutput-Klasse verwenden. Die Lebensdauer des Objekts steuert, wie lange die Ausgabeeinstellungen festgelegt werden. Die SetVerifyOutput-Klasse ist ref-counted und funktioniert pro Thread.
if (NULL != m_key)
{
SetVerifyOutput verifySettings(VerifyOutputSettings::LogOnlyFailures);
VERIFY_IS_TRUE(true, L"Should NOT log a comment");
VERIFY_IS_TRUE(false, L"Should log an error");
}
VERIFY_IS_TRUE(true, L"Should log a comment");
Im obigen Beispiel beziehen sich die angegebenen Einstellungen nur auf Aufrufe, die im Block "if (NULL != m_key)" ausgeführt werden, und nur der Überprüfungsaufruf, bei dem ein Fehler auftritt, wird protokolliert. Der dritte Überprüfungsaufruf wird jedoch protokolliert, obwohl er erfolgreich ist. Dies liegt daran, dass die SetVerifyOutput-Klasse den Gültigkeitsbereich überschritten hat.
Es gibt die folgenden Optionen zum Festlegen der Überprüfungsausgabe:
VerifyOutputSettings::LogOnlyFailures
Es werden nur fehlgeschlagene Überprüfungsaufrufe protokolliert. alle erfolgreichen Aufrufe werden ignoriert.
VerifyOutputSettings::LogFailuresAsBlocked
Protokollieren Sie alle Fehler als blockiert, anstatt einen Fehler zu protokollieren.
VerifyOutputSettings::LogFailuresAsWarnings
Protokollieren Sie alle Fehler als Warnungen, anstatt einen Fehler zu protokollieren.
VerifyOutputSettings::LogValuesOnSuccess
Protokollieren Sie die Werte der übergebenen Parameter, auch wenn der Aufruf Verify erfolgreich ist.
Überprüfen Sie, ob die Ausgabeeinstellungen oder zusammen sein können, um mehrere Einstellungen zu aktivieren:
SetVerifyOutput verifySettings(VerifyOutputSettings::LogOnlyFailures | VerifyOutputSettings::LogFailuresAsBlocked);
Bereitstellen einer Wertausgabe für benutzerdefinierte Typen
Das C++-Überprüfungsframework bietet die Möglichkeit, eine detaillierte Ausgabe für jeden benutzerdefinierten Typ zu generieren. Dazu muss eine Spezialisierung der WEX::TestExecution::VerifyOutputTraits-Klassenvorlage implementiert werden.
Die WEX::TestExecution::VerifyOutputTraits-Klassenvorlagenspezialisierung muss im WEX::TestExecution-Namespace vorhanden sein. Es wird auch erwartet, dass eine öffentliche statische Methode namens ToString bereitgestellt wird, die einen Verweis auf Ihre Klasse akzeptiert und einen WEX::Common::NoThrowString zurückgibt, der eine Zeichenfolgendarstellung des Werts enthält.
class MyClass
{
public:
MyClass(int value)
: m_myValue(value)
{
}
int GetValue()
{
return m_myValue;
}
private:
int m_myValue;
}
namespace WEX { namespace TestExecution
{
template <>
class VerifyOutputTraits<MyClass>
{
public:
static WEX::Common::NoThrowString ToString(const MyClass& myClass)
{
return WEX::Common::NoThrowString().Format(L"%d", myClass.GetValue());
}
};
}}
Bereitstellen von Komparatoren für benutzerdefinierte Typen
Das C++-Überprüfungsframework bietet die Möglichkeit, Komparatoren für benutzerdefinierte Typen zu definieren, die keine entsprechenden Operatorüberladungen implementieren (operator=, Operator< usw.). Dazu muss eine Spezialisierung der WEX::TestExecution::VerifyCompareTraits-Klassenvorlage implementiert werden.
Die WEX::TestExecution::VerifyCompareTraits-Klassenvorlagenspezialisierung muss im WEX::TestExecution-Namespace vorhanden sein. Es wird auch erwartet, dass es eine öffentliche statische Methode namens AreEqual, AreSame, IsLessThan, IsGreaterThan und IsNull bereitstellt.
class MyClass
{
public:
MyClass(int value)
: m_myValue(value)
{
}
int GetValue()
{
return m_myValue;
}
private:
int m_myValue;
}
namespace WEX { namespace TestExecution
{
template <>
class VerifyCompareTraits<MyClass, MyClass>
{
public:
static bool AreEqual(const MyClass& expected, const MyClass& actual)
{
return expected.GetValue() == actual.GetValue();
}
static bool AreSame(const MyClass& expected, const MyClass& actual)
{
return &expected == &actual;
}
static bool IsLessThan(const MyClass& expectedLess, const MyClass& expectedGreater)
{
return (expectedLess.GetValue() < expectedGreater.GetValue());
}
static bool IsGreaterThan(const MyClass& expectedGreater, const MyClass& expectedLess)
{
return (expectedGreater.GetValue() > expectedLess.GetValue());
}
static bool IsNull(const MyClass& object)
{
return object.GetValue() == 0;
}
};
}}
Verwenden von Überprüfen von C #
Die C#-Überprüfungsverwendung ähnelt der von C++. Sie wird jedoch über den WEX bereitgestellt. TestExecution.Verify-Klasse , die sich in Te.Managed.dllbefindet.
Die folgenden Überprüfungsmethoden sind für C#-Tests verfügbar:
| Makro | Funktionalität |
|---|---|
| AreEqual(object expected, object actual) | Überprüft, ob zwei angegebene Objekte gleich sind. |
| AreEqual(object expected, object actual, string message) | Überprüft, ob zwei angegebene Objekte gleich sind. protokolliert eine benutzerdefinierte Meldung über den Erfolg oder Fehler der Überprüfung. |
| AreEqual<T>(T erwartet, T tatsächlich) | Überprüft, ob zwei angegebene Objekte gleich sind. |
| AreEqual<T>(T erwartet, T tatsächlich, Zeichenfolgenmeldung) | Überprüft, ob zwei angegebene Objekte gleich sind. protokolliert eine benutzerdefinierte Meldung über den Erfolg oder Fehler der Überprüfung. |
| AreNotEqual(object expected, object actual) | Überprüft, ob zwei angegebene Objekte nicht gleich sind. |
| AreNotEqual(object expected, object actual, string message) | Überprüft, ob zwei angegebene Objekte nicht gleich sind. protokolliert eine benutzerdefinierte Meldung über den Erfolg oder Fehler der Überprüfung. |
| AreNotEqual<T>(T erwartet, T tatsächlich) | Überprüft, ob zwei angegebene Objekte nicht gleich sind. |
| AreNotEqual<T>(T expected, T actual, string message) | Überprüft, ob zwei angegebene Objekte nicht gleich sind. protokolliert eine benutzerdefinierte Meldung über den Erfolg oder Fehler der Überprüfung. |
| AreSame(Objekt erwartet, Objekt tatsächlich) | Überprüft, ob die beiden angegebenen Parameter auf dasselbe Objekt verweisen. |
| AreSame(object expected, object actual, string message) | Überprüft, ob die beiden angegebenen Parameter auf dasselbe Objekt verweisen. protokolliert eine benutzerdefinierte Meldung über den Erfolg oder Fehler der Überprüfung. |
| AreNotSame(Objekt erwartet, Objekt tatsächlich) | Überprüft, ob die beiden angegebenen Parameter nicht auf dasselbe Objekt verweisen. |
| AreNotSame(object expected, object actual, string message) | Überprüft, ob die beiden angegebenen Parameter nicht auf dasselbe Objekt verweisen. protokolliert eine benutzerdefinierte Meldung über den Erfolg oder Fehler der Überprüfung. |
| IsGreaterThan(IComparable expectedGreater, IComparable expectedLess) | Überprüft, ob der erste Parameter größer als der zweite Parameter ist. |
| IsGreaterThan(IComparable expectedGreater, IComparable expectedLess, Zeichenfolgenmeldung) | Überprüft, ob der erste Parameter größer als der zweite Parameter ist. protokolliert eine benutzerdefinierte Meldung über den Erfolg oder Fehler der Überprüfung. |
| IsGreaterThanOrEqual(IComparable expectedGreater, IComparable expectedLess) | Überprüft, ob der erste Parameter größer oder gleich dem zweiten Parameter ist. |
| IsGreaterThanOrEqual(IComparable expectedGreater, IComparable expectedLess, Zeichenfolgenmeldung) | Überprüft, ob der erste Parameter größer oder gleich dem zweiten Parameter ist. protokolliert eine benutzerdefinierte Meldung über den Erfolg oder Fehler der Überprüfung. |
| IsLessThan(IComparable expectedLess, IComparable expectedGreater) | Überprüft, ob der erste Parameter kleiner als der zweite Parameter ist. |
| IsLessThan(IComparable expectedLess, IComparable expectedGreater, string message) | Überprüft, ob der erste Parameter kleiner als der zweite Parameter ist. protokolliert eine benutzerdefinierte Meldung über den Erfolg oder Fehler der Überprüfung. |
| IsLessThanOrEqual(IComparable expectedLess, IComparable expectedGreater) | Überprüft, ob der erste Parameter kleiner oder gleich dem zweiten Parameter ist. |
| IsLessThanOrEqual(IComparable expectedLess, IComparable expectedGreater, Zeichenfolgennachricht) | Überprüft, ob der erste Parameter kleiner oder gleich dem zweiten Parameter ist. protokolliert eine benutzerdefinierte Meldung über den Erfolg oder Fehler der Überprüfung. |
| Fail(Zeichenfolgenmeldung) | Schlägt fehl, ohne bedingungen zu überprüfen. |
| IsTrue(bool-Bedingung) | Überprüft, ob die angegebene Bedingung wahr ist. |
| IsTrue(bool-Bedingung, Zeichenfolgennachricht) | Überprüft, ob die angegebene Bedingung wahr ist. protokolliert eine benutzerdefinierte Meldung über den Erfolg oder Fehler der Überprüfung. |
| IsFalse(bool-Bedingung) | Überprüft, ob die angegebene Bedingung false ist. |
| IsFalse(bool-Bedingung, Zeichenfolgenmeldung) | Überprüft, ob die angegebene Bedingung false ist. protokolliert eine benutzerdefinierte Meldung über den Erfolg oder Fehler der Überprüfung. |
| IsNull(object obj) | Überprüft, ob der angegebene Parameter NULL ist. |
| IsNull(object obj, string message) | Überprüft, ob der angegebene Parameter NULL ist. protokolliert eine benutzerdefinierte Meldung über den Erfolg oder Fehler der Überprüfung. |
| IsNotNull(object obj) | Überprüft, ob der angegebene Parameter nicht NULL ist. |
| IsNotNull(object obj, string message) | Überprüft, ob der angegebene Parameter nicht NULL ist. protokolliert eine benutzerdefinierte Meldung über den Erfolg oder Fehler der Überprüfung. |
| <Löst T> (VerifyOperation-Vorgang) aus. | Überprüft, ob der angegebene Vorgang den angegebenen Ausnahmetyp auslöst. Gibt auch die Ausnahme zur weiteren Überprüfung zurück. |
| <Löst T> aus (VerifyOperation-Vorgang, Zeichenfolgenmeldung) | Überprüft, ob der angegebene Vorgang den angegebenen Ausnahmetyp auslöst. protokolliert eine benutzerdefinierte Meldung über den Erfolg oder Fehler der Überprüfung. Gibt auch die Ausnahme zur weiteren Überprüfung zurück. |
| NoThrow(VerifyOperation-Vorgang) | Überprüft, ob der angegebene Vorgang keine Ausnahme auslöst. |
| NoThrow(VerifyOperation-Vorgang, Zeichenfolgenmeldung) | Überprüft, ob der angegebene Vorgang keine Ausnahme auslöst. protokolliert eine benutzerdefinierte Meldung über den Erfolg oder Fehler der Überprüfung. |
Ausnahmebasierte Überprüfung der Nutzung
Wenn Überprüfungsfehler in C#-Testfällen auftreten, wird ein Fehler in die Protokollierung und einen WEX geschrieben. TestExecution.VerifyFailureException wird ausgelöst. Genau wie beim nativen C++-Modell müssen Sie sich nicht um das Abfangen dieser Ausnahmen kümmern. Das TAEF-Framework wird es für Sie abfangen und mit dem nächsten Testfall fortfahren.
Optional können Sie die DisableVerifyExceptions-Klasse verwenden, wenn Sie eine Reihe von Überprüfungen in einer Reihe durchführen möchten, anstatt den Test beim ersten Überprüfungsfehler abzubrechen. Die Lebensdauer des Objekts steuert die Zeitspanne, in der Ausnahmen deaktiviert werden. Die DisableVerifyExceptions-Klasse ist ref-counted und funktioniert pro Thread.
using (new DisableVerifyExceptions())
{
Verify.AreSame(item1, item2);
Verify.AreEqual(item1, item2);
}
Wenn im obigen Beispiel beim ersten Überprüfungsaufruf ein Fehler auftritt, wird der zweite Überprüfungsaufruf weiterhin ausgeführt.
Alternativ können Sie das gleiche Ergebnis erzielen, indem Sie Verify.DisableVerifyExceptions = true vor den Überprüfungsvorgängen festlegen, wie im folgenden Beispiel gezeigt.
Verify.DisableVerifyExceptions = true;
try
{
Verify.AreSame(item1, item2);
Verify.AreEqual(item1, item2);
}
finally
{
Verify.DisableVerifyExceptions = false;
}
Beachten Sie, dass das Deklarieren von DisableVerifyExeptions als Objekt in einem using-Block auch wenn eine solche Option verfügbar ist, immer noch die empfohlene Option ist.
Wenn Sie im Debugger anhalten möchten, wenn ein Überprüfungsfehler auftritt, rufen Sie das Ausnahmedialogfeld auf (STRG+ALT+E), klicken Sie auf Hinzufügen, wählen Sie "Common Language Runtime-Ausnahmen" in der Dropdownliste aus, und legen Sie "WEX" fest. TestExecution.VerifyFailureException" im Feld Name.
Überprüfen der Ausgabeeinstellungen
Wenn Sie die Ausgabe anpassen möchten, die von den Verify-APIs generiert wird, können Sie die SetVerifyOutput-Klasse verwenden. Die Lebensdauer des Objekts steuert, wie lange die Ausgabeeinstellungen festgelegt werden. Die SetVerifyOutput-Klasse ist ref-counted und funktioniert pro Thread.
using (new SetVerifyOutput(VerifyOutputSettings.LogOnlyFailures))
{
Log.Comment("Only the following error should be logged:");
Verify.IsTrue(true, "Should NOT log a comment");
Verify.IsTrue(false, "Should log an error");
}
Verify.IsTrue(true, "Should log a comment");
Im obigen Beispiel sollte nur der zweite Überprüfungsaufruf protokolliert werden, da dies der einzige Aufruf ist, der innerhalb des using-Blocks fehlschlägt. Der dritte Überprüfungsaufruf wird jedoch protokolliert, obwohl er erfolgreich ist. Dies liegt daran, dass die SetVerifyOutput-Klasse den Gültigkeitsbereich überschritten hat.
Alternativ können Sie das gleiche Ergebnis erzielen, indem Sie Verify.OutputSettings = VerifyOutputSettings.LogOnlyFailures vor den Verify-Vorgängen festlegen, wie das folgende Beispiel zeigt.
Verify.OutputSettings = VerifyOutputSettings.LogFailuresAsWarnings
try
{
Verify.AreSame(item1, item2);
Verify.AreEqual(item1, item2);
}
finally
{
Verify.OutputSettings = VerifyOutputSettings.None;
}
Beachten Sie, dass das Deklarieren von SetVerifyOutput als Objekt in einem using-Block auch wenn eine solche Option verfügbar ist, immer noch die empfohlene Option ist.
Es gibt die folgenden Optionen zum Festlegen der Überprüfungsausgabe:
VerifyOutputSettings.LogOnlyFailures
Es werden nur fehlgeschlagene Überprüfungsaufrufe protokolliert. alle erfolgreichen Aufrufe werden ignoriert.
VerifyOutputSettings.LogFailuresAsBlocked
Protokollieren Sie alle Fehler als blockiert, anstatt einen Fehler zu protokollieren.
VerifyOutputSettings.LogFailuresAsWarnings
Protokollieren Sie alle Fehler als Warnungen, anstatt einen Fehler zu protokollieren.
Überprüfen Sie, ob die Ausgabeeinstellungen oder zusammen sein können, um mehrere Einstellungen zu aktivieren:
using (new SetVerifyOutput(VerifyOutputSettings.LogFailuresAsBlocked | VerifyOutputSettings.LogOnlyFailures))
{
...
}
Verwenden des Skripts überprüfen
Die Überprüfungs-API wird auch für Skriptsprachen angezeigt, die den gleichen Verwendungsmustern wie C++ und C# folgen.
Installation
Wenn Sie die skriptfähigen Überprüfungs-API's innerhalb einer TAEF-Testmethode verwenden, ist keine Installation erforderlich. Die erforderlichen API's werden mit "Registrierung free COM" registriert. Um die skriptfähige API außerhalb einer TAEF-Testmethode (außerhalb von TAEF oder in einem untergeordneten Prozess) zu verwenden, registrieren Sie einfach die Te.Common.dll Binärdatei mithilfe von regsvr32 an einer Eingabeaufforderung mit erhöhten Rechten; Zum Beispiel:
regsvr32 Te.Common.dll
Bei der Bereitstellung von TAEF mithilfe einer Bereitstellungsdatei für die Labausführung wird Te.Common.dll automatisch registriert.
Verwendung
Die skriptfähigen Überprüfungs-API's werden über "TE. Common.Verify' COM-Klasse – einfach diese Klasse instanziieren und Methoden aufrufen – die Verify-Klasse funktioniert automatisch mit WEXLogger, um Pass- und Fail-Überprüfungen in das Protokoll zu schreiben.
1 <?xml version="1.0" ?>
2 <?component error="false" debug="false"?>
3 <package>
4 <component id="Example">
5 <object id="Log" progid="Wex.Logger.Log" />
6 <object id="Verify" progid="Te.Common.Verify" />
7 <reference guid="e65ef678-a232-42a7-8a36-63108d719f31" version="1.0"/>
8 <reference guid="f8bb9db9-e54e-4555-b3e5-e3ddf2fef401" version="1.0"/>
9
10 <public>
11 <method name="HelloWorld"/>
12 </public>
13
14 <script language="JScript">
15 function HelloWorld() {
16 Verify.IsTrue(true);
17 Verify.IsFalse(false);
18 }
19 </script>
20 </component>
21 </package>
In diesem Beispiel wird eine TAEF-Skripttestklasse mit einer einzelnen "HelloWorld"-Methode definiert. Zeile 6 verwendet das Objektelement, um die Variable Verify im globalen Bereich zu definieren. Zeile 8 verwendet das Verweiselement, um alle Konstanten aus der angegebenen Typbibliothek (in diesem Fall die Typbibliothek Te.Common.dll) in den globalen Bereich des Skripts einzuschließen. in diesem Fall werden die Konstanten "VerifySettings" hinzugefügt. In den Zeilen 16 und 17 wird die einfache Verwendung der Prüf-API angezeigt. Wenn das Beispiel ausgeführt wird, wird die folgende Ausgabe generiert:
Test Authoring and Execution Framework v2.7 Build 6.2.7922.0 (fbl_esc_end_dev(mschofie).110202-1000) For x86
StartGroup: Example::HelloWorld
Verify: IsTrue
Verify: IsFalse
EndGroup: Example::HelloWorld [Passed]
Summary: Total=1, Passed=1, Failed=0, Blocked=0, Not Run=0, Skipped=0
Skriptfähige Überprüfungs-API
Die Methoden für die Überprüfung für die skriptfähige Überprüfungs-API sind wie folgt:
| Methode | Funktionalität |
|---|---|
| bool Verify.AreEqual(expected, actual, [optional message]) | Überprüft, ob die beiden Werte gleich sind. Wenn die Einstellung "VerifySettings_CoerceTypes" aktiviert ist, verwendet diese Methode die JScript-Definition der Gleichheit. Wenn die Einstellung "VerifySettings_CoerceTypes" nicht aktiviert ist, verwendet die Methode die JScript-Definition der Identität. "VerifySettings_CoerceTypes" ist standardmäßig aktiviert. |
| bool Verify.AreNotEqual(expected, actual, [optional message]) | Überprüft, ob die beiden Werte nicht gleich sind. Wenn die Einstellung "VerifySettings_CoerceTypes" aktiviert ist, verwendet diese Methode die JScript-Definition der Gleichheit. Wenn die Einstellung "VerifySettings_CoerceTypes" nicht aktiviert ist, verwendet die Methode die JScript-Definition der Identität. "VerifySettings_CoerceTypes" ist standardmäßig aktiviert. |
| bool Verify.IsGreaterThan(expectedGreater, expectedLess, [optionale Nachricht]) | Überprüft, ob der erste Wert größer als der zweite ist. |
| bool Verify.IsGreaterThanOrEqual(expectedGreater, expectedLess, [optionale Nachricht]) | Überprüft, ob der erste Wert größer oder gleich dem zweiten wert ist. |
| bool Verify.IsLessThan(expectedLess, expectedGreater, [optionale Nachricht]) | Überprüft, ob der erste Wert kleiner als der zweite ist. |
| bool Verify.IsLessThanOrEqual(expectedLess, expectedGreater, [optionale Nachricht]) | Überprüft, ob der erste Wert kleiner oder gleich dem zweiten wert ist. |
| bool Verify.AreSame(expected, actual, [optional message]) | Überprüft, ob die Werte identisch sind. |
| bool Verify.AreNotSame(expected, actual, [optional message]) | Überprüft, ob die Werte nicht identisch sind. |
| bool Verify.Fail([optionale Nachricht]) | Schlägt fehl, ohne die Bedingungen zu überprüfen. |
| bool Verify.IsTrue(expression, [optional message]) | Überprüft, ob der angegebene Ausdruck als "true" ausgewertet wird. |
| bool Verify.IsFalse(expression, [optionale Nachricht]) | Überprüft, ob der angegebene Ausdruck als false ausgewertet wird. |
| bool Verify.IsNull(expected, [optionale Nachricht]) | Überprüft, ob der angegebene Wert "NULL" ist. |
| bool Verify.IsNotNull(expected, [optionale Nachricht]) | Überprüft, ob der angegebene Wert nicht "NULL" ist. |
| bool Verify.Throws(function, [optionale Nachricht]) | Überprüft, ob die angegebene Funktion ausgelöst und eine Ausnahme auslöst. |
| bool Verify.NoThrow(function, [optional message]) | Überprüft, ob die angegebene Funktion keine Ausnahme auslöst. |
Es gibt zwei Methoden für die Verify-Klasse zum Steuern der Einstellungen:
| Methode | Funktionalität |
|---|---|
| object Verify.EnableSettings(settings) | Das angegebene Einstellungsflag bzw. die angegebenen Flags werden aktiviert. |
| object Verify.DisableSettings(settings) | Das angegebene Einstellungsflag bzw. die angegebenen Flags werden deaktiviert. |
Der Einstellungswert, der an die Methoden Verify.EnableSettings oder Verify.DisableSettings übergeben wird, kann einer der folgenden Werte sein:
VerifySettings_LogOnlyFailures = 0x01
Es werden nur Fehler protokolliert. Bei erfolgreichen Überprüfungsaufrufen gibt es keine Ausgabe.
VerifySettings_LogFailuresAsBlocked = 0x02
Fehler werden als "Blockiert" anstelle des Standardfehlers protokolliert.
VerifySettings_LogFailuresAsWarnings = 0x04
Fehler werden als "Warnung" anstelle des Standardfehlers protokolliert.
VerifySettings_LogValuesOnSuccess = 0x08
Die Werte der zu überprüfenden Parameter werden als Teil der Meldung "Protokoll überprüfen" geschrieben. Dies ist standardmäßig aktiviert.
VerifySettings_CoerceTypes = 0x1000
Die an die Verify-Methoden übergebenen Werte werden nach den JScript-Coercion-Regeln zwangsgezwingt. Dies ist standardmäßig aktiviert.
VerifySettings_DisableExceptions = 0x2000
Ausnahmen werden nicht ausgelöst, wenn eine Überprüfung fehlschlägt.
Einstellungen überprüfen
Die Überprüfungs-API stellt Einstellungen bereit, um ihr Verhalten zu konfigurieren. Die Methoden "EnableSettings" und "DisableSettings" können verwendet werden, um bestimmte Einstellungen zu aktivieren oder zu deaktivieren, die die Verify-Klasse verwaltet. Die Methoden verwenden mindestens eine Einstellung, um diese zu aktivieren oder zu deaktivieren.
Verify.EnableSettings(VerifySettings_LogOnlyFailures);
Um mehrere Einstellungen in einem Anruf zu aktivieren oder zu deaktivieren, können Sie mehrere "VerifySettings"-Flags einschließen:
Verify.EnableSettings(VerifySettings_LogOnlyFailures | VerifySettings_DisableExceptions);
Die Methoden EnableSettings und DisableSettings geben ein Objekt zurück, das zum Wiederherstellen der ursprünglichen Einstellungen verwendet werden kann, sodass Einstellungen für einen bestimmten Bereich aktiviert oder deaktiviert werden können.
1 var guard = Verify.EnableSettings(VerifySettings_LogOnlyFailures);
2 try
3 {
4 Verify.AreEqual(10, 0xa);
5 }
6 finally
7 {
8 guard.Restore();
9 }
In diesem Beispiel wird die Verify.EnableSettings-Methode "VerifySettings_LogOnlyFailures" übergeben, die in die Einstellungen integriert wird, die bereits für das Verify-Objekt vorhanden sind. Innerhalb eines Try-finally-Blocks wird ein Verify-Aufruf ausgeführt, sodass während des endgültigen Blocks das "guard"-Objekt verwendet werden kann, um die ursprünglichen Einstellungen wiederherzustellen.
Ausnahmebasierte Überprüfung der Nutzung
Standardmäßig lösen die Verify-Methoden eine Ausnahme aus, wenn eine Überprüfung fehlschlägt. Wenn sie unter TAEF ausgeführt wird, wenn die Ausnahme aus der Testmethode ausgelöst wird, ist der Test fehlgeschlagen. Beispiel:
1 var guard = Verify.EnableSettings(VerifySettings_CoerceTypes);
2 try
3 {
4 Verify.AreEqual(1, "1");
5 Verify.AreEqual("1", 1);
6 }
7 finally
8 {
9 guard.Restore();
10 }
In diesem Beispiel wird der zweite Überprüfungsaufruf nie ausgeführt, da der erste eine Ausnahme auslöst und den Test fehlschlägt. Die Einstellungsunterstützung für die Überprüfungs-API kann verwendet werden, um dieses Verhalten zu ändern, sodass fehlerhafte Überprüfungen nicht ausgelöst werden, sodass nachfolgende Überprüfungsaufrufe ausgeführt werden können. Dies ist besonders nützlich, um eine Reihe von Parametern zu überprüfen und sicherzustellen, dass alle Überprüfungen ausgeschrieben sind.
1 var guard = Verify.EnableSettings(VerifySettings_CoerceTypes | VerifySettings_DisableExceptions);
2 try
3 {
4 Verify.AreEqual(1, "1");
5 Verify.AreEqual("1", 1);
6 }
7 finally
8 {
9 guard.Restore();
10 }
Da Ausnahmen deaktiviert wurden, werden beide Überprüfungen in das Protokoll geschrieben.
Verwenden der skriptfähigen Überprüfungs-API außerhalb von TAEF
Die skriptfähige Überprüfungs-API kann außerhalb von TAEF verwendet werden. Stellen Sie sicher, dass die Te.Common.dll registriert ist, wie im Abschnitt Installation angegeben, und erstellen Sie einfach "TE. Common.Verify"-Klasse.
var VerifySettings_DisableExceptions = 0x2000;
var Verify = new ActiveXObject("TE.Common.Verify");
var Log = new ActiveXObject("WEX.Logger.Log");
Verify.EnableSettings(VerifySettings_DisableExceptions);
Log.StartGroup("Group A");
Verify.AreEqual(1, 2);
Log.EndGroup("Group A");
Log.StartGroup("Group B");
Verify.AreEqual(2, 2);
Log.EndGroup("Group B");
Der obige Code generiert die folgende Konsolenausgabe, wenn sie über cscript ausgeführt wird:
StartGroup: Group A
Error: Verify: AreEqual - Values (1, 2)
EndGroup: Group A [Failed]
StartGroup: Group B
Verify: AreEqual - Values (2, 2)
EndGroup: Group B [Passed]
Non-passing Tests:
Group A [Failed]
Summary: Total=2, Passed=1, Failed=1, Blocked=0, Not Run=0, Skipped=0
Die "WEX. Logger.Log' API kann verwendet werden, um die WEX-Protokollierung nach Bedarf zu konfigurieren (z. B. als untergeordneter Prozess), und die skriptfähige Überprüfungs-API nutzt diese Konfiguration.