Corrientes de pensamiento sobre las pruebas
Hay una gran cantidad de instrucciones a la hora de realizar pruebas. Vamos a cubrir algunas de las escuelas comunes de reflexión que suelen recomendar los desarrolladores experimentados.
Desarrollo controlado por pruebas (TDD)
El desarrollo controlado por pruebas, o TDD, es un método de acoplamiento directo de las pruebas con cada parte del desarrollo diario. Los desarrolladores que usan TDD normalmente empiezan el desarrollo escribiendo primero una prueba que produce un error y, a continuación, el código que hace que la prueba se pase. Este enfoque significa que es más probable que el código del producto obtenga una cobertura de prueba alta y que las pruebas suelen ser las primeras.
Muchos desarrolladores encuentran este patrón útil para ayudarles a priorizar una buena arquitectura desde el principio del desarrollo y para centrarse en cada parte de la funcionalidad que necesitan implementar. Esta escuela de reflexión es promotora de que las pruebas no sean una idea posterior al desarrollo, sino un impulsor.
Por ejemplo, en la siguiente imagen, puede ver que AddTest está escrito y con errores mientras el método Add todavía no se ha implementado. Esta prueba producirá un error hasta que se implemente el método.
Hay un tipo de TDD denominado Red/Green/Refactor. Es bueno saber sobre eso porque aporta más orden a este proceso. Funcionamiento:
- Escriba una prueba "roja" con errores.
- Agregue el código de producto necesario para asegurarse de que la prueba se supera o se vuelve "verde".
- "Refactorizar" ahora que tiene la funcionalidad correcta.
En el siguiente diagrama se ofrece un objeto visual del tipo de TDD.
Desarrollo basado en el comportamiento (BDD)
El desarrollo basado en el comportamiento (o BDD) es similar a TDD, pero con mayor atención en el uso de pruebas de aceptación para guiar el desarrollo en un nivel alto. Es posible que trabaje con sus clientes, asociados comerciales o administradores de programas para definir un conjunto de pruebas que enumera los criterios necesarios para el producto. Estas pruebas son descripciones de mayor nivel de funcionalidad que pruebas unitarias y están más orientadas a la empresa.
BDD puede usar muchas herramientas diferentes, pero todas tienden a centrarse en documentar diferentes fases de expectativas para la funcionalidad (por ejemplo, consulte los comentarios en la siguiente captura de pantalla de una prueba). Las pruebas BDD también pueden enumerar el ámbito de lo que se espera. En el ejemplo básico siguiente, los comentarios especifican que esta aplicación solo se espera que agregue dos números.
Una vez y solo una (DRY)
Una vez y solo una, también conocido como DRY, es otra práctica en el campo de las pruebas. DRY afirma que debe evitar repetir la información y la lógica en cualquier lugar que pueda. Puede evitar la repetición abstrayendo la información y respetando un "origen de verdad", en lugar de mantener varias copias de la misma lógica.
Por ejemplo, supongamos que está escribiendo pruebas unitarias para diferentes constructores, pero está reutilizando muchos de los parámetros para varias pruebas. Puede escribir un método auxiliar de pruebas que mantenga todas las entradas de parámetros en un solo lugar, para que se puedan llamar y modificar más fácilmente para todas las pruebas. Este es un ejemplo de reducción de la duplicación, por lo que no lo olvide «una vez y solo una».
Elegir lo que mejor se adapte a sus necesidades
En última instancia, debe elegir las prácticas que mejor le funcionen y lo conviertan en el programador más eficaz. Puede ser diferente para todos, ya que todos creemos y solucionamos problemas de maneras diferentes. No se preocupe si el TDD es demasiado intenso o no se ajusta a su proyecto en particular. Es posible que el equipo en el que está trabajando tenga mejores instrucciones sobre las prácticas que funcionan mejor específicamente para su base de código. Realice algunas investigaciones y busque algo que sea una buena opción para usted.