La nomenclatura sobre tests puede ser francamente caótica. Ha sido fuente de discusión en los últimos años y sigue sin existir universalmente de manera categórica. Cada equipo tiende a adoptar sus propias convenciones, ya que existen distintos aspectos a considerar para denominar tests. Por aspecto quiero decir que, según cómo se mire, el test se puede clasificar de una manera o de otra.
Así se habla, por ejemplo, del aspecto visibilidad (si se sabe lo que hay dentro del SUT o no), del aspecto potestad (a quién pertenece el test), etc. Dale H. Emery hace una extensa recopilación de los posibles aspectos o puntos de vista y los tipos que alberga cada uno de ellos. No es la única que existe, ni sus definiciones son extensas, pero nos da una idea de la complejidad del problema.
Michael Feathers también enumera varias clasificaciones de tests en un post reciente. Por su parte, la Wikipedia aporta otro punto de vista complementario a los anteriores.
Definitivamente, cada comunidad usa unos términos diferentes. Una comunidad podría ser la de los que practicamos TDD, y otra podría ser la de los que escriben tests para aplicaciones ya implementadas que todavía no los tienen, por ejemplo.
Un mismo test puede ser de varios tipos, incluso mirándolo desde la perspectiva de un solo equipo de desarrollo ya que su clasificación dependerá del aspecto a considerar. No existen reglas universales para escribir todos y cada uno de los tipos de tests ni sus posibles combinaciones. Es una cuestión que llega a ser artesanal.
Sin embargo, más allá de los términos, es conveniente que tengamos una idea de cómo es cada tipo de test, según las convenciones que hayamos elegido, para ser coherentes a la hora de escribirlos. Cada vez que vamos a programar un test, tenemos que estar seguros de por qué lo escribimos y de qué estamos probando. Es extremadamente importante tener claro qué queremos afirmar con cada test y por qué lo hacemos de esa manera.
Podría ser que el hecho de no saber determinar qué tipo de test vamos a programar, indique que no estamos seguros de por qué lo escribimos. Dicho de otro modo, si no conseguimos darle nombre a lo que hacemos, quizás no sepamos por qué lo hacemos. Probablemente no tengamos claro el diseño que queremos, o puede que el test no esté probando lo que debe, o que no estemos delimitando responsabilidades adecuadamente,o quizás estemos escribiendo más tests de los que son necesarios. Es una heurística a tener en cuenta.
En el ámbito de TDD no hablamos de tests desde el aspecto visibilidad (típicamente tests de caja blanca y caja negra). Usamos otros términos, pero sabemos que un test de caja negra podría coincidir con un test unitario basado en el estado. Y un test de caja blanca podría coincidir con un test unitario basado en la interacción. No es una regla exacta porque, dependiendo de cómo se haya escrito el test, puede que no sea unitario sino de integración. Lo importante es ser capaces de entender la naturaleza de los tests.
En la siguiente sección veremos los términos más comunes dentro de la comunidad TDD y sus significados.