1. LINK DEL TEXTO

<http://esj.com/Articles/2012/09/24/Better-Unit-Testing.aspx?p=1>

2. GUIDELINES

1) SEPA LO QUE ESTA PROBANDO:
	 Una prueba escrita sin un objetivo claro en mente es fácil de detectar. 
   Este tipo de prueba es larga, difícil de entender y, por lo general, 
   prueba más de una cosa.

2) LAS PRUEBAS UNITARIAS DEBEN SER AUTOSUFICIENTES:
   Una buena prueba unitaria debe estar aislada. Evite dependencias como 
   la configuración del entorno, los valores de registro o las bases de datos.
   Una sola prueba no debe depender de la ejecución de otras pruebas antes de 
   ella, ni debe verse afectada por el orden de ejecución de otras pruebas. 
   Ejecutar la misma prueba unitaria 1000 veces debería arrojar el mismo resultado
   cada vez.

3) LAS PRUEBAS DEBEN SER DETERMINISTAS:
   La peor prueba es la que pasa parte del tiempo. Una prueba debe pasar 
   todo el tiempo o fallar hasta que se solucione. Tener una prueba unitaria 
   que pasa parte del tiempo es equivalente a no tener ninguna prueba.

4) CONVENCIONES DE NOMENCLATURA:
   Para saber por qué falló una prueba, debemos poder entenderla de un 
   vistazo. Lo primero que nota sobre una prueba fallida es su nombre: 
   el nombre del método de prueba es muy importante. Cuando falla una prueba 
   bien nombrada, es más fácil comprender qué se probó y por qué falló.

5) REPITASE:
   En el código de producción, debe evitar la duplicación porque causa 
   problemas de mantenimiento. La legibilidad es muy importante en las 
   pruebas unitarias, por lo que es aceptable tener código duplicado. 
   Evitar la duplicación en las pruebas crea pruebas que son difíciles de 
   leer y comprender:

6) RESULTADOS DE LA PRUEBA, NO IMPLEMENTACION:
	 Las pruebas unitarias exitosas requieren pruebas de escritura que solo 
   fallarían en caso de un error real o un cambio de requisito. Hay algunas 
   reglas que ayudan a evitar escribir pruebas unitarias frágiles. 
   Estas son pruebas que fallarían debido a un cambio interno en el software 
   que no afecta al usuario.

   Dado que el mismo desarrollador que escribió el código y sabe cómo se 
   implementó la solución, generalmente escribe pruebas unitarias, es difícil 
   no probar el funcionamiento interno de cómo se implementó una característica. 
   El problema es que la implementación tiende a cambiar y la prueba fallará 
   incluso si el resultado es el mismo.

7) EVITE LA ESPECIFICACION EXCESIVA:
   Es tentador crear una prueba bien definida, controlada y estricta que 
   observe el flujo exacto del proceso durante la prueba configurando cada 
   objeto y probando cada aspecto que se prueba. El problema es que esto 
   "bloquea" el escenario bajo prueba, impidiendo que cambie de forma que 
   no afecte el resultado.

8) USE UN MARCO DE AISLAMIENTO:
   Escribir buenas pruebas unitarias puede ser difícil cuando la clase bajo 
   prueba tiene dependencias internas o externas. Para ejecutar una prueba, 
   es posible que necesite una conexión a una base de datos completa o un 
   servidor remoto. En algunos casos, es posible que deba crear instancias 
   de una clase compleja creada por otra persona.

   Estas dependencias dificultan la capacidad de escribir pruebas unitarias. 
   Cuando tales dependencias necesitan una configuración compleja para que 
   se ejecute la prueba automatizada, el resultado son pruebas frágiles 
   que se rompen, incluso si el código bajo prueba funciona perfectamente.