Creación de pruebas en C#
En el ejemplo siguiente se muestra un archivo .cs de C# con una clase de prueba sencilla que muestra el marcado de pruebas de C#. (Tenga en cuenta que este ejemplo es solo para fines demostrativos, por lo que no se compilará ni ejecutará).
1 using Microsoft.VisualStudio.TestTools.UnitTesting;
2 using System;
3 using System.Collections;
4 using WEX.Logging.Interop;
5 using WEX.TestExecution;
6
7 [TestClass]
8 public class ManagedStartMenuTests
9 {
10 [AssemblyInitialize]
11 [TestProperty("Component", "Navigation")]
12 [TestProperty("SubComponent", "StartMenu")]
13 public static void RunModuleSetup(Object context)
14 {
15 defaultPolicy = SetObjectFactoryPolicy(PolicyClassic);
16 }
17
18 [AssemblyCleanup]
19 public static void RunModuleCleanup()
20 {
21 SetObjectFactoryPolicy(defaultPolicy);
22 }
23
24 [ClassInitialize]
25 [TestProperty("TeamOwner", "WEX")]
26 [TestProperty("GroupOwner", "MediaPlayerTest")]
27 public static void TestClassSetup(Object testContext)
28 {
29 objectFactory = new ObjectFactory();
30 }
31
32 [ClassCleanup]
33 public static void TestClassCleanup()
34 {
35 objectFactory.Dispose();
36 }
37
38 [TestInitialize]
39 public void TestMethodSetup()
40 {
41 startMenuObject = objectFactory.CreateObject();
42 }
43
44 [TestCleanup]
45 public void TestMethodCleanup()
46 {
47 startMenuObject.Dispose();
48 }
49
50
51 [TestMethod]
52 [Owner("Someone")]
53 [Priority(0)]
54 public void TestMethod1()
55 {
56 Verify.AreEqual(startMenuObject.size, expectedObjectSize);
57 }
58 }
Para declarar pruebas de c#, TAEF usa el marcado de prueba de VSTS.
Para declarar una clase de prueba en C#, use el atributo [TestClass] en una clase C# normal (Línea 7) y para una declaración de método de prueba, use el atributo [TestMethod] en un método de clase normal (Línea 51).
El marcado de prueba de C# también admite una amplia gama de métodos de configuración y limpieza.
El método estático con el conjunto de atributos [AssemblyInitialize] se ejecuta antes de cualquier otro método de clase y realiza la inicialización del nivel de ensamblado (línea 10). Por lo tanto, hay un método de limpieza de ensamblados, un método estático con el conjunto de atributos [AssemblyCleanup] que se ejecuta después de que se completen todos los demás métodos (línea 18).
Del mismo modo, existen métodos de configuración y limpieza de clases y pruebas. (consulte las líneas 24, 32, 38, 44) A diferencia de en C++, los métodos de configuración y limpieza de clases en código administrado deben ser estáticos.
El marcado de prueba de TAEF C# admite propiedades de prueba, clase y módulo.
Para establecer las propiedades del módulo, establezca atributos en un inicializador de ensamblado (consulte las líneas 11 y 12). De forma similar a establecer propiedades de nivel de clase, establezca propiedades en un inicializador de clase (consulte las líneas 25 y 26). Para una propiedad de nivel de método de prueba, simplemente aplique la propiedad a un método de prueba determinado. (consulte líneas 52 y 53)
Ejecución en VSTS
Nota: para reducir la dependencia de los archivos binarios de VSTS, actualmente los métodos de instalación clase y ensamblado toman Object como primer parámetro.
Si desea ejecutar las pruebas desde VSTS, cambie ese tipo de objeto a TestContext. Tenga en cuenta que esto agregará una dependencia en microsoft.visualstudio.qualitytools.unittestframework.dll y microsoft.visualstudio.qualitytools.resource.dll.
Los pasos son un poco diferentes al ejecutarse en VSTS. Debe configurar la configuración de ejecución de pruebas locales para copiar las dependencias no administradas. Para ello, vaya a:
- Prueba->Editar configuraciones de ejecución de pruebas->Prueba de ejecución local
- Haga clic en Deployment.Escriba los archivos DLL que necesita copiar para cada prueba:
- Wex.Logger.dll
- Wex.Common.dll
- Wex.Common.Managed.dll
- Wex.Communication.dll
- Wex.Logger.Interop.dll
Esto es necesario debido al hecho de que VSTS realiza un nuevo directorio y copia los archivos en cada vez que ejecuta los casos de prueba. Puede ver estos directorios en la máquina como carpeta del mismo nivel en la carpeta del proyecto.
Ejecución de pruebas administradas en el dominio de aplicación predeterminado
De forma predeterminada, para el aislamiento de código de prueba, TAEF ejecuta pruebas administradas en un dominio de aplicación de prueba especial. Sin embargo, cuando se usan dominios de aplicación no predeterminados, los escenarios en los que el código nativo llama a código administrado (por ejemplo, funciones de devolución de llamada nativas consumidas por el código administrado) pueden provocar errores con el mensaje: "No se puede pasar un GCHandle a través de AppDomains". En estos escenarios, obligue a que las pruebas administradas se ejecuten en el dominio de aplicación predeterminado mediante el modificador /defaultAppDomain.
Tenga en cuenta que la ejecución de pruebas administradas en el dominio de aplicación predeterminado no es compatible con los archivos de configuración de ensamblado.
Compatibilidad con métodos de prueba asincrónicos
Los archivos binarios de NetFX 4.5 de TAEF admiten la ejecución de métodos de prueba de TAEF asincrónicos. Esto significa que las pruebas de TAEF marcadas con la palabra clave async pueden esperar operaciones asincrónicas.
Nota No intente aprovechar esta funcionalidad con los archivos binarios NetFX 2.0/3.5 de TAEF; solo los archivos binarios de NetFX 4.5 admiten esta característica.
TAEF admite métodos de prueba void asincrónicos y Task asincrónicos (ambos darán lugar a la misma funcionalidad):
[TestMethod]
public async Task MyAsyncTest()
{
await AsyncAPICall1();
var result = await AsyncAPICall2();
Verify.IsTrue(result);
}
O bien:
[TestMethod]
public async void MyAsyncTest2()
{
await AsyncAPICall1();
var result = await AsyncAPICall2();
Verify.IsTrue(result);
}