design-patterns - pruebas - tdd ventajas y desventajas

Nunca debería usar métodos, clases y singletons estáticos cuando sigo el paradigma de desarrollo basado en pruebas. (4)

He estado leyendo que los métodos estáticos ... son malos cuando intentas implementar pruebas unitarias

Nunca he leído eso. ¿Podría proporcionar una referencia? Y yo lo disputaría. Uso y prueba de forma estática los métodos (funciones) todo el tiempo y sin problemas.

Editado

Gracias por la referencia a que los Métodos Estáticos son Muerte a Probabilidad : Ese artículo es basura.

El problema básico con los métodos estáticos es que son códigos de procedimiento. No tengo idea de cómo probar el código de procedimiento por unidad.

Esto indica que el autor no sabe mucho acerca de las pruebas unitarias. Por supuesto usted puede hacer una prueba de código de procedimiento.

Durante la creación de instancias, conecto las dependencias con simulacros / amistosos que reemplazan las dependencias reales.

Este es el error clave: la idea de que las pruebas unitarias requieren objetos simulados. No es asi. En cualquier caso, puede pasar los objetos simulados como argumentos al método estático que está probando: la inyección de dependencia no requiere un constructor. Para obtener más información, consulte la respuesta aceptada de la pregunta "Métodos estáticos: cuándo y cuándo no"

Si el método estático llama a otro método estático, no hay manera de anular la dependencia del método llamado.

Cierto pero irrelevante. Si el método estático A llama al método estático B , ese es un detalle de implementación del método A. Así que no tienes por qué tratar de interceptar la llamada a B. Solo trata a A como una unidad.

Supongamos que su aplicación no tiene más que métodos estáticos

Un argumento de paja. Claramente, en el contexto de las pruebas unitarias modernas, estamos hablando de un programa OO con solo algunos métodos estáticos.

He estado leyendo que los métodos estáticos, las clases estáticas y los singletons son malos cuando intentas implementar pruebas de unidad en tu proyecto. Al seguir el paradigma TDD, ¿debo olvidar que alguna vez existieron y nunca volver a usarlos o está bien usarlos algunas veces?

¿Deberías olvidar que alguna vez existieron? No.
¿Debería asegurarse de que su incorporación a su código se realice de tal manera que sean transparentes a la funcionalidad de una clase? Sí.

Para explicar aún más la última parte, en lugar de intentar recuperar un valor de un singleton dentro de su código, intente inicializar el valor dentro de un argumento de constructor. Si su constructor crece demasiado, cree un método de fábrica para la creación, de modo que pueda probar su clase sin usar el singleton. Si eso resulta problemático o su singleton tiene un estado mutable (me daría miedo, pero hey, ese soy yo), intente tenerlo para que su singleton sea tan fácil de incorporar en sus pruebas como sea posible.

No desea tener que crear un archivo de configuración completo solo para probar un método en una clase que calcula la desviación estándar de un bloque de cotizaciones de acciones en un período de 4 horas. Eso es demasiado trabajo. Pero si su singleton está escrito de tal manera que pueda llenarlo con los datos y hacer que otra clase sea responsable de leer en el archivo de configuración y rellenar esos datos, entonces ha hecho grandes avances.

En lo que respecta a los métodos estáticos, diría que son los métodos más fáciles de probar que podría escribir basándose en la condición de que no necesita preocuparse por el estado global. Las estáticas son equivalentes a y = f(x) que parece simplista, pero subraya el hecho de que ninguna transición de estado local puede cambiar la invariante de que para una x dada siempre obtendrás la misma y .

Al igual que con cualquier práctica de ingeniería de software, nunca hay una solución definitiva para cualquier situación. Así que nunca debes descartar métodos estáticos, clases estáticas y singletons. El objetivo de TDD es hacer que su vida sea más fácil, y notará que a medida que trabaje más con TDD, su código será modular, lo que significa que incluso si está utilizando métodos estáticos (... etc), su código seguirá siendo comprobable.

La regla por la que me gusta vivir es: use lo que quiera siempre que su código sea fácil de leer y su diseño sea elegante. Cómo lograr estos 2 depende de ti. Demonios, también podrías usar GOTO si aún puedes entregar código elegante.

Nunca digas nunca: las clases y los métodos estáticos tienen su lugar en tu caja de herramientas.

Dicho esto, si la clase que está tratando de aislar y probar (sujeto bajo prueba o SUT) depende de una clase o método estático, no podrá escribir una prueba que aísle el SUT de esa dependencia estática, cuando su código de prueba se ejecuta aún utilizará la llamada estática. A veces esto está bien, pero a veces desea crear una prueba aislada que pruebe SOLAMENTE la lógica de su SUT sin dependencias (generalmente a través de técnicas de burla o similares).

En general, personalmente uso clases y métodos estáticos con relativa moderación.

Debido a la naturaleza de cómo se implementan los Singletons, presentan un problema similar para aislar un SUT para pruebas de unidad. Además, un cierto porcentaje de desarrolladores de software considera que el concepto de GOF singleton es una mala práctica. Resulta que estoy de acuerdo con este sentimiento, pero casi no hay consenso sobre este tema. Una búsqueda rápida en Google probablemente le dará una buena idea de los pros y los contras del patrón GOF Singleton.