Ejercicios para hacer cumplir las buenas prácticas tales como TDD y burlándose

Question

Busco recursos que proporcionan un plan de lección real o camino para estimular y reforzar prácticas de programación tales como TDD y burlarse. Hay muchos recursos que muestran ejemplos, pero estoy buscando algo que realmente proporcione una progresión de que permite que los conceptos se aprendan en lugar de forzar la emulación.

Mi objetivo principal es acelerar el proceso para que alguien entienda los conceptos detrás de TDD y realmente ser efectivo en su implementación. ¿Hay algún recurso gratuito como este?

Answer 1

Es una cosa difícil de alentar porque se puede percibir (bastante bastante) como un cambio radical; no tanto una progresión hacia un objetivo, sino un enfoque completamente diferente de las cosas.

La lista breve de consejo es:

• Necesita ser el líder, tiene que convertirse en expertos antes de poder convencer a otros para, tiene que ser capaz de mostrar a otros el camino y establecerse sus incertidumbres.

• Primera convertirse en expertos en la unidad de escribir las pruebas a ti mismo

  • pruebas de escritura Práctica para los métodos existentes. Probablemente se golpee la cabeza en el escritorio tratando de probar gran parte de su código, no porque las pruebas sean difíciles o porque no pueda comprender las pruebas; es más probable porque su código y estilo de codificación existentes no son muy comprobables.

  • Si tiene dificultades para comenzar, encuentre los métodos más simples que pueda y úselos como punto de partida.

• A continuación, se centran en la mejora de la capacidad de prueba del código que producen

  • El mayor consejo: hacer las cosas más pequeñas y más al punto. Este es el gran cambio: esta es la parte más difícil de hacer, y aún más difícil de convencer a los demás.

Personalmente tuve mi "momento de claridad", mientras que la lectura del libro "Código limpio" de Bob Martin; un capítulo temprano habla sobre cómo se verá un método limpio y como ejemplo toma un método de ~ 40 líneas que se asemeja visualmente a algo que yo produciría y lo refactoriza en una clase que es apenas más grande en cuanto a recuento pero no consiste en nada pero métodos del tamaño de un bocado que son quizás 3-7 líneas cada uno.

Mirando estos pequeños métodos, de repente hizo clic en que la piedra angular de pruebas unitarios "cada prueba solo prueba una cosa" es más fácil de lograr cuando sus métodos solo hacen una cosa (y hacen una cosa sin tener 30 mecanismos internos jugando).

Lo bueno es que puede comenzar a aplicar sus hallazgos inmediatamente; practica escribir pequeños métodos y clases pequeñas y pruebas en el camino. Probablemente comiences despacio, y pegues algunos inconvenientes con bastante rapidez, pero los primeros dos meses te ayudarán a apuntar en la dirección correcta.

Answer 2

Una cosa que he trabajado que me ayudó a apreciar TDD más fue NHibernate and the Unit of Work Pattern. Aunque es específico de NHibernate y .NET, me gustó la forma en que se arregló. Usando TDD, desarrolla algo (un UnitofWork) que es realmente útil en lugar de un ejemplo simple de "esto es lo que parece un simulacro".

Cómo aprendo mejor un concepto es poniéndolo en práctica para una necesidad real. Te sugiero que eches un vistazo a la estructura del artículo y veas si está en línea con lo que estás buscando.

Answer 3

usted podría intentar asistir (o alojamiento de uno si no hay nadie cerca de usted!) Un coding dojo

yo asistimos a un tal ejercicio y fue muy divertido TDD aprendizaje.

Answer 4

Los libros son siempre un buen recurso, aunque no gratuito, pueden valer la pena buscar los buenos recursos gratuitos por el dinero que cuestan esos libros.

"Test driven development by example" por Kent Beck.

"Test Driven Development in Microsoft .NET" por James W. Newkirk y Alexei A. Vorontsov

favor no dude en añadir a esta lista

Answer 5

frikis son excelentes para trabajar con las métricas, si son buenos para ellos o no!

Puede usar esto para su ventaja. Configure un servidor de CI y falle la compilación siempre que las coberturas de código caigan por debajo del 50 por ciento. Hágales saber que el umbral aumentará un 10 por ciento cada mes hasta que llegue a los 90. Tal vez podría usar algunos ganchos de confirmación para evitar que puedan verificar el código, pero nunca lo intenté.

Hazles saber que la cobertura del equipo se tomará en cuenta en cualquier evaluación de rendimiento, etc. Al enfatizar que es la cobertura del equipo, deberías obtener la presión de grupo ayudándote a garantizar una buena cobertura.

Esto solo garantizará que están probando su código, no qué tan bien están probando su código, ni si están escribiendo primero las pruebas. Sin embargo, es muy alentador (u obligatorio) para ellos incorporar las pruebas en su proceso de desarrollo diario.

Generalmente, una vez que las personas tienen algo en su proceso, querrán hacer algo de la manera más fácil/eficiente posible. TDD es la forma más fácil de escribir código con alta cobertura ya que no se escribe una línea de código sin que se cubra.

Answer 6

Encuentra a alguien con experiencia y habla con ellos. Si no hay un grupo local de desarrolladores, comience uno.

También debe tratar de empujar las cosas demasiado lejos para empezar, y luego aprender cuándo retroceder. Por ejemplo, todo el simulacro comenzó cuando alguien preguntó "¿Qué pasa si programamos sin getters"?

Finalmente, aprenda a "escuchar las pruebas". Cuando las pruebas parecen terribles, considere si es el código el culpable, no su técnica de prueba.