desarrollo impulsado por pruebas: ¿quién debe escribir las pruebas?

Originalmente, es deber del desarrollador escribir la prueba, pero me di cuenta de que en muchos casos / desarrolladores maduros electrónicos esos casos no dan ni siquiera un 80% de cobertura.
¿Qué tal si tengo una persona de control de calidad dedicada a escribir TODAS las pruebas para un proyecto determinado en lugar del desarrollador?
¿Hay alguna desventaja en eso?

En Test-Driven Development, las pruebas deben ser escritas por el desarrollador. De lo contrario, alguien que no sea el desarrollador está impulsando el desarrollo.

Entonces, tan pronto como le das el trabajo de escribir pruebas a un no desarrollador, esa persona se convierte en desarrollador.

Mi experiencia en TDD es que escribir el código de prueba es a menudo tan difícil o más difícil que escribir el código de producción. Entonces, si tiene recursos capaces de escribir un buen código de prueba de unidad / prueba de integración, deberían estar escribiendo el código de producción que hace pasar esas pruebas.

El trabajo de QA es realizar un tipo de prueba completamente diferente (es decir, pruebas de usabilidad / integración). Realmente no tienen que conocer las tecnologías utilizadas en el código.

Si le preocupa la baja cobertura de código, debe disciplinar a sus desarrolladores. Por ejemplo, dejar de trabajar en cualquier función nueva, hasta que aumente la cobertura del código. Algunas organizaciones llegan a tener un enlace de precompromiso en su repositorio que no permitirá el registro de código descubierto.

Por último, pero no menos importante, en TTD 'puro', no debería haber ningún código descubierto (ya que primero escribe las pruebas). Sin embargo, hay casos (aunque las personas discuten al respecto) en los que una cobertura de código más baja es aceptable. Algunos argumentan, por ejemplo, que escribir pruebas para captadores / creadores de POJO es una pérdida de tiempo.

esos casos no dan ni siquiera un 80% de cobertura

Eso podría ser un problema de gestión.

O podría ser irrelevante.

Primero, la diferencia entre el 80% y el 100% de cobertura es probablemente un gran costo por muy poco beneficio.

"Cobertura" puede significar cualquier cosa. Líneas de código, rutas lógicas, etc. Supongo que quiere decir líneas de código (no rutas lógicas).

Algunas rutas lógicas se prueban bastante bien "por inspección". El código es obvio, no tiene sentencias if, tiene una complejidad muy, muy baja y probablemente no necesita una prueba adicional.

Un 20% más de pruebas no siempre es un 20% más de calidad.

Segundo. Es un problema de gestión. Si la gerencia quiere una cobertura del 100%, tienen que establecer un sistema de recompensas que recompense la cobertura del 100% en lugar de "lo suficientemente bueno como para liberar" una cobertura del 80%.

Agregar personas de control de calidad para escribir más pruebas no ayudará mucho.

Agregar desarrolladores para escribir más pruebas es lo que se requerirá para obtener una cobertura de prueba del 100%.

La prueba de la unidad de la OMI no es un proceso de control de calidad. Se trata más de acelerar el desarrollo (reduciendo el ciclo de retroalimentación para los desarrolladores). Debe hacerlo la persona que escribe el componente (también conocido como unidad) con un enfoque en el uso de los componentes (por otro desarrollador).

La prueba funcional es un proceso de control de calidad que puede y debe ser realizado por un equipo de control de calidad. El desarrollador puede hacer esto, pero un no desarrollador sería mejor ya que el desarrollador podría no conocer todas las formas en que un usuario podría usar la aplicación.

Ambos se pueden hacer de forma TDD.

TDD no se trata solo de pruebas, sino también de diseño. Escribir código solo para pasar las pruebas generalmente conduce a un código más pequeño y fácil de mantener. Si delega a cualquier otra persona para escribir las pruebas, también delegará la responsabilidad de crear un buen código.

También debe tener en cuenta que la cobertura no le informará sobre la calidad del código y no le informará si las reglas de dominio están siendo cubiertas.

Si necesita al menos un 80% de cobertura, debe hacer un par de cosas:

• Proporcione a sus desarrolladores las herramientas que necesitan para determinar qué nivel de cobertura tienen, y asegúrese de que sean manzanas con manzanas. Hay más de una forma de medir la cobertura.
• Proporcionar una recompensa / incentivo para lograr esa hazaña. Los programadores solo harán lo que sientan que valdrá la pena. Si una cobertura del 50% es lo suficientemente buena como para garantizar la calidad y realizar todo el trabajo, eso es lo que harán.

Finalmente, comprenda que hay una diferencia entre las rutas de ejecución previstas y las rutas de ejecución no intencionadas . En el proceso de escribir código controlado por pruebas, es posible que haya demostrado que necesita un par de declaraciones if independientes. Como resultado, hay pruebas para dos de las cuatro posibles rutas de ejecución disponibles. Agregue una instrucción if más independiente, y tiene un potencial para ocho rutas de ejecución (es decir, aumenta exponencialmente).

Comprenda que TDD no necesariamente predice cada ruta potencial de ejecución, por lo que hay una serie de pruebas que podrían necesitarse para completarse, pero no se escriben porque no era necesario probar esa ruta. En resumen, TDD no garantiza la cobertura, pero sí garantiza que hay al menos una prueba para demostrar el motivo del código que existe.