Verificar estrutura

Para facilitar a escrita de testes, o TAEF fornece a estrutura "Verificar" que aproveita o WexLogger para relatar logs detalhados com uma quantidade mínima de código. A estrutura Verificar ajuda os Testes a fornecer saída de log estruturada - produz um log bem-sucedido se uma determinada verificação for bem-sucedida e produz informações detalhadas se uma verificação falhar.

Usando Verificar a partir de C++

A API de verificação é apresentada em C++ como um conjunto de macros definidas no arquivo de cabeçalho "Verify.h" (Observação: você não precisa incluir explicitamente Verify.h, você deve incluir "WexTestClass.h", que contém tudo o que você precisa para marcar testes C++ e interagir com as APIs Verify e WexLogger).

As seguintes macros de verificação estão disponíveis para testes C++ nativos:

Verificação de Uso Baseada em Exceções

Se o código-fonte for compilado com exceções C++ habilitadas (especificando a opção de linha de comando "/EHsc" ou a macro "USE_NATIVE_EH=1" em um arquivo de códigos-fonte), as macros Verify usarão como padrão registrar um erro em caso de falha, seguido de lançar uma exceção C++ nativa. A exceção lançada é um WEX::TestExecution::VerifyFailureException. Não precisa de apanhar esta exceção - o framework TAEF irá apanhá-la para si e passar para o caso de teste seguinte.

Opcionalmente, se você quiser executar uma série de verificações seguidas em vez de abortar o teste na primeira falha de verificação, você pode usar a classe DisableVerifyExceptions . O tempo de vida do objeto controla a quantidade de tempo que as exceções são desabilitadas.

if (NULL != m_key)
{
    DisableVerifyExceptions disable;
    VERIFY_WIN32_SUCCEEDED(::RegDeleteKey(HKEY_CURRENT_USER, zTempName));
    VERIFY_WIN32_SUCCEEDED(::RegCloseKey(m_key));
}

No exemplo acima, as exceções são desabilitadas apenas dentro do bloco "if (NULL != m_key)" e, se a primeira chamada de verificação falhar, a segunda chamada de verificação ainda será feita.

A classe DisableVerifyExceptions é contabilizada por referência e também funciona por base de thread.

Uso de verificação não baseado em exceções

Se o código-fonte não for compilado com exceções C++ habilitadas, as macros Verificar não lançarão um C++ nativo quando as verificações falharem. Além disso, se o código-fonte for compilado com exceções C++ habilitadas, mas você quiser desabilitar Verificar exceções, basta #define NO_VERIFY_EXCEPTIONS antes de incluir "WexTestClass.h".

Neste modelo, deve-se executar uma série de instruções if aninhadas para controlar o fluxo do caso de teste, em vez de depender das exceções de C++.

if (VERIFY_WIN32_SUCCEEDED(::RegDeleteKey(HKEY_CURRENT_USER, zTempName)))
{
    ...
}

Verificar configurações de saída

Se quiser personalizar a saída produzida pelas APIs de verificação, você pode usar a classe SetVerifyOutput . O tempo de vida do objeto controla a quantidade de tempo que as configurações de saída são definidas. A classe SetVerifyOutput é controlada por contagem de referências e funciona com base em cada 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");

No exemplo acima, as configurações especificadas referem-se apenas a chamadas feitas dentro do bloco "if (NULL != m_key)" e somente a chamada de verificação que falhar será registrada. No entanto, a terceira chamada de verificação será registrada mesmo que seja bem-sucedida. Isso se deve ao fato de que a classe SetVerifyOutput saiu do escopo.

Existem as seguintes opções para definir a saída de verificação:

VerifyOutputSettings::LogOnlyFailures
Somente chamadas de verificação com falha serão registradas; Todas as chamadas bem-sucedidas são ignoradas.

VerifyOutputSettings::LogFailuresAsBlocked
Registre todas as falhas como bloqueadas em vez de registrar um erro.

VerificarConfiguraçõesDeSaída::RegistarFalhasComoAvisos
Registre todas as falhas como avisos em vez de registrar um erro.

VerifyOutputSettings::LogValuesOnSuccess
Registre os valores dos parâmetros passados, mesmo quando a chamada Verificar for bem-sucedida.

Verifique se as configurações de saída podem ser OU juntas para habilitar várias configurações:

SetVerifyOutput verifySettings(VerifyOutputSettings::LogOnlyFailures | VerifyOutputSettings::LogFailuresAsBlocked);

Fornecendo saída de valor para tipos personalizados

A estrutura C++ Verify fornece a capacidade de gerar saída detalhada para qualquer tipo personalizado. Para fazer isso, é preciso implementar uma especialização do modelo de classe WEX::TestExecution::VerifyOutputTraits .

A especialização do modelo de classe WEX::TestExecution::VerifyOutputTraits deve existir no namespace WEX::TestExecution . Também é esperado que forneça um método estático público chamado ToString, que usa uma referência à sua classe e retorna um WEX::Common::NoThrowString contendo uma representação de cadeia de caracteres de seu valor.

    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());
            }
        };
    }}

