¿Es el código verificable mejor el código?

Con respecto a la definición común de pruebas unitarias, diría que no. He visto un código simple enrevesado debido a la necesidad de torcerlo para adecuarlo al marco de prueba (por ejemplo, interfaces y IoC en todas partes, lo que hace que las cosas sean difíciles de seguir a través de capas de llamadas de interfaz y datos que deberían ser obvios pasados por magia). Dada la elección entre el código que es fácil de entender o el código que es fácil de probar por unidad, siempre utilizo el código que se puede mantener.

Esto no significa no probar, sino ajustar las herramientas a su medida, no al revés. Hay otras formas de realizar pruebas (pero el código difícil de entender siempre es un código incorrecto). Por ejemplo, puede crear pruebas unitarias que sean menos granulares (por ejemplo, la actitud de Martin Fowler de Martin Fowler es que clase, no un método), o puede golpear su programa con pruebas de integración automatizadas en su lugar. Tal vez no sea tan bonito como su marco de prueba se ilumina con marcas verdes, pero estamos después del código probado, no de la gamificación del proceso, ¿no?

Puede hacer que su código sea fácil de mantener y aún así ser bueno para las pruebas unitarias definiendo buenas interfaces entre ellas y luego escribiendo pruebas que ejerzan la interfaz pública del componente; o podría obtener un mejor marco de prueba (uno que reemplaza las funciones en tiempo de ejecución para burlarse de ellas, en lugar de requerir que el código se compile con las simulaciones en su lugar). Un mejor marco de prueba de unidad le permite reemplazar la funcionalidad GetCurrentTime () del sistema con la suya, en tiempo de ejecución, por lo que no necesita introducir envoltorios artificiales para esto solo para adaptarse a la herramienta de prueba.

  

¿La escritura de código comprobable sigue siendo una buena práctica incluso en ausencia de pruebas?

Lo primero es lo primero, la ausencia de pruebas es un problema mucho más grande que su código que se puede probar o no. No tener pruebas de unidad significa que no ha terminado con su código / función.

Aparte de eso, no diría que es importante escribir código verificable, es importante escribir código flexible . El código inflexible es difícil de probar, por lo que hay mucha superposición en el enfoque y lo que la gente llama.

Para mí, siempre hay un conjunto de prioridades en el código de escritura:

1. Haz que funcione : si el código no hace lo que tiene que hacer, es inútil.
2. Haz que sea mantenible : si el código no es mantenible, dejará de funcionar rápidamente.
3. Hágalo flexible : si el código no es flexible, dejará de funcionar cuando, inevitablemente, el negocio llegue y le preguntará si el código puede hacer XYZ.
4. Hágalo rápido : más allá de un nivel básico aceptable, el rendimiento es simplemente una salsa.

Las pruebas unitarias ayudan al mantenimiento del código, pero solo hasta cierto punto. Si hace que el código sea menos legible, o más frágil para hacer que las pruebas unitarias funcionen, se vuelve contraproducente. El "código comprobable" es generalmente un código flexible, por lo que es bueno, pero no tan importante como la funcionalidad o la capacidad de mantenimiento. Para algo como la hora actual, hacer eso flexible es bueno, pero perjudica la capacidad de mantenimiento al hacer que el código sea más difícil de usar y más complejo. Dado que la capacidad de mantenimiento es más importante, por lo general erraré hacia un enfoque más simple, incluso si es menos comprobable.

Sí, es una buena práctica. La razón es que la capacidad de prueba no es para el propósito de las pruebas. Es por el bien de la claridad y la comprensión que trae consigo.

A nadie le importan las pruebas. Es un hecho triste de la vida que necesitamos grandes suites de pruebas de regresión porque no somos lo suficientemente inteligentes como para escribir código perfecto sin verificar constantemente nuestra base. Si pudiéramos, el concepto de pruebas sería desconocido, y todo esto no sería un problema. Ciertamente me gustaría poder hacerlo. Pero la experiencia ha demostrado que casi todos nosotros no podemos, por lo tanto, las pruebas que cubren nuestro código son una buena cosa, incluso si nos quitan tiempo para escribir el código de negocios.

