Desarrolladores senior y pruebas unitarias: ¿se requieren?¿Se les permite utilizar lacayos?[cerrado]

Question

¿Deberían los desarrolladores senior estar exentos de las pruebas unitarias o se les debería permitir utilizar lacayos para implementarlas?¿Cuál es la mejor manera de motivar a las personas que no están acostumbradas a utilizar técnicas de pruebas unitarias para que las adopten?

Answer 1

Yo diría que desde un punto de vista purista de TDD (es decir,uno que piensa que las pruebas unitarias deberían escribirse antes 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 del código base.Si dejas que los lacayos los escriban, básicamente estás dejando que aquellos que menos saben sobre tu dominio dicten la estructura de tu código base.Eso me parece una mala idea.

Answer 2

Creo que tener lacayos haciendo pruebas unitarias para otra persona está destruyendo el sentido de tener pruebas unitarias para empezar.El programador que escribe código debe saber cómo debe descomponerse el código y cuál es su comportamiento esperado.El hecho de que otra persona lo haga no libera al programador original de esa responsabilidad.

(Redacción incómoda debido a la neutralidad de género).

Answer 3

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 al que 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 tengas un taller interno de 1 día sobre TDD o TFD que involucre a todo el equipo.

Answer 4

¿Deberían los desarrolladores senior estar exentos de las pruebas unitarias?

Absolutamente no.Entonces no deberían ser desarrolladores senior en absoluto.Los desarrolladores senior deberían ser líderes que muestren el camino, la idea de que los lacayos lo hagan parece absurda; entonces, ¿por qué molestarse en realizar pruebas?

Answer 5

Creo que una forma posible de manejar estas situaciones sería que el desarrollador senior pudiera 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 trabajar.Luego, los lacayos pueden escribir el código que coincida con la prueba, aprendiendo las filosofías de diseño del senior mientras lo hacen.

Answer 6

Parte I (Desarrolladores senior y pruebas unitarias)

Cuando pienso en TDD o Test Driven Design, las pruebas unitarias sirven para eliminar el diseño evolutivo del sistema, con la esperanza de garantizar una mejora continua.
Escribir la prueba da forma al código o resalta problemas con una decisión que ya se ha tomado, lo que con suerte resultará en un proceso de refactorización para aumentar la calidad del diseño.

En mi experiencia, el desarrollador senior suele ser la persona con mayor experiencia y capacidad, lo que significa que debería estar en una mejor posición para detectar estas oportunidades de refactorización.(Detecta los olores del código)

Hay tres situaciones que se me ocurren, fuera de mi cabeza, en las que alguien más escribe las pruebas por ti. podría estar bien visto.

1. Prueba de aceptacion/Pruebas de clientes/Pruebas de extremo a extremo.Llámelos como quiera, 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 atraviesan toda la pila del sistema (hasta una base de datos, llamada a otro servicio, volver a la pantalla de resultados de entrada, etc.).Esto podría escribirlo alguien que no esté implementando los detalles de las unidades individuales que serán ejercitadas por las pruebas.

2. Programación emparejada (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.

3. Pruebas de corrección de errores: cuando se encuentra un error, suele ser una buena práctica escribir una prueba fallida que exponga el defecto.Una vez realizada esta prueba, es muy posible que alguien implemente el código que hace que la prueba pase.No creo que sea una buena idea, ya que el acto de escribir la prueba que falla debido al defecto a menudo brinda algunas ideas sobre cómo se podría producir una solución.

En resumen, mi respuesta a su primera pregunta sería: no, un desarrollador senior no debería estar exento de escribir pruebas unitarias.

Parte II (Motivar a la gente a escribir exámenes)

Esto es algo con lo que he tenido problemas en el pasado.Aunque ahora intento realizar TDD con la frecuencia adecuada, me llevó algunos meses darme cuenta de que escribir pruebas tenía un beneficio real.
Creo que intentar mostrar a otros los beneficios de TDD y las pruebas unitarias es bastante difícil.Solo cuando la persona experimenta por sí misma ese momento de 'ah, ja' en el que TDD/Pruebas unitarias han resaltado una sutileza en su código, que de otra manera podría haber pasado por alto, o haberle ayudado a corregir un error en un corto período de tiempo, es que ver los beneficios.Llevarlos a ese punto puede resultar bastante difícil.
Personalmente, llegué allí programando en pareja en el patrón de ping pong antes mencionado, trabajando con un TDDer experimentado 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 de ese trabajo que pasó por el control de calidad y entró en el entorno en vivo sin que se presentaran defectos.

En resumen, creo que trabajar con un programador experimentado que ya esté convencido de los beneficios que se obtienen al escribir pruebas unitarias es una excelente manera de ayudar a alguien a motivarse a escribir pruebas unitarias.

Answer 7

Absolutamente no;al menos porque es mucho más fácil escribir pruebas para el código que usted mismo desarrolla.Pero es importante que todos los desarrolladores, independientemente de su antigüedad, realicen pruebas unitarias de todo su código;si desarrollan sabiendo que su código debe ser comprobable, los frutos de su trabajo serán mucho mayores.

Si necesita motivar a los desarrolladores para que realicen pruebas unitarias, simplemente insista en las ventajas y el tiempo que se ahorrará a largo plazo.Si adquieren el hábito de escribir pruebas unitarias para su código, pronto comenzarán a hacerlo de forma natural.

Answer 8

Si un desarrollador senior no realiza sus propias pruebas, entonces no es un desarrollador senior.

La falta de voluntad para realizar pruebas es casi siempre un signo de pereza o ineptitud (o ambas), y tampoco es un rasgo que deba encontrarse en un desarrollador senior.

El único escenario que se me ocurre en el que sería apropiado que un desarrollador senior hiciera que otra persona escribiera sus pruebas unitarias sería en el caso de que un nuevo empleado junior se ponga al día con las cosas.Podría ser una buena tarea para mojarse los pies mientras escriben código.

Answer 9

Uno de los mayores beneficios de las pruebas unitarias es la retroalimentación inmediata que le indica qué tan bien lo está haciendo.Si subcontrata la implementación de sus pruebas, no recibirá comentarios sobre si su diseño funciona o no.Y las personas que luchan con un mal diseño no tienen medios para corregirlo.

Answer 10

Si es un desarrollador senior, es en parte porque tiene suficiente experiencia para saber que las pruebas unitarias son una excelente práctica de desarrollo que ayuda tú producir mejor software

Answer 11

No me suscribo a la religión de TDD, pero veo mucho valor en las pruebas unitarias, etc., y lo hago mucho mientras codifico.

La cuestión es que nadie en realidad sabe lo que se supone que debe hacer el código excepto la persona que lo escribió y, a menudo, ni siquiera lo saben.

Con eso en mente, no obtendrás mucho valor de que los 'lacayos' escriban las pruebas porque

1. No tendrán una comprensión profunda de todos los casos sutiles
2. No les importará el código porque no han invertido nada en él.
3. Se sentirán tratados como idiotas.

Incluso si SON idiotas, a nadie le gusta que lo traten como tal.Si desea que su personal renuncie, esta es una buena manera de alentarlos.

Answer 12

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: el código más complejo irá a los desarrolladores más experimentados, de ahí que también les llegue a ellos un número más complejo y mayor de pruebas unitarias.

Si tiene uno o más desarrolladores que no pueden adaptarse, debe intentar brindarles asistencia personalizada y emparejar al desarrollador con las pruebas unitarias hasta que comience a dominarlo.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 las 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 evaluadores 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 una prueba falla o no.

Answer 13

Bueno, yo diría que sí, pero solo si al lacayo se le permite dejar que el mayor arregle los errores encontrados.Eso le enseñará.