Fornecendo comparadores para tipos personalizados

A estrutura C++ Verify fornece a capacidade de definir comparadores para tipos personalizados que não implementam sobrecargas de operador correspondentes (operator=, operator<, etc). Para fazer isso, é preciso implementar uma especialização do modelo de classe WEX::TestExecution::VerifyCompareTraits .

A especialização do modelo de classe WEX::TestExecution::VerifyCompareTraits deve existir no namespace WEX::TestExecution . Também se espera que forneça métodos estáticos públicos chamados AreEqual, AreSame, IsLessThan, IsGreaterThan e IsNull.

    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;
            }
        };
    }}

Utilizando o Verify do C#

O uso do C# Verify é semelhante ao do C++. No entanto, é fornecido através do WEX. TestExecution.Verify classe, que está localizada dentro Te.Managed.dll.

Os seguintes métodos Verify estão disponíveis para testes C#:

Verificação de uso baseada em exceção

Quando ocorrem falhas de verificação em casos de teste C#, um erro é gravado no registador e uma WEX.TestExecution.VerifyFailureException é lançada. Assim como no modelo C++ nativo, você não precisa se preocupar em capturar essas exceções. A estrutura TAEF irá capturá-lo por si e passar para o próximo caso de teste.

Opcionalmente, se você quiser executar uma série de verificações seguidas em vez de abortar o teste na primeira falha de verificação, você pode usar a classe DisableVerifyExceptions . O tempo de vida do objeto controla a quantidade de tempo que as exceções são desabilitadas. A classe DisableVerifyExceptions é referenciada e funciona numa base por thread.

using (new DisableVerifyExceptions())
{
    Verify.AreSame(item1, item2);
    Verify.AreEqual(item1, item2);
}

No exemplo acima, se a primeira chamada de verificação falhar, a segunda chamada de verificação ainda será feita.

Como alternativa, você pode obter o mesmo resultado definindo Verify.DisableVerifyExceptions = true antes das operações Verify como o exemplo mostrado abaixo.

Verify.DisableVerifyExceptions = true;
try
{
    Verify.AreSame(item1, item2);
    Verify.AreEqual(item1, item2);
}
finally
{
    Verify.DisableVerifyExceptions = false;
}

Observe que, embora essa opção esteja disponível, declarar DisableVerifyExeptions como um objeto em um bloco de uso ainda é a opção recomendada.

Se você quiser parar no depurador quando ocorrer um erro de verificação, abra a caixa de diálogo de exceções (Ctrl+Alt+E), clique em Adicionar, escolha "Common Language Runtime Exceptions" na lista suspensa e coloque "WEX. TestExecution.VerifyFailureException" no campo Nome.

Verificar configurações de saída

Se quiser personalizar a saída produzida pelas APIs de verificação, você pode usar a classe SetVerifyOutput . O tempo de vida do objeto controla a quantidade de tempo que as configurações de saída são definidas. A classe SetVerifyOutput tem um contador de referências e funciona com base em cada 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");

No exemplo acima, apenas a segunda chamada de verificação deve ser registrada, pois é a única chamada que falha dentro do bloco de uso. No entanto, a terceira chamada de verificação será registrada mesmo que seja bem-sucedida. Isso se deve ao fato de que a classe SetVerifyOutput saiu do escopo.

Como alternativa, você pode obter o mesmo resultado definindo Verify.OutputSettings = VerifyOutputSettings.LogOnlyFailures antes das operações Verify como o exemplo mostrado abaixo.

Verify.OutputSettings = VerifyOutputSettings.LogFailuresAsWarnings
try
{
    Verify.AreSame(item1, item2);
    Verify.AreEqual(item1, item2);
}
finally
{
    Verify.OutputSettings = VerifyOutputSettings.None;
}

Observe que, embora essa opção esteja disponível, declarar SetVerifyOutput como um objeto em um bloco de uso ainda é a opção recomendada.

Existem as seguintes opções para definir a saída de verificação:

VerificarConfiguraçõesDeSaída.RegistarApenasFalhas
Somente chamadas de verificação com falha serão registradas; Todas as chamadas bem-sucedidas são ignoradas.

VerificarDefiniçõesDeSaída.RegistarFalhasComoBloqueadas
Registre todas as falhas como bloqueadas em vez de registrar um erro.

VerificarDefiniçõesDeSaída.RegistarFalhasComoAvisos
Registre todas as falhas como avisos em vez de registrar um erro.

Verifique se as configurações de saída podem ser combinadas utilizando 'OU' para ativar várias opções.

using (new SetVerifyOutput(VerifyOutputSettings.LogFailuresAsBlocked | VerifyOutputSettings.LogOnlyFailures))
{
...
}

Utilizar Verificar a partir do script

A API de verificação também é exibida para linguagens de script, seguindo os mesmos padrões de uso que C++ e C#.

Instalação

