Pruebas unitarias de aplicaciones empresariales

Las aplicaciones móviles tienen problemas únicos que las aplicaciones de escritorio y basadas en web no tienen. Los usuarios móviles variarán según los dispositivos que usen, por conectividad de red, por la disponibilidad de los servicios y por una variedad de otros factores. Por lo tanto, las aplicaciones móviles deben probarse ya que se usarán en el mundo real para mejorar su calidad, confiabilidad y rendimiento. Hay muchos tipos de pruebas que se deben realizar en una aplicación, incluidas las pruebas unitarias, las pruebas de integración y las pruebas de interfaz de usuario, y las pruebas unitarias son la forma más común de pruebas.

Una prueba unitaria toma una pequeña unidad de la aplicación, normalmente un método, lo aísla del resto del código y comprueba que se comporta según lo previsto. Su objetivo es comprobar que cada unidad de funcionalidad funciona según lo previsto, para que los errores no se propaguen en toda la aplicación. Detectar un error donde se produce es más eficaz que observar el efecto de un error indirectamente en un punto de error secundario.

Las pruebas unitarias tienen un mayor efecto en la calidad del código cuando son parte integral del flujo de trabajo de desarrollo de software. En cuanto se haya escrito un método, se deben escribir pruebas unitarias que comprueben el comportamiento del método en respuesta a casos de datos de entrada estándar, límites e incorrectos, y que comprueben las suposiciones explícitas o implícitas realizadas por el código. Como alternativa, con el desarrollo controlado por pruebas, las pruebas unitarias se escriben antes que el código. En este escenario, las pruebas unitarias actúan como documentación de diseño y especificaciones funcionales.

Las pruebas unitarias suelen usar el patrón organizar-actuar-afirmar:

• La sección arrange de un método de prueba unitaria inicializa objetos y establece el valor de los datos que se pasa al método en pruebas.
• La sección act invoca al método objeto de las pruebas con los argumentos necesarios.
• La sección assert comprueba si la acción del método en pruebas se comporta de la forma prevista.

Si sigue este patrón, se garantiza que las pruebas unitarias sean legibles y coherentes.

Inserción de dependencias y pruebas unitarias

Una de las motivaciones para adoptar una arquitectura de acoplamiento flexible es que facilita las pruebas unitarias. Uno de los tipos registrados con Autofac es la clase OrderService. En el ejemplo de código siguiente, se muestra un esquema de esta clase:

public class OrderDetailViewModel : ViewModelBase  
{  
    private IOrderService _ordersService;  

    public OrderDetailViewModel(IOrderService ordersService)  
    {  
        _ordersService = ordersService;  
    }  
    ...  
}

La clase OrderDetailViewModel tiene una dependencia del tipo IOrderService que el contenedor resuelve cuando crea una instancia de un objeto OrderDetailViewModel. Sin embargo, en lugar de crear un objeto OrderService para hacer las pruebas unitarias de la clase OrderDetailViewModel, reemplace el objeto OrderService por un objeto ficticio con fines de prueba. La figura 10-1 ilustra esta relación.

Figura 10-1: Clases que implementan la interfaz IOrderService

Este enfoque permite pasar el objeto OrderService a la clase OrderDetailViewModel en tiempo de ejecución y, en interés de la capacidad de prueba, permite pasar una clase OrderMockService a la clase OrderDetailViewModel en tiempo de pruebas. La principal ventaja de este enfoque es que permite ejecutar pruebas unitarias sin necesidad de recursos pesados, como los servicios web o las bases de datos.

Prueba de aplicaciones MVVM

Probar modelos y ver modelos de aplicaciones MVVM es idéntico a probar cualquier otra clase y se usan las mismas herramientas y técnicas; como las pruebas unitarias y la simulación. Sin embargo, algunos patrones típicos para modelar y ver las clases del modelo se pueden beneficiar de técnicas específicas de las pruebas unitarias.

La aplicación móvil eShopOnContainers realiza pruebas unitarias, que admite dos tipos diferentes de pruebas unitarias:

• Los hechos son pruebas que siempre son verdaderas, que prueban condiciones invariables.
• Las teorías son pruebas que solo son verdaderas para un conjunto determinado de datos.

Las pruebas unitarias incluidas con la aplicación móvil eShopOnContainers son pruebas de hechos, por lo que cada método de la prueba unitaria está decorado con el atributo [Fact].

