Hace un tiempo en un webcast de la comunidad ágil de Venezuela mencioné la importancia de que todo programador sea responsable de escribir las pruebas unitarias de su código, lo cual es absolutamente independiente del lenguaje de programación utilizado ya que para hacer pruebas no es necesario contar con ninguna herramienta particular. Ante esta afirmación una persona de la audiencia consulto ¿afirmas que es posible escribir pruebas unitarias sin usar un framework de pruebas unitarias? La respuesta es si. Veamos un ejemplo.
Básicamente una prueba unitaria consta de 3 pasos conocidos como las 3A.
- Arrange: es la preparación de todo lo necesario para realizar la prueba
- Act: es la ejecutación de la prueba
- Assert: es verificación de que el resultado obtenido es acorde a lo esperado
De estos tres pasos el único que depende del framework de pruebas unitarias es el assert. Generalmente el framework de pruebas unitarias provee uno o varios métodos del tipo assertXXXX que verifican el valor de verdad de una expresión y en base a ello arrojan un resultado.
Esta funcionalidad del assert de framework de pruebas unitarias bien podría ser reemplazada por una función similar a la siguiente
public void verificar(boolean expresion){
if(!expresion)
throw new RuntimeException();
}
Vemos cómo podríamos utilizar esta función para hacer un prueba de la clase ArrayList.
public void deberiaCrearseVacio(){
// arrange & act
ArrayList array = new ArrayList();
// assert
verificar(array.size()==0);
}
Para aquellos interesados en profundizar, aquí les dejo un ejemplo completo en Java que muestra como codificar y ejecutar las pruebas.
Blog de NicoPaez 
Si bien es verdad que las 3A son los tres elementos de una prueba unitaria y «en teoría» se podría prescindir de un Framework, la familia xUnit (y sus vecinos) provee bastantes más cosas, con las que escribir pruebas unitarias es posible, pero poco más que una tortura. Por nombrar algunas:
– Reporte de fallas y errores
– Ejecución de tests parametrizados (para poder correr el mismo test con distintos tipos de entrada)
– Integración con IDEs
– Integración con frameworks de mocking, stubbing, etc.
Por otro lado, estos Frameworks presentan, en general, unas interfaces con muy buen diseño, por lo que son una excelente manera de aprender sobre el diseño de buenas APIs.
Estoy de acuerdo con tus observaciones. Este ejemplo no apuntaba a no usar un framework de pruebas unitarias, sino a mostrar que no es necesario el framework, pues hay gente que ve el no tener un framework como un impedimento para hacer las pruebas, lo cual es falso.