Cada vez que empiezo a trabajar con un nuevo equipo, tarde o temprano teminamos hablando de pruebas unitarias. Al mismo tiempo es un tema que dicto en mis materias de Ingeniería de Software. Pero dado que no he encontrado un material que cubra el tema de una forma que me resulte 100% convincente, he decidido escribir esta guía. Aquí va la primera parte.

Las pruebas unitarias son una pieza fundamental para controlar la calidad del software que desarrollamos. A diferencia de lo que ocurre con otros tipos de pruebas, en el caso de la pruebas unitarias hay un concenso absoluto en que las mismas son responsabilidad del desarrollador.

Entre los beneficios que nos proveen las pruebas unitarias se cuentan:

• Ayudan a encontrar problemas rápidamente, ya que por su naturaleza operan sobre una porción puntual y acotada de código
• Actúan como un mecanismo de seguridad a la hora de hacer modificaciones en el código, facilitando así el desarrollo iterativo
• Son en cierto modo documentación ejecutable lo cual a la largo plazo facilita la evolución del código

Estando entonces convencidos que queremos hacer pruebas unitarias, comencemos por dejar en claro que NO es una prueba unitaria. Según Michael Feather a test is not a unit test if:

• It talks to the database
• It communicates across the network
• It touches the file system
• It can’t run at the same time as any of your other unit tests
• You have to do special things to your environment (such as editing config files) to run it.

En términos más generales una prueba unitaria prueba un elemento en forma aislada, siendo ese elemento típicamente un objeto o un método.

Continuará…