Ao usar as APIs de verificação programáveis de dentro de um método de teste TAEF, nenhuma instalação é necessária - as APIs necessárias são registradas usando 'Registration Free COM'. Para utilizar a API programável fora de um método de teste TAEF (fora do TAEF ou num processo secundário), basta registar o binário Te.Common.dll utilizando o regsvr32 a partir de um prompt de comando elevado; por exemplo:

regsvr32 Te.Common.dll

Ao implantar o TAEF usando um arquivo de implantação para execução em laboratório, Te.Common.dll é registrado automaticamente.

Utilização

As APIs de verificação programáveis são exibidas através do 'TE. A classe COM do Common.Verify - basta instanciar essa classe e chamar métodos nela - a classe Verify funcionará automaticamente com WEXLogger para gravar verificações de aprovação e falha no log.

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>

Este exemplo define uma classe de teste de script TAEF com um único método 'HelloWorld'. A linha 6 usa o elemento 'object' para definir a variável Verify no escopo global. A linha 8 usa o elemento 'reference' para incluir todas as constantes da biblioteca de tipos especificada (neste caso, a biblioteca de tipos de Te.Common.dll) no escopo global do script; neste caso, adiciona as constantes 'VerifySettings'. As linhas 16 e 17 mostram simplesmente o uso das APIs de verificação. Quando executado, o exemplo gerará a seguinte saída:

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

API de verificação programável

Os métodos para validação na API de verificação programável são os seguintes:

Há dois métodos na classe Verify para controlar as configurações:

O valor de configurações passado para os métodos Verify.EnableSettings ou Verify.DisableSettings pode ser qualquer um dos seguintes valores:

VerifySettings_LogOnlyFailures = 0x01
Somente falhas são registradas - não há saída em chamadas de verificação bem-sucedidas.

VerifySettings_LogFailuresAsBlocked = 0x02
As falhas são registadas como 'Bloqueado', em vez de 'Erro', que é o padrão.

VerifySettings_LogFailuresAsWarnings = 0x04
As falhas são registradas como 'Aviso', em vez do padrão 'Erro'.

VerifySettings_LogValuesOnSuccess = 0x08
Os valores dos parâmetros a serem verificados são anotados como parte da mensagem de verificação de log. Isso está ativado por padrão.

VerifySettings_CoerceTypes = 0x1000
Os valores passados para os métodos Verify serão coagidos seguindo as regras de coerção JScript. Isso está ativado por padrão.

VerifySettings_DisableExceptions = 0x2000
Não serão lançadas exceções quando uma validação falhar.

Verificar configurações

A API de verificação fornece configurações para configurar seu comportamento. Os métodos 'EnableSettings' e 'DisableSettings' podem ser usados para habilitar ou desabilitar configurações específicas que a classe Verify mantém. Os métodos usam uma ou mais configurações para habilitar ou desabilitar.

    Verify.EnableSettings(VerifySettings_LogOnlyFailures);

Para ativar ou desativar várias configurações em uma chamada, você pode incluir vários sinalizadores 'VerifySettings':

    Verify.EnableSettings(VerifySettings_LogOnlyFailures | VerifySettings_DisableExceptions);

Os métodos EnableSettings e DisableSettings retornam um objeto que pode ser usado para restaurar as configurações originais, permitindo que as configurações sejam habilitadas ou desabilitadas para um determinado escopo;

1    var guard = Verify.EnableSettings(VerifySettings_LogOnlyFailures);
2    try
3    {
4        Verify.AreEqual(10, 0xa);
5    }
6    finally
7    {
8        guard.Restore();
9    }

Neste exemplo, o método Verify.EnableSettings é passado para 'VerifySettings_LogOnlyFailures', que será incorporado às configurações já presentes no objeto Verify. Uma chamada Verify é feita dentro de um bloco try-finally para que, durante o bloqueio final, o objeto 'guard' possa ser usado para restaurar as configurações originais.

Verificação de uso com base em exceção

Por padrão, os métodos Verify lançarão uma exceção quando uma verificação falhar. Ao ser executado sob TAEF se a exceção for descartada do método de teste, o teste será reprovado. Por exemplo:

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   }

Neste exemplo, a segunda chamada Verificar nunca será feita, pois a primeira lançará uma exceção e falhará no teste. O suporte às configurações na API de verificação pode ser usado para alterar esse comportamento, para que as verificações com falha não sejam lançadas, o que permitiria que chamadas subsequentes de verificação fossem feitas. Isso é particularmente útil para verificar um conjunto de parâmetros e certificar-se de que todas as verificações são gravadas.

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   }

Como as exceções foram desabilitadas, ambas as verificações serão gravadas no log.

Usando a API de verificação programável fora do TAEF

A API de verificação programável pode ser usada fora do TAEF. Certifique-se de que o Te.Common.dll está registado, como está descrito na seção Instalação, e simplesmente crie a classe "TE.Common.Verify".

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");

O código anterior gerará a seguinte saída do console quando executado através do cscript:

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

A API 'WEX.Logger.Log' pode ser usada para configurar o WEX Logger conforme necessário (por exemplo, como um processo filho), e a API Verify programável aproveitará essa configuração.