Competencia de pruebas unitarias

12

Mis empleadores organizan una competencia mensual de pruebas unitarias. Un día entero se dedica a escribir pruebas unitarias (obviamente, hacemos más pruebas a lo largo del mes, pero este es un día completo) y el "ganador" de la competencia recibe un premio. Sin embargo, nos resulta difícil determinar quién es el ganador.

Estábamos asignando puntos para cada caso de prueba. Así que si escribiste una prueba de unidad como esta ...

for (int i = 0; i < 100; i++) {
  assertTrue(i*i, square(i));
}

le darían 100 puntos. Obviamente, este es un ejemplo simplista pero demuestra los problemas con la asignación de "puntos" a cada caso de prueba.

Somos principalmente un Java & Tienda de Javascript. Así que sugerí contar el número de ramas de código probadas como una métrica. Podemos contar fácilmente las sucursales probadas a través de una herramienta de cobertura de código (como EclEmma). Sin embargo, no estamos seguros de cómo haríamos esto con nuestras pruebas de Selenium y obtener una cobertura de código en las fuentes de Javascript (¿alguna idea?)

¿Alguien tiene alguna sugerencia sobre cómo podríamos determinar mejor el ganador de esta competencia?

Edit

Sé cómo escribir pruebas unitarias, sé cómo escribir pruebas unitarias efectivas, no necesito ayuda para determinar qué probar. No tengo control sobre esta competencia, la competencia continuará. Entonces, o bien agrego algo de información para mejorarlo o continúo con las pruebas (sí, las juego. Por supuesto que las juego. Hay premios que ganar)

Editar

Esta pregunta aquí obviamente no es un duplicado, Aunque contiene información útil sobre cómo encontrar buenos casos de prueba, no proporciona ninguna métrica útil para evaluar la competencia.

    
pregunta Shaun 02.06.2015 - 22:22

3 respuestas

15
  

¿Alguien tiene alguna sugerencia sobre cómo podríamos determinar mejor el ganador de esta competencia?

Lo único que tiene sentido para mí es votar: cada desarrollador puede asignar algunos puntos a la prueba de todos los demás desarrolladores (excepto el suyo). Tal vez 3 puntos para la prueba, cree que es el "más efectivo", 2 puntos para el segundo y uno para el tercero. La prueba con más puntos gana. Puede dar mejores resultados cuando la asignación de puntos se realiza sin saber de antemano quién escribió la prueba en particular.

Como beneficio adicional, obtendrás una revisión por pares de todas tus pruebas.

    
respondido por el Doc Brown 02.06.2015 - 22:53
6
  

Entonces, si escribiste una prueba de unidad como esta ...

for (int i = 0; i < 100; i++) {
 assertTrue(i*i, square(i));
}
     

le darían 100 puntos.

Le daría 0 puntos a esta persona (incluso si la prueba probara algo realmente relevante), porque las aserciones dentro de un bucle tienen poco sentido y las pruebas con afirmaciones múltiples (especialmente en forma de un bucle o un mapa) son difíciles de entender. trabajar con.

El problema consiste esencialmente en tener una métrica que no se puede engañar [fácilmente]. Una métrica que se basa exclusivamente en el número de aserciones es exactamente la misma que la que pagan los desarrolladores por LOC escrito. Al igual que con pay-by-LOC, que conduce a un código enorme e imposible de mantener, la política real de su empresa conduce a pruebas inútiles y mal escritas.

Si el número de afirmaciones es irrelevante, el número de pruebas también es irrelevante. Este es también el caso de muchas métricas (incluidas las combinadas) que uno podría imaginar para este tipo de situaciones.

Lo ideal sería aplicar un enfoque sistémico. En la práctica, esto difícilmente puede funcionar en la mayoría de las compañías de desarrollo de software. Así que puedo sugerir algunas otras cosas:

  1. Usar revisiones de pares para las pruebas y tener algo similar al número de WTF por minuto métrica.

  2. Mida el impacto de esas pruebas a lo largo del tiempo en el número de errores . Esto tiene varios beneficios:

    • Parece justo,
    • En realidad, se puede medir si recopila datos suficientes sobre los informes de errores y su destino,
    • En realidad vale la pena!
  3. Utilice cobertura de rama , pero combínelo con otras métricas (así como con una revisión). La cobertura de la sucursal tiene sus beneficios, pero probar el código CRUD solo para obtener una mejor calificación no es la mejor manera de gastar el tiempo de los desarrolladores.

  4. Decida en conjunto cuáles son las métricas que desea aplicar en este momento (es posible que tales decisiones no sean bienvenidas o incluso no sean posibles en algunas compañías y equipos). Revise y cambie las métricas a menudo, seleccione las que sean más relevantes y asegúrese de que todos comprendan claramente qué se mide y cómo.

respondido por el Arseni Mourzenko 02.06.2015 - 22:53
5

Supongo que su empleador organiza este día de prueba de unidad para ofrecerle a las personas incentivos para encontrar errores, lograr una mayor cobertura de código y también para terminar teniendo más pruebas, que son útiles para siempre.

Por lo tanto, creo que tendría sentido que el ganador sea el desarrollador que encuentre la mayoría de los errores, o el desarrollador cuyas pruebas logren el mayor aumento en la cobertura de código.

Una prueba le ganaría un punto si hace que se abra una nueva entrada en su sistema de seguimiento de problemas / errores / defectos. Si una entrada ya está abierta para ese problema, no cuenta. Además, como se sugiere en los comentarios, los errores en su propio código no cuentan; Sólo los errores en el código de otras personas deben contar. Desafortunadamente, este enfoque no ofrece una gratificación instantánea porque puede demorar algunos días hasta que todas las pruebas fallidas se hayan revisado y se hayan abierto los problemas correspondientes. Además, esto no siempre puede funcionar; a medida que su sistema madura, puede ser extremadamente raro descubrir errores agregando pruebas.

El aumento en la cobertura del código podría proporcionar una medición más objetiva de la mejora representada por las nuevas pruebas. Primero, la cobertura total del código deberá registrarse el día anterior a la competencia. Luego, cada desarrollador deberá mostrar de alguna manera el aumento en la cobertura del código que resulta solo de sus pruebas, sin tener en cuenta el aumento en la cobertura del código resultante de las pruebas escritas por otros desarrolladores. Esto significa que probablemente necesitará un árbitro que vaya a la máquina de cada desarrollador y registre la cobertura del nuevo código antes de que se hayan realizado las pruebas de cualquiera.

Por cierto, tener en cuenta la cobertura del código proporciona una recompensa justa para las personas que escriben pruebas reales, en lugar de hacer tonterías como el ejemplo que proporcionó en la pregunta.

    
respondido por el Mike Nakis 02.06.2015 - 23:32

Lea otras preguntas en las etiquetas