Prueba de la funcionalidad asincrónica

Al implementar el patrón MVVM, los modelos de vista suelen invocar operaciones en servicios, a menudo de forma asincrónica. Las pruebas del código que invoca estas operaciones suelen usar simulaciones como sustitución de los servicios reales. En el ejemplo de código siguiente, se muestra cómo probar la funcionalidad asincrónica pasando un servicio ficticio a un modelo de vista:

[Fact]  
public async Task OrderPropertyIsNotNullAfterViewModelInitializationTest()  
{  
    var orderService = new OrderMockService();  
    var orderViewModel = new OrderDetailViewModel(orderService);  

    var order = await orderService.GetOrderAsync(1, GlobalSetting.Instance.AuthToken);  
    await orderViewModel.InitializeAsync(order);  

    Assert.NotNull(orderViewModel.Order);  
}

Esta prueba unitaria comprueba que la propiedad Order de la instancia de OrderDetailViewModel tenga un valor después de invocar al método InitializeAsync. Se invoca al método InitializeAsync cuando se navega a la vista correspondiente del modelo de vista. Para más información sobre la navegación, consulte Navegación.

Cuando se crea la instancia de OrderDetailViewModel, se espera que se especifique una instancia de OrderService como argumento. Sin embargo, OrderService recupera datos de un servicio web. Por lo tanto, se especifica una instancia de OrderMockService, que es una versión ficticia de la clase OrderService, como argumento para el constructor OrderDetailViewModel. A continuación, se recuperan datos ficticios en lugar de comunicarse con un servicio web cuando se invoca al método InitializeAsync del modelo de vista, que usa operaciones de IOrderService.

Prueba de implementaciones de INotifyPropertyChanged

La implementación de la interfaz INotifyPropertyChanged permite que las vistas reaccionen ante los cambios que se originan en los modelos de vista y los modelos. Estos cambios no se limitan a los datos que se muestran en los controles; también se usan para controlar la vista, como los estados del modelo de vista que hacen que se inicien las animaciones o se deshabiliten los controles.

Las propiedades que se pueden actualizar directamente mediante la prueba unitaria se pueden probar adjuntando un controlador de eventos al evento PropertyChanged y comprobando si se genera el evento después de establecer un nuevo valor para la propiedad. En el ejemplo de código siguiente, se muestra una prueba de este tipo:

[Fact]  
public async Task SettingOrderPropertyShouldRaisePropertyChanged()  
{  
    bool invoked = false;  
    var orderService = new OrderMockService();  
    var orderViewModel = new OrderDetailViewModel(orderService);  

    orderViewModel.PropertyChanged += (sender, e) =>  
    {  
        if (e.PropertyName.Equals("Order"))  
            invoked = true;  
    };  
    var order = await orderService.GetOrderAsync(1, GlobalSetting.Instance.AuthToken);  
    await orderViewModel.InitializeAsync(order);  

    Assert.True(invoked);  
}

Esta prueba unitaria invoca al método InitializeAsync de la clase OrderViewModel, lo que hace que se actualice su propiedad Order. Se superará la prueba unitaria, siempre que se genere el evento PropertyChanged para la propiedad Order.

Prueba de la comunicación basada en mensajes

Los modelos de vista que usan la clase MessagingCenter para comunicarse entre clases de acoplamiento flexible se pueden probar de forma unitaria mediante la suscripción al mensaje enviado por el código objeto de las pruebas, como se muestra en el ejemplo de código siguiente:

[Fact]  
public void AddCatalogItemCommandSendsAddProductMessageTest()  
{  
    bool messageReceived = false;  
    var catalogService = new CatalogMockService();  
    var catalogViewModel = new CatalogViewModel(catalogService);  

    Xamarin.Forms.MessagingCenter.Subscribe<CatalogViewModel, CatalogItem>(  
        this, MessageKeys.AddProduct, (sender, arg) =>  
    {  
        messageReceived = true;  
    });  
    catalogViewModel.AddCatalogItemCommand.Execute(null);  

    Assert.True(messageReceived);  
}

