¿Qué incluirías en una charla de Grok de 10 min sobre Pruebas unitarias?

Question

Pronto haré una charla de 10 minutos sobre pruebas de unidad en mi empresa. Lo he intentado yo mismo, y siento que ciertamente puede traer beneficios a la compañía. Ya realizamos pruebas de WebInject en nuestro dedicado equipo de control de calidad, pero quiero probar y vender pruebas de unidades a los desarrolladores.

Entonces, con solo 10 minutos, ¿qué cubrirías y por qué?

• somos Microsoft Shop C# Web Apps, he usado NUnit en mi experiencia.

Answer 1

La prueba de la unidad es aproximadamente confianza.

Le permite estar seguro de que su código es sólido y de que otras personas pueden confiar en él cuando escriben sus propias partes de un sistema. Si logras atravesar las pruebas de la unidad que ayudarán a eliminar la inquietud que viene con la primera versión de un nuevo sistema, espero que tu audiencia se interese pronto.

Answer 2

Intente hablar brevemente sobre el aspecto del desarrollo impulsado por prueba: primero escriba pruebas y las interfaces sobre la marcha, luego implemente todo.

Tal vez también sobre la integración continua, esto significa que tan pronto como revisa algo en su sistema de control de origen, el proyecto se compila y se ejecutan todas las pruebas para que el desarrollador sepa inmediatamente si ha hecho algo mal.

Si hay gerentes de proyecto en la audiencia, también sea tan justo decirles que las pruebas unitarias harán que su proyecto tarde un 15-30% más, pero valdrá la pena a largo plazo.

Answer 3

Aquí es un buen formato para una breve charla en una técnica X:

• razón por la que decidimos probarlo X primer lugar
• lo que usted personalmente ha ganado el uso de X
• qué limitaciones he dado cuenta, las cosas que X no aborda

¿no 'vender' o pasar mucho tiempo en la teoría. Hacer preparar de antemano y señalar a las personas a los libros, las URL de los artículos o tutoriales que usted creo que son de mayor ayuda. Aquellos que estén interesados ​​después de su charla pueden buscar los detalles en la Web.

Answer 4

Se podría hablar de que será una curva de aprendizaje difícil, y se sentirá como la productividad está siendo afectado, pero los beneficios valen la pena:

por ejemplo, de hecho, la creación de un conjunto de pruebas de regresión automatizadas, que a su vez le permite hacer adiciones o modificaciones mayores a las ya existentes sin preocuparse de que esté rompiendo alguna funcionalidad existente.

La creación del código de producción será más lenta, pero esto debería compensarse con la mayor calidad del código, es decir, menos errores, lo que a la larga significa una mayor productividad general.

Answer 5

Desde una perspectiva comercial, puede resaltar el hecho de que las pruebas unitarias pueden "eliminar el riesgo" de cualquier cambio que realice en su código.Una vez que tenga un conjunto de pruebas unitarias, puede hacer cambios en la base de códigos y saber qué interrupciones y qué no.

Puede que no sea una mala idea para repasar las pruebas de usuario. Si tiene un buen conjunto de pruebas, puede presentar pruebas fallidas a los usuarios después de realizar cambios para que validen que los resultados nuevos son correctos. Además, puede agilizar la recopilación de requisitos si los usuarios escriben nuevas definiciones de pruebas unitarias para usted. Ellos no tienen que ser capaces de código, pero sí es necesario que sea capaz de darle las entradas y salidas esperadas correspondientes (de lo contrario ¿cómo iban a saber si los cambios que pedían eran de trabajo?).

Visual Studio tiene un conjunto bastante bueno de herramientas para pruebas unitarias, por lo que un ejemplo o dos pueden ser de gran ayuda para que su grupo tenga una idea de cómo son las pruebas unitarias en la práctica.

Answer 6

Comenzaría con un problema con el que muchos programadores estarían familiarizados: es el miedo a cambiar el código existente por temor a que se rompa algo. ¿Cómo que impide el trabajo suceda, o impide que se hace correctamente (porque tienen miedo a refactorizar) y por lo tanto conduce a tener que volver a escribir todo lo que cada x años.

