¿Una forma automatizada de detectar pruebas que no pueden fallar, registradas para alcanzar la cobertura mínima del código?

Question

Tengo un desarrollador que sorteará nuestra cobertura de código escribiendo pruebas que nunca fallan.

El código es simplemente atroz, pero las pruebas nunca lo detectan porque afirman (verdadero).

Reviso el código, pero no puedo hacer el trabajo de todos para ellos, todo el tiempo.¿Cómo se puede motivar a personas como esta para crear un buen software?

¿Existe un complemento de compilación para detectar pruebas que no pueden fallar?

C#, pruebas mbUnit.

Answer 1

La verdadera motivación viene de dentro.Algunas personas juegan con el sistema cada vez que pueden, a veces sin más razón que la que pueden.Otros lo hacen simplemente porque son hacks.

Dicho esto, asumiendo que eres el gerente, ten una reunión de "ven a Jesús" con el desarrollador.Si eso aún no funciona, siempre queda la puerta.

Si no es el administrador, utilice los canales adecuados.

Answer 2

Creo que casi has respondido la pregunta por ti mismo allí.Si tiene a alguien trabajando para usted o con usted (no tiene claro si es el administrador de este desarrollador), entonces, si no está haciendo el trabajo correctamente, seguramente hay procedimientos disponibles para dejarle claro a esta persona que no están produciendo trabajo a un nivel aceptable.

¿El desarrollador es nuevo en TDD?Tal vez necesiten algo de enseñanza sobre cómo redactar buenos exámenes, etc.De lo contrario, necesitan una patada en el trasero y que se les enfatice que las pruebas son más importantes que el código que está produciendo.

Ah, sí, y en cuanto al complemento, olvídalo, la misma revisión de código que estás haciendo debería ser suficiente.

Answer 3

Realmente deberías especificar el lenguaje/marco que estás utilizando.

En el caso más simple, supongo que debería ser fácil de detectar. assert(true) cuerdas con simples grep-silbido.

Answer 4

Siempre puede intentar realizar una prueba con basura para los valores de configuración de la aplicación.

¿Alguna prueba que pase es sospechosa?

Answer 5

En lugar de dedicar tiempo a buscar pruebas que no puedan fallar, ¿qué tal extender un poco las pruebas? Hacer que el código falle de muchas maneras.Eso podría

• Muéstrele cómo escribir mejores pruebas.
• Obligarlo a corregir su código y evitar que se registren más códigos incorrectos.

Un fragmento de código con errores que tengas que usar sería un buen punto de partida; debes estar seguro de que funciona...

Answer 6

Tome la interfaz que está probando y redúzcala a su forma más simple.En otras palabras, tome las firmas de clase/método y solo agregue el código necesario para compilar más allá de eso.Ejecute sus pruebas contra eso.Pregúntele por qué sus pruebas pasan cuando el programa no hace nada.

Answer 7

La revisión de código, realizada por dos o más desarrolladores que ya están infectados por la prueba, es probablemente la mejor manera de hacer que el desarrollador en cuestión vea que las pruebas unitarias automatizadas en realidad no son tan difíciles ni inusuales.Tener dos desarrolladores infectados de prueba en cada revisión reforzará la importancia de las pruebas unitarias de calidad para él.Además, asignarle revisiones del código de otros desarrolladores que esté bien probado le ayudará a aprender cómo realizar pruebas unitarias.

Deberías echar un vistazo a hacer algunos prueba de mutación, para detectar pruebas débiles. Nester, (el equivalente .Net de Bufón) es una herramienta que puede resultarle útil.

¡Cuéntanos cómo te va!

Actualizar:Me encontré con: "¿Por qué la mayoría de los desarrolladores todavía no escriben pruebas unitarias?" y pensé que sería bueno leerlo aquí también.

Answer 8

Creo que primero debes intentar que escriba una prueba reprobatoria.Intenta que adquiera ese hábito.A menudo, las personas nuevas en las pruebas unitarias tienen dificultades para escribirlas.

También existen algunas herramientas que pueden ayudarle a "explorar todas las rutas de código posibles".Te sugiero que le eches un vistazo, PEX lo que generará pruebas automatizadas y muy probablemente romperá su código...Si bien esta puede no ser una solución óptima, intente promover el concepto de una base de código compartida.

Haga que sus desarrolladores emparejen el programa; es mucho más difícil "ser vago" cuando trabaja con otra persona en la misma función, y esto distribuirá la propiedad del código.Parece que no estás haciendo esto, ya que hablas de "su" código.Puede resultar sorprendente lo mucho que se puede hacer si hay dos personas trabajando en el mismo trabajo. Aumentará mucho la calidad.

Además, las pruebas unitarias no son el santo grial para erradicar todos los problemas...Deberían ser una de las herramientas que tienes a tu disposición.

¿Cuál es su requisito de cobertura de código?