Zen de pruebas unitarias


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

Source: https://habr.com/ru/post/439804/


All Articles