unit-testing - pruebas - unit test c#
Desarrolladores Senior y Pruebas de Unidad-¿Requeridos? ¿Se les permite usar lacayos? (13)
¿Deberían los desarrolladores senior estar exentos de las pruebas unitarias, o deberían poder usar lacayos para implementarlos? ¿Cuál es la mejor manera de motivar a las personas que no están acostumbradas a usar técnicas de pruebas unitarias para adoptarlas?
¿Deben los desarrolladores senior estar exentos de las pruebas unitarias?
Absolutamente no. No deberían ser desarrolladores sénior en absoluto entonces. Los desarrolladores principales deberían ser líderes que muestren el camino, la idea de que los lacayos lo hagan parece absurdo, ¿por qué molestarse en probarlo?
Absolutamente no; al menos porque es mucho más fácil escribir pruebas para el código que usted mismo desarrolla. Pero es importante para todos los desarrolladores, independientemente de su antigüedad, probar la unidad de todo su código; si se desarrollan sabiendo que su código debe ser comprobable, los frutos de su trabajo serán mucho mayores.
Si necesitas motivar a los desarrolladores para que realicen pruebas unitarias, solo presiona las ventajas y el tiempo que se ahorrarán a largo plazo. Si adquieren el hábito de escribir pruebas unitarias para su código, pronto comenzarán a hacerlo por rutina.
Creo que una posible forma de manejar estas situaciones sería que el Desarrollador Senior podría escribir la mayoría de las Pruebas Unitarias. Eso significa que están definiendo y diseñando la forma en que el programa debería funcionar. Los lacayos pueden escribir el código para que coincida con la prueba, aprendiendo las filosofías de diseño del chico mayor mientras están en ello.
La persona que escribe la prueba = define cómo debería funcionar el sistema = el "jefe"
Las personas que implementan las pruebas son los llamados "lacayos"
Suena como el caso de un perro viejo a quien no le gustan los trucos nuevos. Y como dice el refrán, es difícil lograr que cambien ... TFD (desarrollo de prueba primero) es muy divertido una vez que comienzas a hacerlo, tal vez tener un taller interno de 1 día sobre TDD o TFD que involucre a todo el equipo.
Si un desarrollador senior no está haciendo sus propias pruebas, entonces no es un desarrollador sénior.
La falta de voluntad para evaluar casi siempre es un signo de pereza o ineptitud (o ambos), y ninguno de los dos es un rasgo que debería encontrarse en un desarrollador sénior.
El único escenario en el que se me ocurre que sería apropiado para un desarrollador sénior hacer que alguien más escriba sus pruebas unitarias sería en el caso en que un nuevo empleado menor se ponga al corriente de las cosas. Podría ser una buena tarea mojarse los pies mientras escribe algún código.
Si usted es un desarrollador sénior, es en parte porque tiene la experiencia suficiente para saber que la prueba unitaria es una gran práctica de desarrollo que lo ayuda a producir un mejor software.
Yo diría que desde un punto de vista purista TDD (es decir, uno que piensa que las pruebas unitarias deben escribirse antes de la implementación), los desarrolladores senior deberían escribir más pruebas unitarias que lacayos, no menos .
La razón es que, dado que las pruebas unitarias son lo primero, escribirlas requiere un conocimiento profundo de la base de códigos. Si dejas que los lacayos los escriban, esencialmente estás permitiendo que los que menos saben de tu dominio dicten la estructura de tu código base. Eso me parece una mala idea.
Parte I (Desarrolladores Senior y Prueba de Unidad)
Cuando pienso en TDD o Test Driven Design, los Unit Tests cumplen la función de eliminar el diseño evolutivo del sistema, garantizando la mejora continua.
Escribir la prueba da forma al código o resalta los problemas con una decisión que ya se ha tomado, lo que con suerte da como resultado un proceso de refactorización para aumentar la calidad del diseño.
En mi experiencia, el desarrollador principal es normalmente la persona con más experiencia y capacidad, lo que significa que debe estar en una mejor posición para detectar estas oportunidades de refactorización. (Detecta el código huele)
Hay tres situaciones en las que puedo pensar, fuera de mi cabeza, donde alguien que escribe las pruebas podría ser aceptable.
- Pruebas de aceptación / Pruebas de clientes / Pruebas de extremo a extremo. Llámalos como quieras, pero me refiero a las pruebas que comienzan en el punto de entrada de datos (servicio web, página web, entrada de pantalla de la aplicación) y recorren toda la pila del sistema (a una base de datos, llama a otro servicio, volver a la pantalla de resultados de entrada, etc.). Esto podría ser escrito por alguien que no esté implementando los detalles de las unidades individuales que serán ejercidas por las pruebas.
Programación sincronizada ( patrón de ping pong ) -
A escribe una nueva prueba y ve que falla.
B implementa el código necesario para pasar la prueba.
B escribe la siguiente prueba.
A lo implementa.Pruebas de corrección de errores: cuando se encuentra un error, a menudo es una buena práctica escribir una prueba de falla que expone el defecto. Una vez que esta prueba está en su lugar, es completamente posible que alguien implemente el código que hace pasar la prueba. No creo que esta sea una buena idea, ya que el hecho de escribir la prueba que falla debido al defecto a menudo brinda algunas ideas sobre cómo se puede producir una solución.
En resumen, mi respuesta a su primera pregunta sería: ningún desarrollador senior debería estar exento de las pruebas de unidad de escritura.
Parte II (Motivar a las personas a escribir pruebas)
Esto es algo con lo que he tenido problemas en el pasado. A pesar de que ahora trato de realizar TDD tantas veces como sea apropiado, tardé unos meses en ver que había un beneficio real en las pruebas de escritura.
Creo que tratar de mostrar a otros los beneficios de TDD y Unit Testing es bastante difícil. Solo cuando la persona experimenta por sí misma, ese momento "ah ha" en que los TDD / Pruebas Unitarias han resaltado una sutileza en su código, que de otro modo podrían haber pasado por alto, o les ayudó a corregir un error en poco tiempo, que ver los beneficios. Llegar a ese punto puede ser bastante difícil.
Personalmente llegué allí mediante la programación de pares en el Patrón Ping Pong antes mencionado, trabajando con un experimentado TDDer y viendo cómo el código que estábamos escribiendo para resolver una funcionalidad no trivial evolucionaba hacia lo que podría llamarse una solución elegante. Seguido por ese trabajo que pasa por QA y en el Live Environment sin ningún defecto contra él.
En resumen, creo que el emparejamiento con un programador experimentado que ya está convencido de los beneficios que surgen al escribir Pruebas unitarias es una excelente manera de ayudar a alguien a motivarse para escribir pruebas unitarias.
Uno de los mayores beneficios de las pruebas unitarias es la respuesta inmediata que le indica qué tan bien lo está haciendo. Si externaliza la implementación de sus pruebas, no recibirá retroalimentación si su diseño funciona o no. Y las personas que luchan con un mal diseño no tienen medios para corregirlo.
No me suscribo a la religión de TDD, pero veo mucho valor en las pruebas de unidades / etc, y lo hago mucho cuando codigo.
Sin embargo, el punto es que nadie sabe realmente qué se supone que debe hacer el código, excepto la persona que lo escribió, y con frecuencia ni siquiera lo saben.
Con eso en mente, no vas a obtener mucho valor de ''lacayos'' que escriben las pruebas porque
- No tendrán una comprensión profunda de todos los casos de esquina sutiles
- No les importará el código porque no tienen nada invertido en él
- Se sentirán como si estuvieran siendo tratados como idiotas.
Incluso si son idiotas, a nadie le gusta que lo traten como tal. Si desea que su personal se retire, esta es una buena manera de alentarlos.
Bueno, yo diría que sí, pero solo si se permite que el lacayo permita que el arreglo de los errores hallados llegue a la persona mayor. Eso lo enseñará.
Nadie debería estar exento de escribir pruebas unitarias. Todos los desarrolladores deben poder escribirlos, y las pruebas unitarias también deben revisarse como parte del proceso de revisión del código. La complejidad de las pruebas unitarias generalmente será una función de la habilidad del desarrollador, con el código más complejo dirigido a desarrolladores más experimentados, por lo tanto, la cantidad más compleja y mayor de pruebas unitarias también les corresponderá.
Si tiene uno o más desarrolladores que no pueden adaptarse, intente proporcionarles asistencia personalizada y empareje las pruebas unitarias con el desarrollador hasta que él o ella comiencen a familiarizarse con el tema. No hay nada técnicamente lo suficientemente complejo como para que alguien que pueda escribir código no pueda producir pruebas unitarias. Si ese parece ser el caso, probablemente sea un precursor de un problema mayor con el conjunto de habilidades de esa persona.
Personalmente creo que también es útil para los evaluadores poder, al menos, comprender las pruebas unitarias que forman parte del proyecto. La colaboración entre desarrolladores y probadores es muy importante para diagnosticar y corregir defectos correctamente. No esperaría que tuvieran que escribirlos, pero deberían poder sentarse con un desarrollador y repasar el concepto de por qué y cómo falla una prueba o no.
Creo que tener lacayos y pruebas de unidades para alguien más está destruyendo el punto de tener pruebas unitarias para empezar. El programador que escribe el código debe saber cómo debe romperse el código y cuál es su comportamiento esperado. El hecho de que alguien más no libere al programador original de esa responsabilidad.
(Frase extraña debido a la neutralidad de género)