¿De qué manera las pruebas mejoran nuestro código de negocio independientemente de la prueba? Al obligarnos a segmentar nuestra funcionalidad en unidades que fácilmente se demuestra que son correctas. Estas unidades también son más fáciles de acertar que las que, de lo contrario, tendríamos la tentación de escribir.

Tu ejemplo de tiempo es un buen punto. Siempre que solo tenga una función que regrese a la hora actual, podría pensar que no tiene sentido programarla. ¿Qué tan difícil puede ser conseguir esto bien? Pero inevitablemente, su programa usará esta función en otro código, y definitivamente desea probar ese código en diferentes condiciones, incluso en diferentes momentos. Por lo tanto, es una buena idea poder manipular el tiempo que retorna su función, no porque desconfíe de su llamada currentMillis() de una línea, sino porque necesita verificar la persona que llama de esa llamada bajo control circunstancias. Como puede ver, tener un código comprobable es útil, aunque por sí solo, no parece merecer tanta atención.

  

En algún punto, el valor debe inicializarse, y ¿por qué no es lo más cercano al consumo?

Porque es posible que necesite reutilizar ese código, con un valor diferente al generado internamente. La capacidad de insertar el valor que va a utilizar como parámetro garantiza que pueda generar esos valores en cualquier momento que lo desee, no solo "ahora" (que significa "ahora" cuando se llama el código).

Hacer que el código sea verificable en efecto significa hacer que el código pueda (desde el principio) usarse en dos escenarios diferentes (producción y prueba).

Básicamente, si bien puede argumentar que no hay incentivo para hacer que el código se pueda probar en ausencia de pruebas, existe una gran ventaja al escribir código reutilizable, y los dos son sinónimos.

  

Además, el propósito del método en mi mente es devolver algún valor en función de la hora actual, al convertirlo en un parámetro que implica que este propósito puede / debe cambiarse.

También podría argumentar que el propósito de este método es devolver algo de valor basado en un valor de tiempo, y lo necesita para generar ese valor basado en "ahora". Uno de ellos es más flexible, y si te acostumbras a elegir esa variante, con el tiempo, tu tasa de reutilización de código aumentará.

Puede parecer una tontería decirlo de esta manera, pero si quieres poder probar tu código, entonces sí, escribir código verificable es mejor. Usted pregunta:

  

En algún punto, el valor debe inicializarse, y por qué no es lo más cercano   al consumo?

Precisamente porque, en el ejemplo al que hace referencia, hace que ese código no se pueda probar. A menos que solo ejecute un subconjunto de sus pruebas en diferentes momentos del día. O restableces el reloj del sistema. O alguna otra solución. Todo lo cual es peor que simplemente hacer que su código sea flexible.

Además de ser inflexible, ese pequeño método en cuestión tiene dos responsabilidades: (1) obtener la hora del sistema y luego (2) devolver algún valor basado en ello.

public static string GetTimeOfDay()
{
    DateTime time = DateTime.Now;
    if (time.Hour >= 0 && time.Hour < 6)
    {
        return "Night";
    }
    if (time.Hour >= 6 && time.Hour < 12)
    {
        return "Morning";
    }
    if (time.Hour >= 12 && time.Hour < 18)
    {
        return "Afternoon";
    }
    return "Evening";
}

Tiene sentido desglosar las responsabilidades aún más, de modo que la parte fuera de su control ( DateTime.Now ) tenga el menor impacto en el resto de su código. Hacer esto hará que el código anterior sea más simple, con el efecto secundario de ser comprobable sistemáticamente.

Ciertamente tiene un costo, pero algunos desarrolladores están tan acostumbrados a pagar que han olvidado que el costo está ahí. Para su ejemplo, ahora tiene dos unidades en lugar de una, ha requerido que el código de llamada inicialice y administre una dependencia adicional, y mientras que GetTimeOfDay es más comprobable, está de vuelta en el mismo barco probando su nuevo IDateTimeProvider . Es solo que si tiene buenas pruebas, los beneficios generalmente superan los costos.

