2010-04-13 10 views
8

Tengo curiosidad por saber cuál es un valor razonable/típico para la relación entre código de prueba y código de producción cuando las personas hacen TDD. En cuanto a un componente, tengo 530 líneas de código de prueba para 130 líneas de código de producción. Otro componente tiene 1000 líneas de código de prueba para 360 líneas de código de producción. Por lo tanto, las pruebas unitarias requieren aproximadamente de 3 a 5 veces más código. Esto es para el código Javascript. No tengo a mano el código de C# probado, pero creo que para otro proyecto estaba buscando de 2x a 3x tanto código de prueba como código de producción.Tamaño típico de pruebas unitarias en comparación con el código de prueba

Me parece que cuanto menor sea ese valor, suponiendo que las pruebas sean suficientes, reflejaría pruebas de mayor calidad. Pura especulación, solo me pregunto qué proporciones ven otras personas.

Sé que las líneas de código son una medida suelto, pero dado que codigo en el mismo estilo tanto para prueba como para producción (mismo formato de espacio, misma cantidad de comentarios, etc.) los valores son comparables.

+0

Por cierto, esto realmente parece una discusión, no es una pregunta real. –

Respuesta

4

Esto realmente dependerá de qué tan bien se toman en cuenta las cosas, pero, según mi experiencia (sí, lo he medido en algunos proyectos), he visto proporciones de 2: 1 a 5: 1 (esto es para código probado por supuesto). También eche un vistazo a las páginas ProductionCodeVsUnitTestsRatio y UnitTestToCodeRatio en la wiki C2.

0

Esos números suenan normales. La prueba de unidad más larga que he escrito fue de más de 1500 líneas y solo probó alrededor de 300 líneas de código.

+0

No es una prueba unitaria –

+0

@CallumBradbury Una unidad es la cantidad más pequeña de código que puede convenientemente ajustar para la prueba. 300 líneas son demasiado grandes y deben ser refactorizadas, así que cuando me entregaron el código escribí las pruebas para que se rompa con seguridad. – Daniel

3

¡Guau, esos números son bastante grandes! Soy aproximadamente 1: 1, a veces para las clases que tienen una complejidad ciclomática más alta que puede ir más cerca de 2: 1 a favor de las pruebas unitarias LOC, pero eso activa las alarmas que la clase necesita refactorizar.

Mencione que está utilizando el mismo estilo para las pruebas de su unidad. Eso es bueno en cuanto a tratar sus pruebas como código de producción, pero ¿realmente necesita muchos comentarios para el código de prueba? ¿Estás nombrando tus métodos de prueba para que sean descriptivos de lo que afirma la prueba? por ejemplo, usando el nombre de la función 'GivenXWhenYThenZ', entonces debería quedar bastante claro lo que hace la prueba sin una sección de comentarios grande.

¿Está refacturando sus pruebas? mover cualquier duplicación de instalación, etc. en métodos separados?

¿Mantiene las pruebas unitarias simples para que solo afirmen una cosa por prueba?

y ¿está probando demasiado cosas como getters/setters?

+0

Dije que mi uso de los comentarios es consistente entre el código de producción y el de prueba, pero eso significa que no hay muchos comentarios;) –

+0

¿Qué curioso es el lenguaje que está utilizando en donde ve una relación 1: 1? Creo que mis pruebas en javascript pueden ser más pesadas ya que hago más stubbing y burlarse en comparación con mi código C#. –

0

Los diferentes lenguajes y marcos de prueba serán muy diferentes. Por ejemplo, los marcos BDD son mucho más "DRYer" que el código de estilo TestUnit. Además, en un par de proyectos terminé teniendo grandes conjuntos de datos alimentados a través de unas pocas líneas de Java, que probaron miles de líneas del código, por lo que mi relación sería muy complicada.

Acabo de ver mis tres proyectos más recientes (rieles de tamaño mediano), y las proporciones de código a prueba eran 1: 2.3, 1: 1.6 y 1: 1.9 ... por lo que los números suenan parecidos. (Acabo de funcionar rake stats - En realidad nunca los miraba antes.)

De todos modos, las señales de advertencia que tiene demasiadas pruebas:

  • si realiza un cambio fallan las pruebas múltiples, o sólo uno ? Si falla una gran cantidad de pruebas, probablemente esté probando lo mismo una y otra vez y pueda eliminar la mayoría de ellas.
  • Parece que el código fue copiado y pegado. Refactorizar código común.
  • pruebas son demasiado lentos
  • pruebas que nunca han dejado de
0

Yo personalmente uso una aserción al cociente loc. Algunas cosas pueden requerir más maquetas y códigos de configuración para probar que otras. Siento que las líneas X del código de prueba en las líneas Y del código prod pueden no ser muy útiles. Una herramienta de cobertura de código es probablemente la mejor manera de verlo. He encontrado en mis dos últimos proyectos que mi código tiene 1 afirmación por cada 10 líneas de código de producción. ¿Alguien más obtiene valores similares?

Cuestiones relacionadas