Pruebas de mutación con el ejemplo: Cómo aprovechar el fracaso

| |

COMPARTE EL ARTÍCULO!!!

Utilice el fallo planificado para asegurarse de que su código cumple con los resultados esperados y siga el marco de pruebas de .NET xUnit.net.

En mi artículo La prueba de mutación es la evolución de TDD , expuse el poder de la iteración para garantizar una solución cuando una prueba medible está disponible. En ese artículo, un enfoque iterativo ayudó a determinar cómo implementar código que calcula la raíz cuadrada de un número dado.

También demostré que el método más efectivo es encontrar una meta o prueba mensurable, y luego empezar a iterar con las mejores conjeturas. La primera conjetura en la respuesta correcta muy probablemente fallará, como se esperaba, así que la conjetura fallida necesita ser refinada. La conjetura refinada debe ser validada contra el objetivo o prueba medible. Basado en el resultado, la conjetura es validada o debe ser refinada.

En este modelo, la única manera de aprender a alcanzar la solución es fallar repetidamente. Suena contraintuitivo, pero sorprendentemente, funciona.

Siguiendo los pasos de ese análisis, este artículo examina la mejor manera de utilizar un enfoque DevOps cuando se construye una solución que contiene algunas dependencias. El primer paso es escribir una prueba que se puede esperar que falle.

El problema con las dependencias es que no puede depender de ellas

El problema con las dependencias, como Michael Nygard expresa ingeniosamente en Arquitectura sin un estado final , es un tema enorme que es mejor dejar para otro artículo. En esta sección se analizan los posibles escollos que las dependencias tienden a aportar a un proyecto y cómo aprovechar el desarrollo impulsado por pruebas (TDD) para evitarlos.

En primer lugar, plantee un desafío de la vida real, y luego vea cómo se puede resolver utilizando la DDT.

¿Quién dejó salir al gato?

En entornos de desarrollo ágiles, es útil empezar a construir la solución definiendo los resultados deseados. Típicamente, los resultados deseados se describen en una historia de usuario :

Usando mi sistema domótico (HAS),
Quiero controlar cuando el gato puede salir,
porque quiero mantener al gato a salvo toda la noche.

Ahora que tiene una historia de usuario, necesita explicarla detalladamente proporcionando algunos requisitos funcionales (es decir, especificando los criterios de aceptación ). Comience con el más simple de los escenarios descritos en el pseudo-código:

Escenario #1: Desactivar la trampilla para gatos durante la noche

  • Dado que el reloj detecta que es de noche
  • Cuando el reloj notifica al HAS
  • Entonces HAS desactiva la trampilla para gatos con capacidad para Internet de los objetos (IoT)

Descomponer el sistema

El sistema que está construyendo (el HAS) necesita ser descompuesto -desglosado hasta sus dependencias- antes de que pueda empezar a trabajar en él. Lo primero que debe hacer es identificar cualquier dependencia (si tiene suerte, su sistema no tiene dependencias, lo que lo haría fácil de construir, pero entonces podría decirse que no sería un sistema muy útil).

Desde el simple escenario anterior, se puede ver que el resultado de negocio deseado (controlando automáticamente la puerta de un gato) depende de la detección durante la noche. Esta dependencia depende del reloj. Pero el reloj no es capaz de determinar si es de día o de noche. Depende de ti proporcionar esa lógica.

Otra dependencia en el sistema que estás construyendo es la capacidad de acceder automáticamente a la puerta del gato y habilitarla o deshabilitarla. Es muy probable que esa dependencia dependa de una API proporcionada por la puerta del gato con capacidad de IO.

Fallar rápidamente en la gestión de dependencias

Para satisfacer una dependencia, construiremos la lógica que determina si la hora actual es de día o de noche. En el espíritu de la DDT, comenzaremos con un pequeño fracaso.

Consulte mi artículo anterior para obtener instrucciones detalladas sobre cómo establecer el entorno de desarrollo y los andamios necesarios para este ejercicio. Reutilizaremos el mismo entorno NET y confiaremos en el framework xUnit.net.

A continuación, cree un nuevo proyecto llamado HAS (para el «sistema domótico») y cree un archivo llamado UnitTest1.cs . En este archivo, escriba la primera prueba unitaria fallida. En esta prueba de unidad, describa sus expectativas. Por ejemplo, cuando el sistema funciona, si la hora es las 7pm, entonces el componente responsable de decidir si es de día o de noche devuelve el valor «Nighttime».

