¿Debo comenzar con las pruebas unitarias cuando enseño a un nuevo desarrollador?

Question

Actualmente estoy trabajando en un proyecto que está utilizando tecnologías como Silverlight, WCF, EnterpriseLibrary, Unidad, LinqToSql, NUnit, RhinoMocks en .Net 3.5

estoy entrenando a un nuevo desarrollador que tiene cierta experiencia con VB secuencia de comandos y SQL, pero sin exposición a .NET

Casi el 100% de la base de código tiene cobertura de prueba unitaria, pero parece que obtener el nuevo desarrollador para empezar a escribir pruebas unitarias es demasiado, hay suficientes cosas pasando para captar su atención, sin la confusión adicional de pruebas unitarias y burlas.

Se le han asignado tareas para implementar nuevas características en la solución que atraviesa cada capa, desde UI a base de datos, y como siempre existe una fuerte demanda de los clientes para que la característica entre en producción lo antes posible.

¿Cuál cree que sería el mejor enfoque para que alguien se ponga al día?

Answer 1

Sin ninguna experiencia de .NET, yo diría que encaprichando con TDD al mismo tiempo que aprender .NET es demasiado.

Algunas personas con mucha experiencia en .NET tienen suficiente tiempo con TDD, se requiere un cambio real en el enfoque fundamental del desarrollo. Pasar de VB a .NET no es difícil, pero lleva tiempo.

que realmente quiere evitar confusiones - TDD es una buena maneraa desarrollar, pero no es la forma y el desarrollo TDD = .NET!. De hecho, es totalmente ortogonal, ¿intenta enseñar una nueva metodología y una nueva plataforma al mismo tiempo? No veo cómo es una buena idea.

Answer 2

Parece que el nuevo desarrollador ya está pasando por una prueba de fuego.

Parece que debería dejarlo ponerse al día y comenzar a compartir sus funciones, darle algo de tiempo para trabajar en ellas y, una vez que se sienta cómodo ... luego iniciarlo en Pruebas unitarias.

Answer 3

Considerando que ya hay muchas cosas por aprender, me temo que hablar sobre TDD y las pruebas automatizadas puede ser un poco "demasiado": si su nuevo desarrollador no sabe cómo desarrollarse, no lo sabrá cómo desarrollar pruebas, y las pruebas que escribirá probablemente no sean realmente útiles.

En su situación, le permití programar un par de días/semanas, probando a mano; y cuando empiece a comprender su código base, pasaría un tiempo con él, para programar un par: sería una gran ocasión para introducir pruebas automáticas, y revisar su código/comentario/mejorar al mismo tiempo.

Answer 4

Yo diría que sí, el objetivo principal de las pruebas es concentrarse en un área. De hecho, ayuda a despejar la cabeza y no es como si llevara más de 10 minutos aprender NUnit. Claro que probablemente tenga problemas un poco con los conceptos por un tiempo, pero un poco de trabajo arduo y un montón de emparejamientos deberían superarlo mucho más fácilmente que lanzarle tareas sin la orientación que proporciona TDD.

Answer 5

Yo diría que apague el programador. Comprender el problema de los usuarios y buscar el error, la detección de fallas y la solución les enseñará a los nuevos programadores cómo se arma la aplicación, escribir pruebas es más sobre un nuevo desarrollo.

Answer 6

Si tiene una gran burla en su área de prueba, tendrá serios problemas para comprender eso.Sin embargo, si le asignara Tareas más simples (donde no debería preocuparse por Mockery) y aprenda a averiguar "¿qué debería hacer mi código?" esto debería ser factible

Answer 7

Para un desarrollador inexperto, las pruebas unitarias parecen duplicar todo su código. Es un gran apagón.

Realmente necesita dejar que fallen antes de que puedan apreciar realmente los beneficios de las pruebas unitarias.

Answer 8

Si fuera yo, me emparejaría con él y TDD por un momento. Usted escribe una prueba, escribe el código que lo hace funcionar, luego escribe la siguiente prueba y usted escribe el código para hacerlo funcionar, etc.

Diversión, lo hace experimentar rápidamente, ahorra tiempo y dinero.

Answer 9

Comenzaría de manera simple: cortar la tarea en partes lógicas, luego sincronizar con él hasta que capte la parte actual. No creo que una inmersión total en TDD sea efectiva hasta que se alcance un buen nivel de confort por su parte, pero eso no significa que no puedas exponerlo a pruebas unitarias y tal.

