Unit Testers Get More Chicks

En mi nuevo trabajo el cliente pide todos los desarrollos con pruebas unitarios. ¿Que son las pruebas unitarias? De wikipedia:

En programación, una prueba unitaria es una forma de probar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. Luego, con las Pruebas de Integración, se podrá asegurar el correcto funcionamiento del sistema o subsistema en cuestión. La idea es escribir casos de prueba para cada función no trivial o método en el módulo de forma que cada caso sea independiente del resto.

Para que una prueba unitaria sea buena se deben cumplir los siguientes requisitos:

• Automatizable: no debería requerirse una intervención manual.
• Completas: deben cubrir la mayor cantidad de código.
• Repetibles o Reutilizables: no se deben crear pruebas que sólo puedan ser ejecutadas una sola vez. También es útil para integración continua.
• Independientes: la ejecución de una prueba no debe afectar a la ejecución de otra.
• Profesionales: las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación, etc.

Aunque estos requisitos no tienen que ser cumplidos a rajatabla, se recomienda seguirlos o de lo contrario las pruebas pierden parte de su función.

Luego encontré un articulo muy entretenido que es de un desarrollador que cree que convertirse en un desarrollador orientado a pruebas unitarias (test-driven) es lo mejor que puede hacer para mejorar su rutina, y estas son sus razones:

1. Though counterintuitive, I swear that it makes you code faster. No one tends to believe me on this, but most test-driven developers come to this realization eventually. The reason is simple: you spend much less time debugging the 935 errors from your two-hour code sprees.
2. The tests are my memory. My head is too full of all the languages, frameworks, APIs, and family birthdays I am expected to know to remember everything I’ve ever done on top of that. This week at work I’ve touched three separate projects all with over 1,000 lines of code. I’m sure I had good ideas when I wrote those lines, but now I doubt I can tell you what they are. My tests can though. They remember so I don’t have to. If I go into the code and change something I don’t remember was needed or why, my tests will remind me immediately.
3. In team development, my test-powered memory even travels to the machines of the other developers! How cool is that? When someone goes into the code and says, “Why on Earth did James do this? We don’t need this. I’m going to change that…” my tests will look after my interests for me.
4. I’m a lot more confident in my software. I use to say things like, “I just finished this, so it hasn’t been used much yet and probably still has plenty of issues.” Now by the time I finish something my tests have been using the heck out of it. I won’t kid you and tell you that my software now springs fully formed from the head of my tests, but it definitely comes out farther along the track.
5. Environment changes seldom surprise me anymore. When I move my software to a different box and it can’t cope for whatever reason, I not only know the first time I run the tests, I have an excellent idea of exactly where the problem is.