Compartir a través de


Hacer la mayor parte de TAEF

Test Authoring and Execution Framework proporciona una plataforma eficaz para crear y ejecutar las pruebas. Puede ser beneficioso comprender algunos detalles en segundo plano del funcionamiento de TAEF con el fin de sacar el máximo partido. En esta página se describen algunas sugerencias y características que le ayudarán a crear sus pruebas para optimizar y sacar el máximo partido de lo que TAEF tiene que ofrecer. Asegúrese de que está familiarizado con los conceptos básicos de las pruebas de creación y ejecución con TAEF.

Configuración (o inicialización) y métodos de limpieza

Los métodos de instalación y limpieza en el nivel de ensamblado (también conocidos como accesorios), se ejecutan una vez por cada ejecución de DLL. Del mismo modo, los métodos de configuración y limpieza de nivel de clase se ejecutan una vez por clase. Los métodos de configuración y limpieza de nivel de prueba son los mismos para todas las pruebas de una clase y se invocan una vez antes y después de cada prueba de la clase .

Solo puede haber un método de instalación y limpieza de nivel de ensamblado por ensamblado, una configuración de nivel de clase y un método de limpieza por clase, y un método de instalación y limpieza de prueba por clase. Tenga en cuenta que los métodos de instalación y limpieza de clases son estáticos en código administrado, pero no son estáticos en el código de C++.

Si las excepciones están habilitadas (el caso predeterminado), la ejecución de cualquier método finaliza en la primera llamada Verify que produce un error. Si ha deshabilitado explícitamente las llamadas Verify basadas en excepciones (consulte la sección Comprobar en Pruebas de creación para obtener más información), deberá tener instrucciones condicionales explícitas para controlar el flujo de control después de que se produzca un error en una llamada a Verify.

En el caso de que el error se produzca en un método de instalación (ya sea a través de un error de comprobación basado en excepciones o mediante la configuración que devuelve explícitamente un error), las pruebas que se deben seguir se consideran "Bloqueadas" y se registran como tal. Por ejemplo, si se produce un error en el método de instalación de nivel de clase, todos los métodos de prueba de la clase se consideran "Bloqueados" y cada uno de ellos se registrará como tal. Además de eso, no se invocará el método Cleanup si el error se produce en un método de instalación.

Test (método)

No es necesario registrar explícitamente el resultado de la prueba. Si todas las llamadas Verify de la prueba se realizaron correctamente, la prueba se registrará como "Superada". En la primera llamada a Verify que produce un error, la ejecución del método de prueba finalizará (a menos que haya deshabilitado explícitamente las llamadas Verify basadas en excepciones; en cuyo caso las instrucciones condicionales determinarán el flujo de control allí después, pero independientemente de las siguientes suspensiones) y la prueba se marcará como "Failed".

Del mismo modo, si tiene un contenedor VERIFY (depende del tipo de valor devuelto y de lo que determina el éxito) en torno a una llamada de invocación de método auxiliar, no tendrá que comprobar explícitamente y registrar su resultado.

Especificación de metadatos

La búsqueda de metadatos es jerárquica. Esto significa que si la instrucción select es /select:"@Priority=2" y si el TestMethod no especifica Priority, TAEF buscará la clase que lo contiene. Si los metadatos de nivel de clase no lo especifican, TAEF busca en el nivel de ensamblado.

Por lo tanto, si desea que todas o la mayoría de las pruebas de la clase tengan la misma "Prioridad", o bien diga "Propietario, puede obtenerlo simplemente especificando en el nivel de clase. Para las pruebas que son una excepción a esta regla, puede proporcionar explícitamente los metadatos en el nivel "TestMethod". Consulte la prueba siguiente para obtener más información:

1    namespace WEX { namespace UnitTests { namespace Samples
2    {
3        //
4        // Declare module level properties
5        //
6        BEGIN_MODULE() //This metadata applies to all the classes and tests in this module or assembly
7            MODULE_PROPERTY(L"GroupOwner", L"SomeGroup")
8        END_MODULE()
9        class PremiumBankAccountTests
10       {
11           //
12           // Declare this class to be a test class with an'advanced' declaration
13           // Use advanced declaration when you want to set metadata on the class
14           //
15           BEGIN_TEST_CLASS(PremiumBankAccountTests) //This metadata applies to all the test in this class
16               TEST_CLASS_PROPERTY(L"Priority", L"2")
17               TEST_CLASS_PROPERTY(L"DevOwner", L"Someone")
18               TEST_CLASS_PROPERTY(L"PMOwner", L"Someone")
19           END_TEST_CLASS()
20           //
21           // Declare class setup - a method that runs after class constructor
22           // and before any test class methods and test setup method
23           //
24           TEST_CLASS_SETUP(SetDefaultAccountType);
25           //
26           // Declare class cleanup - a methods that runs after all the class test methods and test setup method
27           // and before the class destructor
28           //
29           TEST_CLASS_CLEANUP(ResetDefaultAccountType);
30           //
31           // Declare test setup and cleanup - methods that run before and after the execution
32           // of every test method correspondingly
33           //
34           TEST_METHOD_SETUP(CreateBankAccount);
35           TEST_METHOD_CLEANUP(DestroyBankAccount);
36           //
37           // Declare test methods with an 'advanced' declaration
38           // Use advanced declaration when you want to set metadata on the methods
39           //
40           BEGIN_TEST_METHOD(DebitTest)
41               TEST_METHOD_PROPERTY(L"BVT", L"TRUE")
42               TEST_METHOD_PROPERTY(L"PERF", L"TRUE")
43               TEST_METHOD_PROPERTY(L"STRESS", L"FALSE")
44               TEST_METHOD_PROPERTY(L"Priority", L"1") //Overrides the Class level Priority value
45           END_TEST_METHOD()
46           BEGIN_TEST_METHOD(CreditTest)
47               TEST_METHOD_PROPERTY(L"BVT", L"TRUE")
48               TEST_METHOD_PROPERTY(L"PERF", L"FALSE")
49               TEST_METHOD_PROPERTY(L"STRESS", L"TRUE")
50               TEST_METHOD_PROPERTY(L"GroupOwner", L"SomeGroupTest") //Overrides the GroupOwner specified at the Module level
51           END_TEST_METHOD()
52   
53           std::unique_ptr<BankAccount> m_spBankAccount;
54           BankAccountType m_defaultType;
55       };
56   } /* namespace Samples */ } /* namespace UnitTests */ } /* namespace WEX */

NOTA: Para las pruebas administradas, la creación se realiza de forma similar. El nivel de módulo es el mismo que el marcado de nivel de ensamblado en administrado. Para la especificación de metadatos de nivel de ensamblado o de nivel de clase en código administrado, el marcado debe proporcionarse antes de los métodos de inicializador estáticos. Esto puede significar que es posible que tenga que proporcionar un inicializador vacío si la prueba aún no tiene una. Este diseño se ha diseñado específicamente para garantizar la compatibilidad con VSTS.

En el caso de las pruebas basadas en datos basadas en tablas, puede realizar este paso más allá e invalidar los metadatos de nivel de prueba especificandolos en el nivel de fila. Consulte El ejemplo de prueba controlada por datos de invalidación de metadatos para obtener más información.