Aquí está la prueba unitaria que describe esa expectativa:

usandoSistema;
 >Sistema usandoXunit;

> namespace unittest
{
> clase pública UnitTest1
{
> DayOrNightUtility dayOrNightUtility =new DayOrNightUtility();

> Hecho]
publicvoid Given7pmReturnNighttime()
{
> var expected =»Nighttime»;
var actual = dayOrNightUtility.GetDayOrNight();
Afirmar igual (esperado, real);
}
> }
> }

>

En este punto, usted puede estar familiarizado con la forma y la forma de una prueba unitaria. Un refresco rápido: describa la expectativa dando a la prueba de unidad un nombre descriptivo, Given7pmReturnNighttime , en este ejemplo. Luego, en el cuerpo de la prueba unitaria, se crea una variable llamada expected y se le asigna el valor esperado (en este caso, el valor «Nighttime»). A continuación, a una variable llamada actual se le asigna el valor real (disponible después de que el componente o servicio procese la hora del día).

Más recursos de DevOps

  • ¿Qué es DevOps?
  • La guía de contratación definitiva de DevOps
  • Guía de herramientas de monitorización de DevOps
  • Introducción a DevSecOps
  • Términos de DevOps: 10 conceptos esenciales
  • Últimos artículos de DevOps

Por último, comprueba si se ha cumplido la expectativa afirmando que los valores esperados y los reales son iguales: Assert.igual(esperado, real) .

También puede ver en la lista anterior un componente o servicio llamado dayOrNightUtility . Este módulo es capaz de recibir el mensaje GetDayOrNight y se supone que devuelve el valor del tipo cadena .

Una vez más, en el espíritu de la DDT, el componente o servicio que se describe no se ha construido todavía (simplemente se está describiendo con la intención de prescribirlo más adelante). Su construcción está impulsada por las expectativas descritas.

Crear un nuevo archivo en la carpeta app y darle el nombre DayOrNightUtility.cs . Añada el siguiente código C# a ese archivo y guárdelo:

usandoSistema;
 >Sistema 
 > app de namespace {
   clase pública DayOrNightUtility {
     cadena pública GetDayOrNight(){
       string dayOrNight ="Indeterminado";
       volver día O Noche;
     }
 >  }
 > }

Felicitaciones, ha escrito la primera prueba unitaria fallida. La prueba unitaria esperaba que DayOrNightUtility devolviera el valor de cadena «Nighttime», pero en su lugar recibió el valor de cadena «Undetermined».

Arreglar la prueba de unidad defectuosa

Una forma rápida y sucia de solucionar el problema es sustituir el valor «Indeterminado» por el valor «Nocturno» y guardar el cambio:

usandoSistema;
 >Sistema 
 > app de namespace {
   clase pública DayOrNightUtility {
     cadena pública GetDayOrNight(){
       string dayOrNight ="Nighttime";
       volver día O Noche;
     }
 >  }
 > }

Sin embargo, la codificación rígida de los valores es básicamente engañosa, por lo que es mejor dotar a DayOrNightUtility de cierta inteligencia. Modifique el método GetDayOrNight para incluir alguna lógica de cálculo de tiempo:

serie pública GetDayOrNight(){
    cadena dayOrNight = "Daylight";
    DateTime time = nuevo DateTime();
    if(hora.Hora     dayOrNight = "Nighttime";
    }
 >   volver día O Noche;
  }

>

El método obtiene ahora la hora actual del sistema y compara el valor Hora para ver si es inferior a las 7am. Si lo es, la lógica transforma el valor de la cadena dayOrNight de «Daylight» a «Nighttime». La prueba de la unidad ha pasado.

El inicio de una solución basada en pruebas

Ahora tenemos el comienzo de una prueba de unidad de caso base y una solución viable para nuestra dependencia del tiempo. Hay más de un par de casos por resolver.

En el próximo artículo, voy a demostrar cómo hacer pruebas para detectar las horas de luz diurna y cómo aprovechar los fallos en el camino.

COMPARTE EL ARTÍCULO!!!

Previous

Cómo el club de prótesis impresas en 3D de una universidad proporciona dispositivos para amputados

Un sistema operativo ligero y de un solo usuario para su próximo proyecto doméstico

Next

Deja un comentario

shares