La capacidad de escribir buenas pruebas unitarias es una característica importante de cualquier desarrollador. ¿Pero cómo entender que las pruebas unitarias son correctas? Una buena prueba de unidad es como un buen juego de ajedrez. En nuestro caso, los ajedrecistas son los enfoques que vamos a discutir en esta publicación. No hay mejor jugador de ajedrez en un juego de ajedrez porque todo depende de las posiciones (y un jugador) . Del mismo modo, en las pruebas unitarias no tiene que distinguir un solo enfoque. En otras palabras, debe usar todos los enfoques juntos para obtener el mejor resultado. Entonces, si quieres ganar este juego, entonces bienvenido debajo del corte.
Debut
¿Por qué debo escribir pruebas unitarias?
No tiene que escribir pruebas unitarias a menos que sea una persona con percepción extrasensorial que pueda escribir código sin errores, tenga súper memoria, pueda compilar su código en su cabeza o simplemente le guste el dolor. De lo contrario, definitivamente tiene que escribir pruebas unitarias, ya que disminuyen el recuento de errores en las características nuevas y existentes, reducen el costo y el miedo a cambiar sus características y permiten refactorizar su código. Además, siempre debe ejecutar las pruebas existentes y le recomiendo que preste atención a las herramientas de prueba continua.
¿Qué probar?
Obviamente, en la prueba de unidad está probando el comportamiento de alguna unidad separada (no invocaciones, porque pueden cambiarse más adelante) . Además, establezca como norma cubrir con pruebas unitarias todos los errores que haya encontrado para probar que están solucionados. ¿Qué pasa con la cobertura del código? La cobertura del código no es un objetivo, es solo una medida que lo ayuda a comprender qué parte de la lógica olvidó cubrir con las pruebas unitarias. Sería un gran error cuando decide cubrir cada línea de código con pruebas unitarias.
Mittelspiel
Prueba solo una cosa
No confunda las pruebas unitarias con las pruebas de integración en las que probar más de una cosa es normal. La idea de las pruebas unitarias es demostrar que un módulo de aplicación separado funciona o no. Debe comprender fácilmente y con certeza qué comportamiento en su código falla y cómo solucionarlo. ¿Cuántas afirmaciones debes usar? Uno! El uso de muchas afirmaciones puede ser el olor del código que está probando en más de una cosa. Además, existe la posibilidad de que alguien pueda agregar una nueva afirmación a su prueba en lugar de escribir otra. ¿Y cómo puedes entender cómo se completaron tus otras afirmaciones cuando falló la primera?
Evitar la lógica
Los errores en las pruebas son las cosas más difíciles de encontrar para los desarrolladores. La posibilidad de obtener un error en su código de prueba aumenta a medida que decide agregar lógica a su prueba. Se hace más difícil de leer, comprender y mantener. Usar for , foreach , if , switch y otros operadores en una prueba también puede ser un olor a código que está probando más de una cosa.
AAA
Arrange, Act, Assert es un patrón de uso común que ayuda a organizar su código de prueba en tres fases en consecuencia. Claramente separa lo que se está probando de los pasos de configuración y verificación. Esta es una de las mejores prácticas y hace que su código de prueba sea más fácil de leer y mantener. Dicho esto, no use comentarios AAA en sus pruebas si desea mantener su código limpio y legible. La prueba creada de manera competente expresa la idea AAA incluso sin comentarios.
Seguir con la convención de nomenclatura
Los nombres de las pruebas deben ser descriptivos y comprensibles, no solo para su autor. Hay muchas estrategias de nombres de prueba, pero me gusta la de Roy Osherove : [MethodName_StateUnderTest_ExpectedBehavior] . Tiene toda la información necesaria sobre la prueba en forma formateada. Es fácil seguir esta estrategia para cualquier desarrollador.
Ejemplos:
public void Sum_NegativeNumberAs2ndParam_ExceptionThrown () public void Sum_simpleValues_Calculated () public void Parse_OnEmptyString_ExceptionThrown() public void Parse_SingleToken_ReturnsEqualTokenValue ()
Pero tenga en cuenta que puede tener una convención de nomenclatura que debe seguir en su proyecto actual. No los mezcles.
Preparación de datos de prueba
La construcción de datos de prueba puede generar desorden y sufrimiento en su código de prueba. Puede enfrentar esta situación cuando:
- tiene que cambiar el constructor de su modelo en cada parte del código donde se crea este modelo (esto generalmente ocurre cuando su modelo es inmutable) ;
- tiene muchos duplicados de código al construir sus datos de prueba;
- debe pasar una gran cantidad de "datos mágicos" en el constructor de su modelo (por ejemplo,
new Device("Stub", 10, true, "http"); ) ; - tiene la sensación de que necesita crear una especie de generador de datos aleatorio;
- es difícil para usted crear colecciones de datos de pruebas.
Con esto en mente, debe considerar algunas alternativas comunes: Madre de objeto y [Patrón de construcción fluido]. Estos enfoques también son buenos jugadores de equipo, por lo que pueden usarlos juntos.
No use datos aleatorios, porque su prueba puede ser sensible a algún tipo de valores. Como resultado, puede obtener un mal heisenbug en su prueba que es difícil de encontrar y reproducir.
Aprenda su marco de prueba
Aprenda todos los atributos, aserciones y otras características de su marco de prueba. Le ayuda a hacer que sus pruebas sean más legibles y elegantes. Por ejemplo, en el marco de NUnit puede usar dos modelos de aserciones y puede elegir el que más le guste:
Assert.AreEqual(StatusCode.OK, response.StatusCode);
o
Assert.That(StatusCode.OK, Is.EqualTo(response.StatusCode));
No se olvide de los métodos de configuración y desmontaje, los atributos de TestCase y Category, las afirmaciones de colección. No confunda los parámetros de resultados esperados y reales en las aserciones.
Endspiel
Su código de prueba tiene el mismo privilegio que su código de producción que debe escribir y mantener, no se olvide de los principios SOLID. Además, sus pruebas unitarias deben ser legibles y hay varias razones por las cuales. En primer lugar, la intención de sus pruebas debe ser comprensible y clara. Significa que no tiene que perder el tiempo mientras lee sus exámenes. En segundo lugar, debería ser fácil mantener sus pruebas, detectar y eliminar problemas sin depurar.
Las pruebas unitarias son una filosofía enorme que no se puede discutir solo en una publicación. Aquí expliqué enfoques comunes y preguntas frecuentes relacionadas con las pruebas unitarias. Si desea profundizar más, puede encontrar interesantes estos enlaces:
Blog de Roy Osherove
Libro de Roy Osherove, "El arte de las pruebas unitarias"
Mantén la calma y prueba unitaria