Pruebas unitarias aplicadas a métodos privados

Question

Actualmente estoy intentando crear algunas clases para hacer algunas Transformaciones de Fourier. Estoy tratando de hacerlo creando primero algunas pruebas unitarias, luego construyo la funcionalidad básica.

El problema con esto es que, bueno, puedo escribir una prueba para ver si el algoritmo funciona, y sé el resultado esperado. Luego empiezo a construir el gran algoritmo, y si funciona, las pruebas de mi unidad pasarán.

Mi problema aquí es que realmente no es TDD. Porque generalmente creas pruebas que prueban una característica muy básica de una clase. Ahora, básicamente, mi clase ejecuta un gran algoritmo y no puedo probar las partes más pequeñas del algoritmo, ya que no son públicas (siempre me han dicho que nunca querría probar métodos privados).

¿Cómo lidiar con esto?

Answer 1

veo 2 maneras posibles:

1. Si es posible - para mover la implementación del algoritmo a otra clase, que se dividió a los métodos. Métodos de prueba después
2. Simplemente escriba una serie de pruebas que cubran posibles casos normales, casos extremos y casos de error.

Answer 2

Recientemente he estado batallando con "¿Qué es una unidad?" que es una pregunta difícil de hecho.

Si tiene motivos para creer que las subunidades de una FFT son particularmente propensas a errores, ajuste las condiciones de contorno y rompa la regla de que los métodos privados están exentos.

Otra forma de decir lo mismo es que la unidad secundaria es en realidad una unidad cuyos servicios son utilizados por la FFT, y entonces no está infringiendo ninguna regla.

Answer 3

Creo que si no pudo probar componentes individuales de su algoritmo, el código está muy acoplado o el código es muy procesal.

Puede que tenga que definir su código como unidades y hacer estas unidades como método protegido. Siempre que el método esté protegido, envía un mensaje claro de que no es parte de la API.

Answer 4

Bueno, si su clase solo tiene un único método comprobable (según su criterio de solo probar métodos públicos), entonces no tiene más remedio que probar solo ese método, ¿no? Sin embargo, eso no significa que no sea TDD, y ciertamente puede probar una gran variedad de valores de entrada. La mayor parte del trabajo aquí será encontrar los valores interesantes: ¿cuáles son los casos límite en los que puede fallar su transformación? ¿Hay alguna entrada no válida y cómo se maneja?

¿Existe alguna manera de validar algorítmicamente muchos valores, como llamar a una rutina bien conocida, usar alguna identificación clave relacionada con Fourier, o tal vez usar su FFT para hacer multiplication?