Esta prueba unitaria comprueba que CatalogViewModel publique el mensaje AddProduct en respuesta a la ejecución de su método AddCatalogItemCommand. Dado que la clase MessagingCenter admite suscripciones de mensajes de multidifusión, la prueba unitaria puede suscribirse al mensaje AddProduct y ejecutar un delegado de devolución de llamada en respuesta a su recepción. Este delegado de devolución de llamada, especificado como una expresión lambda, establece un campo boolean utilizado por la instrucción Assert para comprobar el comportamiento de la prueba.

Prueba del control de excepciones

También se pueden escribir pruebas unitarias que comprueben que se generen excepciones específicas para acciones o entradas no válidas, como se muestra en el ejemplo de código siguiente:

[Fact]  
public void InvalidEventNameShouldThrowArgumentExceptionText()  
{  
    var behavior = new MockEventToCommandBehavior  
    {  
        EventName = "OnItemTapped"  
    };  
    var listView = new ListView();  

    Assert.Throws<ArgumentException>(() => listView.Behaviors.Add(behavior));  
}

Esta prueba unitaria producirá una excepción porque el control ListView no tiene un evento llamado OnItemTapped. El método Assert.Throws<T> es un método genérico donde T es el tipo de la excepción esperada. El argumento pasado al método Assert.Throws<T> es una expresión lambda que producirá la excepción. Por lo tanto, se superará la prueba unitaria siempre que la expresión lambda produzca una excepción ArgumentException.

Prueba de la validación

Hay dos aspectos para probar la implementación de la validación: probar que las reglas de validación se hayan implementado correctamente y probar que la clase ValidatableObject<T> se comporta según lo previsto.

La lógica de validación suele ser sencilla de probar, ya que normalmente es un proceso autocontenido en el que la salida depende de la entrada. Debe haber pruebas de los resultados de invocar al método Validate en cada propiedad que tenga al menos una regla de validación asociada, como se muestra en el ejemplo de código siguiente:

[Fact]  
public void CheckValidationPassesWhenBothPropertiesHaveDataTest()  
{  
    var mockViewModel = new MockViewModel();  
    mockViewModel.Forename.Value = "John";  
    mockViewModel.Surname.Value = "Smith";  

    bool isValid = mockViewModel.Validate();  

    Assert.True(isValid);  
}

Esta prueba unitaria comprueba que la validación se realice correctamente cuando las dos propiedades ValidatableObject<T> de la instancia de MockViewModel tienen datos.

Además de comprobar que la validación se realice correctamente, las pruebas unitarias de la validación también deben comprobar los valores de las propiedades Value, IsValid y Errors de cada instancia de ValidatableObject<T> para comprobar que la clase funciona según lo previsto. En el ejemplo de código siguiente, se muestra una prueba unitaria que hace esto:

[Fact]  
public void CheckValidationFailsWhenOnlyForenameHasDataTest()  
{  
    var mockViewModel = new MockViewModel();  
    mockViewModel.Forename.Value = "John";  

    bool isValid = mockViewModel.Validate();  

    Assert.False(isValid);  
    Assert.NotNull(mockViewModel.Forename.Value);  
    Assert.Null(mockViewModel.Surname.Value);  
    Assert.True(mockViewModel.Forename.IsValid);  
    Assert.False(mockViewModel.Surname.IsValid);  
    Assert.Empty(mockViewModel.Forename.Errors);  
    Assert.NotEmpty(mockViewModel.Surname.Errors);  
}

Esta prueba unitaria comprueba que se produce un error en la validación cuando la propiedad Surname de MockViewModel no tiene ningún dato y las propiedades Value, IsValid y Errors de cada instancia de ValidatableObject<T> se han establecido correctamente.

Resumen

Una prueba unitaria toma una pequeña unidad de la aplicación, normalmente un método, lo aísla del resto del código y comprueba que se comporta según lo previsto. Su objetivo es comprobar que cada unidad de funcionalidad funciona según lo previsto, para que los errores no se propaguen en toda la aplicación.

Se puede aislar el comportamiento de un objeto sometido a prueba reemplazando los objetos dependientes por objetos ficticios que simulan el comportamiento de los objetos dependientes. Esto permite ejecutar pruebas unitarias sin necesidad de recursos pesados, como los servicios web o las bases de datos.

Probar modelos y modelos de vista de aplicaciones MVVM es idéntico a probar cualquier otra clase y se pueden usar las mismas herramientas y técnicas.

Vínculos relacionados

• Descargar libro electrónico (PDF de 2 MB)
• eShopOnContainers (GitHub) (muestra)