¿Es una mala práctica separar las pruebas unitarias para una clase? [cerrado]

Mis clases normalmente tienen un máximo de 5-20 métodos, lo que implica que la clase que tiene las pruebas unitarias tiene aproximadamente el doble de métodos (contando proveedores de datos, configuración, ...)

He pensado separar las pruebas en 2-3 clases, porque incluso si trato de seguir el principio de responsabilidad única, prefiero 2 clases de prueba con 10 métodos cada una, que una con 20.

¿Es una mala práctica? ¿Es bueno tener todas las pruebas para una clase en una sola, aunque la clase de prueba crece en vertical?

Para responder a la pregunta específica, es absolutamente posible que agrupar pruebas en varias clases sea una buena decisión, evento cuando la clase bajo prueba está bien diseñada.

El código de prueba de la unidad es como cualquier otro código: debe seguir buenos principios de diseño ( DRY , GRASP , KISS , SOLID , YAGNI , etc.). Debido a que la lógica que compone el código de prueba es a menudo más simple que la lógica de dominio, muchos de los puntos específicos no aparecerán tanto, pero tenga en cuenta al escribir sus pruebas de todos modos.

Hay un par de principios que vienen a la mente que pueden aplicarse fácilmente al pensar en su pregunta:

Legibilidad

Idealmente, una vez que se escribe una prueba, nunca tiene que volver a mirarla; pero lo mismo puede decirse de cualquier código. La realidad es que los requisitos cambian, por lo que nos encontramos leyendo el código mucho más que escribiéndolo. Incluso cuando haces tu mejor esfuerzo, puedes encontrar que la prueba que escribiste no verificaba lo que pensabas, en ese momento tendrás que volver y descubrir qué estaba mal. Encontrar ese método de prueba en una clase de 40-50 métodos de prueba será difícil, sin mencionar la complicación de nombrar esos métodos para que puedan diferenciarse fácilmente.

Alta cohesión

Cada clase de prueba (como cualquier otra clase) debe tener un enfoque claro. Si tiene muchos casos de prueba diferentes para un método determinado de la clase bajo prueba, como cuando una prueba determinada verifica una sola cosa, coloque esos métodos de prueba en una clase separada y asígnele un nombre para reflejar su enfoque.

Casi no tiene importancia cómo se organizan las pruebas unitarias en comparación con tenerlas en primer lugar.

Un módulo o clase de código comercial es algo que debe comprender como una unidad y desarrollar más. Esa es la razón principal por la que nos esforzamos por hacerlo coherente, fácil de entender en su conjunto, etc. Un conjunto de pruebas es solo una colección de casos que todos deben pasar; No tienen ninguna relación particular entre ellos . Idealmente, nunca más tendrás que lidiar con eso; si lo hace, generalmente es agregar más pruebas que nuevamente no tienen una relación particular con ninguna otra prueba, y nunca se llaman por código de cliente, excepto el marco de prueba de la unidad.

Por lo tanto, la cuestión de cómo organizar las clases que contienen pruebas unitarias es mucho menos crítica que cómo organizar las clases que componen su propia aplicación. No se supone que trates con ellos como una macroestructura bien diseñada de todos modos.

Ponga las pruebas en un archivo. Por lo general, para cada archivo de clase, tendría un archivo de prueba. Por lo general, agregue "Pruebas" al nombre del archivo.

Por ejemplo, si hay una clase llamada "Foo", habría un archivo "FooTests" correspondiente. De esta manera, para cada archivo de código hay una relación 1 a 1 entre el archivo de código y el archivo de prueba.

Esto proporciona coherencia y facilita a los desarrolladores localizar las pruebas y mantenerlas actualizadas. Las pruebas generalmente se excluyen del análisis / métricas de código, por lo que si el archivo es grande, no daña la métrica de salud general del código, por lo que no considero que sea un mal formato tener un archivo de prueba con mucho código de prueba unitaria.

Si decimos que la definición de mala práctica en el desarrollo de software es algo que no te ayuda a lidiar con el cambio y encapsularlo, entonces diría que no mantener tus clases y exámenes en una relación uno a uno es una mala práctica . Es un olor a código que puede surgir debido a las cosas que se mencionan a continuación.

Obviamente, hay excepciones al igual que con cualquier cosa, pero tenlo en cuenta mientras escribes tus exámenes.

Mis clases normalmente tienen un máximo de 5-20 métodos.

Si alguna de sus clases tiene 20 (o un poco menos) métodos, eso me muestra que la clase está haciendo demasiado en primer lugar. Aquí es donde las pruebas unitarias deberían indicarle que es posible que deba desglosar su clase un poco más y distribuir la responsabilidad antes de realizar las pruebas.

En cuanto a mantenerlos en la misma clase o no, sugeriría tratar de mantenerlos en una clase si es posible porque es mejor comprensible: la conexión uno a uno es fácil de entender después de que haya pasado mucho tiempo. Solo por experiencia.

Si ve que las pruebas unitarias son enormes incluso cuando tiene 5 métodos o menos, eso me dice que su código de configuración está haciendo demasiado o que sus objetos son anormalmente grandes .

Si aún no lo ha intentado, consulte el patrón de construcción para construir sus objetos; esto podría reducir drásticamente el código sobre cómo está construyendo sus objetos antes de probarlos. Por lo tanto, hacer la clase de prueba unitaria más corta y menos necesidad de reducirla a más clases.