Unidad de Pruebas -> Refactoring -> Código de estar.

Editar: por cierto, yo no daría lugar a la 'todo el código y sin pruebas de unidad es el código heredado' cita de Michael plumas. Ciertamente me hizo sentir a la defensiva la primera vez que lo escuché. Por el momento la gente deja de sentir ofendido los 10 minutos serán más :-)   (personalmente creo que la cita es más cierto que es útil).

Answer 7

Responsabilidad, como destaca Kent Beck, es otro rasgo que facilita las pruebas unitarias. Escuche su podcast al IT Conversations. (Su punto sobre la responsabilidad comienza a las 30:34.)

Answer 8

Creo que 10 minutos son suficientes para presentar un ejemplo simple de cómo las pruebas unitarias pueden ahorrarle tiempo.

Implementa una clase (puedes TDD si te apetece) y muestra cómo una prueba unitaria puede detectar una modificación que rompe la clase.

Además, puede resaltar cómo puede desarrollar componentes más rápidamente si prueba aisladamente (es decir, no necesita abrir su aplicación web, iniciar sesión, acceder a su funcionalidad, probar); solo puedes ejecutar tus pruebas.

Es posible que pueda realizar esto en un código de su empresa, y tal vez mostrar cómo una prueba unitaria puede haber detectado un error que ha tenido recientemente.

Answer 9

Si usted le da una demostración, lo hace en una pieza de trabajo de código de un proyecto que todo el mundo está familiarizado. Evita los ejemplos artificiales. Los libros en TDD ya están llenos de ellos, y realmente no venden cómo TDD puede funcionar para un proyecto real.

Answer 10

desgaste this t-shirt ;-)

Answer 11

Bien preparado demostración en vivo:

1. encontrar un "error" en su "aplicación"
2. Escribe una prueba de unidad que cubre este error.
3. Corregir este error
4. Mostrar, su código es verde.

Así que usted puede probar, que no hay manera, que este fallo se producirá una vez más!

Answer 12

Otra manera de hacer esto:

proponer un problema que puede ser resuelto mediante la creación de un algoritmo. Algo relativamente simple, por supuesto. A continuación, codifique este algoritmo en un proyecto DLL. Intenta colar algunas debilidades (i < = array.Length siempre es bueno). Luego, pregúnteles cómo probarían esta DLL.

La mayoría de los desarrolladores ejecutan sus aplicaciones para probarlos. Pero no puedes ejecutar una DLL. Es posible que algunos sugieran que cree una aplicación de consola para crear métodos que ejerciten el algoritmo. Muéstreles cómo puede crear pruebas unitarias para hacer esto.

Answer 13

Por el amor de dios, enfatice que las pruebas unitarias son para probar "unidades" de lógica. Odio mirar un conjunto de QA de pruebas de NUnit que nadie esperaba tener que mantener, donde cada "prueba de unidad" prueba salidas válidas para 150 archivos de entrada (binarios) y luego se caga si falla, sin decirle cuál.

Answer 14

Me gustaría demostrar:

• La confianza se da en el código que produce
• La confianza se da cuando se cambia el código, ya que pasa a la unidad de pruebas
• Los beneficios de la cobertura de código, no más "¡Oh, esa declaración de otra índole nunca fue probada!"
• Las ventajas de ejecutar pruebas unitarias por cada construyen sobre una plataforma de CI como Hudson

Fwiw que ejecute la prueba visual studio mierda a través de MSTEST en nuestro cuadro de Hudson y tengo una XSLT que utiliza para convertir Hudson los resultados en el formato nunit para que Hudson pueda descifrarlos. Simplemente exponiendo eso en caso de que quieran que se quede con una plataforma de prueba de Microsoft.

Answer 15

Tener un buen conjunto de recursos para el seguimiento/aprendizaje autodirigido:

• la prueba de la unidad pragmática para Java/C# son buenos libros sobre el tema del papel Beck
• el Kent en la unidad de pruebas
• enlaces a muestras más grandes utilizando el marco de prueba de elección