Además, hasta cierto punto, la escritura de códigos comprobables lo alienta a diseñar su código de una manera más fácil de mantener. El nuevo código de administración de dependencias es molesto, por lo que querrá agrupar todas sus funciones dependientes del tiempo, si es posible. Eso puede ayudar a mitigar y corregir errores como, por ejemplo, cuando carga una página justo en un límite de tiempo, con algunos elementos representados usando el tiempo anterior y algunos usando el tiempo posterior. También puede acelerar su programa al evitar llamadas repetidas al sistema para obtener la hora actual.

Por supuesto, esas mejoras arquitectónicas dependen en gran medida de que alguien se dé cuenta de las oportunidades y las implemente. Uno de los mayores peligros de centrarse tan estrechamente en las unidades es perder de vista el panorama general.

Muchos marcos de prueba de unidad le permiten parchar un objeto simulado en tiempo de ejecución, lo que le permite obtener los beneficios de la capacidad de prueba sin todo el desorden. Incluso lo he visto hecho en C ++. Examine esa capacidad en situaciones en las que parece que el costo de la capacidad de prueba no vale la pena.

Es posible que no todas las características que contribuyen a la capacidad de prueba sean deseables fuera del contexto de la capacidad de prueba: tengo problemas para encontrar una justificación no relacionada con la prueba para el parámetro de tiempo que cita, por ejemplo, pero en términos generales las características que contribuir a la capacidad de prueba también contribuir al buen código independientemente de la capacidad de prueba.

En términos generales, el código comprobable es un código maleable. Está en trozos pequeños, discretos, cohesivos, por lo que se pueden reutilizar los bits individuales. Está bien organizado y tiene un nombre adecuado (para poder probar algunas funciones, debe prestar más atención a la asignación de nombres; si no estuviera escribiendo las pruebas, el nombre de una función de un solo uso sería menos importante). Tiende a ser más paramétrico (como su ejemplo de tiempo), por lo que está abierto a otros contextos que el propósito original. Es SECO, por lo tanto menos abarrotado y más fácil de comprender.

Sí. Es una buena práctica escribir código verificable, incluso sin importar las pruebas.

Escribir código verificable es importante si quieres poder probar que tu código realmente funciona.

Tiendo a estar de acuerdo con los sentimientos negativos acerca de convertir tu código en contorsiones atroces para que se ajuste a un marco de prueba en particular.

Por otra parte, todos los que estamos aquí, en algún momento u otro, han tenido que lidiar con esa función mágica de 1.000 líneas que es simplemente atroz tener que lidiar, prácticamente no se puede tocar sin romper uno o más oscuros Dependencias no obvias en otro lugar (o en algún lugar dentro de sí mismo, donde la dependencia es casi imposible de visualizar) y es prácticamente imposible de probar por definición. La noción (que no es sin mérito) de que los marcos de prueba se han exagerado no debe tomarse como una licencia gratuita para escribir código de baja calidad e inestable, en mi opinión.

Los ideales de desarrollo impulsados por pruebas tienden a empujarlo a escribir procedimientos de responsabilidad única, por ejemplo, y que es definitivamente algo bueno. Personalmente, digo que compre una única responsabilidad, una única fuente de verdad, un alcance controlado (sin variables globales extrañas) y mantenga las dependencias frágiles al mínimo, y su código será comprobable. ¿Se puede probar con algún marco de prueba específico? Quién sabe. Pero tal vez sea el marco de prueba el que necesita ajustarse al buen código, y no al revés.

Pero para ser claro, el código que es tan inteligente, o tan largo y / o interdependiente, que no sea comprendido fácilmente por otro ser humano no es un buen código. Y también, casualmente, no es un código que se pueda probar fácilmente.

Por lo tanto, al acercarse a mi resumen, ¿es el código comprobable mejor ?