Tal vez, como parte de su trabajo de preparación, podría escribir algunas pruebas que serán necesarias para realizar la tarea asignada. Mientras está resolviendo el problema, puede guiarlo hacia una solución general, usando las pruebas ("¡luz roja MAL!") Para demostrar dónde está desactivado su pensamiento.

Desde allí, puede "conducir" mientras "navega" - le define la funcionalidad deseada, y puede preguntarle cómo puede probar esa funcionalidad. Comienza a escribir las pruebas con él para que pueda ver la conexión entre las pruebas y el producto, y luego déjalo tomar el control lentamente.

Afortunadamente, si encaja bien, podrá comprender los conceptos desde cero y luego deducir cómo escribir sus propias pruebas (¡con su guía, por supuesto!). El paso final, creo, sería lanzarlo a la piscina y obligarlo a escribir las pruebas como parte de la definición de la funcionalidad que quiere escribir.

es probable que no sea un proceso rápido, pero espero que esto le dará una buena base en las pruebas de TDD/unidad

Answer 10

Ha sido asignado a las tareas que implementar nuevas funcionalidades a la solución que cortar a través de cada capa, desde UI a la base de datos, y como siempre hay una demanda de los clientes fuerte para obtener la función en producción tan pronto como posible.

¿Cuál cree que es el mejor enfoque para obtener una velocidad de hasta ?

Si withold información entonces puede que nunca ponerse al día. Enséñele cómo usted haría el trabajo.

Como el miembro más joven del equipo, "fuerte demanda" (es decir, problemas con el horario) no es su problema: eso es algo que el líder del equipo y/o jefe de proyecto le deben protegerse de.

Puede que tengas que educar al cliente: que traer a un nuevo miembro del equipo que no tenga experiencia previa con las tecnologías es una inversión que vale la pena a largo plazo.

En el corto plazo, usted (o el cliente más bien) puede ver poco o ningún beneficio inmediato: porque es lento (aprendizaje) y toma algo de su tiempo (no es independiente).

OMI debe:

• no lo convierte prisa (en vez que aprenda a hacerlo bien antes de esperar que lo haga rápidamente)

• Concéntrese en lo que sea necesario para asegurar que su el resultado no degrada la calidad general de los entregables del proyecto (es decir, debe enseñarle y asegurarse de que su horario lo permita, cualquiera que sea el desarrollador y los métodos de garantía de calidad que espere de los desarrolladores)

Dicho esto, I don't think that unit test are always necessary. Pero en una situación en la que es un programador nuevo (inexperto), y donde obviamente ya había decidido que la cobertura de prueba del 100% de la unidad era lo correcto para este proyecto, me resulta difícil ver por qué está pensando en cambiar ahora su proceso de desarrollo para él (a menos que tal vez estas características que le han sido asignadas tengan algunos requisitos de horario/calidad que sean diferentes de otras características).

Answer 11

Si no, ahora ¿cuándo? Creo que la línea de razonamiento que estoy viendo en esta discusión es una excusa para no hacer pruebas unitarias. Siempre habrá un mejor programador que yo, siempre seré un mejor programador mañana.

Incluso insinuar que "solo los desarrolladores de ninja súper" deberían hacer pruebas unitarias es el mensaje incorrecto para enviar, especialmente si valoras tus estadísticas de cobertura del 100%.

Las pruebas de unidades enseñan una de las API del código bajo prueba hacia atrás y hacia adelante sin que el desarrollador aprenda haciendo peligrosos cambios no probados en el código de producción.

En cuanto a la cuestión de la complejidad, el código complejo es un código complejo. El desarrollo de Cowboy sin pruebas unitarias no lo hace más simple.

Answer 12

pida a otra persona que escriba las pruebas unitarias y que escriba el código para que pase la prueba. Una vez que se sienta cómodo con eso, puede presentarlo para crear pruebas.

Answer 13

Lo que yo haría es decir:

"Utilizamos aquí TDD, que va a hacer así, pero primero quiero que se sienta cómodo con el entorno .NET Luego, en un par de semanas'. Me sentaré y programaré un par de pruebas unitarias ".

Creo que esto le da tiempo para digerir.