¿Quién realiza el desarrollo basado en pruebas?

He estado trabajando en el espacio empresarial durante los últimos 4 años y medio y he notado que, en términos generales, las empresas no son entornos propicios para el estilo de desarrollo de primera prueba. Los proyectos son generalmente de costo fijo, línea de tiempo fija y estilo cascada. Cualquier prueba unitaria, si se realiza, generalmente viene después del desarrollo en la fase de control de calidad y realizada por otro equipo.

Antes de trabajar para una empresa, consulté para muchas pequeñas y medianas empresas, y ninguna de ellas estaba dispuesta a pagar por un proyecto de desarrollo al estilo de prueba. Por lo general, querían que el desarrollo comenzara de inmediato, o después de una breve etapa de diseño: es decir, algo más parecido a Agile, aunque algunos clientes querían que todo se trazara de manera similar a una cascada.

¿Con qué tipos de tiendas, empresas y clientes funciona mejor el desarrollo basado en pruebas? ¿Qué tipos de proyectos tienden a conducir a TDD?

Cada línea de código que escribo utiliza un desarrollo basado en pruebas. Si la gerencia no está de acuerdo con escribir las pruebas primero, entonces no se lo digo a la gerencia. Creo firmemente que el desarrollo impulsado por pruebas es un proceso mejor.

Mi jefe me dio de comer hoy, creo que voy a robarlo como si se lo estuviera robando a otra persona.

"¿Esperarías que un carpintero mida el tablero antes de cortarlo?"

Tomé clase de taller de carpintería en la escuela secundaria y trabajé en la construcción hasta la escuela. Nuestro mantra siempre fue "medir dos veces, cortar una vez", seguido por el sarcástico "¡Lo corté y lo corté de nuevo y todavía era demasiado corto!"

Si realiza la prueba después, crea un reproceso ya que el código que habrá escrito será difícil de probar. Cuando pruebe primero, o incluso pruebe un poco en el medio, pero antes de confirmar, el software que cree será más fácil de probar. Una empresa que crea pruebas unitarias después de escribir el código de producción para satisfacer una lista de verificación está desperdiciando esfuerzos.

La integración con el software existente difícil de probar también creará un esfuerzo adicional, ya que necesitará crear costuras de prueba para poder controlar las dependencias que consume su nuevo y brillante código impulsado por pruebas. En algunos casos, como con los marcos que hacen un uso intensivo del estado global y los objetos divinos, esto puede ser muy difícil de lograr. La dificultad percibida del desarrollo impulsado por pruebas a menudo se reduce a una combinación de inexperiencia con escribir buenas pruebas e intentar probar código estrechamente acoplado.

Puede probar el código de unidad incluso en un proyecto en cascada, es una disciplina de ingeniería, no una técnica de gestión de proyectos.

No soy fanático de TDD de ninguna manera, pero te enseña mucho sobre el diseño de software.

Tenga paciencia conmigo, ya que tendrá un sabor distintivo .Net: p

Con respecto a los tipos de proyectos que son susceptibles al enfoque de prueba primero, algunas cosas que debería tener en cuenta:

• ¿Se trata de una base de código existente? A menudo es prohibitivo adaptar un conjunto de pruebas. Obtenga una idea de la cantidad de deuda técnica heredada que existe
• ciertas plataformas y frameworks son inherentemente poco amigables con las pruebas. Experiencia reciente que se me viene a la mente: SharePoint, por ejemplo, es muy difícil (pero no imposible) para TDD. Para cosas como esta, puede que tenga que recurrir a un producto aislante comercial como TypeMock puede ayudar.
• ciertos enfoques de implementación se prestan mejor a TDD que otros. Por ejemplo, ASP.Net con código subyacente, no tan comprobable. ASP.Net MVC: comprobable. Silverlight con código subyacente, no tan comprobable. Silverlight con MVVM: comprobable.

En última instancia, si bien "la organización" puede hacer mucho para apoyar el paso a la prueba, el cambio clave que debe suceder está en la mente de los desarrolladores. He renunciado al enfoque de "escribirás tus pruebas primero" y, en cambio, busco momentos de enseñanza.

+1 en el comentario de mpenrow sobre no decirle a mgmt si tienen un problema:

Su situación no cambiará rápidamente, y la clave para lograrlo es hacerla parte de su disciplina personal y ser bueno en eso, antes de tratar de presionar a los demás. Si puede ser el ejemplo de que funciona, entonces sus gerentes deberían ver beneficios objetivos.

También puede hacer buenos casos de negocios:

• TDD se puede resumir simplemente como "especificación con la que el sistema puede verificar automáticamente". No está programando de manera diferente, no está construyendo un producto diferente.

• Las pruebas unitarias son realmente solo una forma de pruebas automatizadas; que es simplemente dejar que la computadora haga por sí misma lo que la compañía probablemente le está pagando a los ingenieros de espacio de carne para que lo hagan manualmente. Las pruebas automatizadas se ejecutan más rápido, de manera más consistente y, cuando están bien escritas, brindan comentarios, descripciones y direcciones rápidas, concisas y precisas para el problema

• TDD, cuando lo hace alguien que sabe lo que está haciendo, produce resultados tan rápido como el código primero. Habrá una curva de aprendizaje / entrenamiento (y, si sus ingenieros son del extremo inferior del grupo de talentos, esto puede matar por completo sus posibilidades de impulsar TDD; en este caso, lo mejor que puede hacer es continuar defendiéndolo y hacer que la gerencia los cuestione en lugar de TDD)

• TDD tiene mucho que ver con pensar en la tarea en cuestión antes de comenzarla. Está en la línea de "medir dos veces, cortar una vez": la medición adicional agrega una cantidad marginal de tiempo a la tarea, pero evita tirar su recurso más preciado: las horas de desarrollo).

... y solo recuerda; Lo más importante que puede hacer es liderar con el ejemplo. Si eres duro en TDD, invierte algunas horas adicionales para mejorar. Una vez que sea competente, simplemente comience a hacerlo en el trabajo (¿sus gerentes realmente se quejarían de que escribe pruebas?). Lucha una batalla a la vez y avanza hacia ella: ir a por todo el shebang probablemente resultará en un fracaso y la culpa recaerá sobre ti si te esfuerzas por ello.

Hago. Es mi forma preferida de desarrollo, y trabajo para una gran compañía financiera que está feliz de que trabaje de la manera que me parezca adecuada siempre que cumpla con los plazos y produzca un código de calidad. Hecho correctamente, el primer desarrollo de la prueba no necesita más tiempo que la prueba después del desarrollo y no olvidemos los otros beneficios del primer desarrollo de la prueba de menos defectos fuera de las pruebas del sistema más adelante.

La clave para hacer TDD es simplemente hacerlo como parte de la escritura de su código, y si es necesario, no le dice a nadie que lo está haciendo. No es necesario explicar todo lo que estás haciendo. Su resultado final es el código de trabajo.

Si explica "Estoy escribiendo pruebas", entonces The Powers That Be puede decir "¡Oh, podemos eliminar eso!" Pero si no le dice a nadie, entonces todavía tiene las pruebas como residuo del proceso de codificación.

La programación es más que escribir declaraciones de trabajo en un editor. Si la gente no puede manejar eso, entonces protéjalos de esta verdad hasta que estén listos para manejarlo. "Listo para manejarlo" en este caso significa cuando tienes un proyecto completo o dos, hecho a tiempo con un código sólido y confiable, y oh sí, mira, también tienes pruebas unitarias para ello.

Es triste decirlo, no he tenido la oportunidad de usarlo en el sentido clásico clásico de prueba primero, así que no puedo decir "¡yo! ¡Yo! ¡Lo hago!". Supongo que la pregunta es "¿qué industrias / empresas usan TDD en todos los ámbitos" en lugar de "¿alguien puede introducir el TDD en su vida cotidiana?". Estoy de acuerdo en que un desarrollador individual puede hacer TDD totalmente sin obligar a todo el grupo a hacerlo, simplemente no creo que ese sea el punto de la pregunta.

Mi impresión al escuchar en la industria es que es más probable que vea TDD en la mayoría de los grupos de desarrollo en una empresa en situaciones donde:

• No hay una gran base de código existente antes del inicio de TDD

• La compañía no es enorme y, por lo tanto, no tiene muchos de los retrocesos de "siempre lo hemos hecho al revés".

• La compañía no tiene una aceptación enorme en el proceso formalizado. Eso no quiere decir que no pueda implementar TDD en, por ejemplo, una empresa certificada por CMMI, pero si tuviera un proceso que no sea TDD, obtener todos los procesos que supervisa con CMMI actualizados puede ser una gran inversión.

• Las pruebas pueden ser programadas: esta es la base de código más compleja, ya que incluso si no puede crear fácilmente la capa más cercana al usuario, puede escribir algunas de las partes internas. Pero veo situaciones con opciones bien desarrolladas para la automatización de pruebas como los mejores lugares para TDD, ya que se basa en volver a ejecutar y no romper una batería completa de pruebas en las que necesita comentarios sobre las pruebas muy rápidamente. Mi opinión es que una aplicación web independiente es un buen objetivo TDD, un sistema con una gran integración COTS o entrada que no está basada en GUI puede ser complicado.

• Sistemas en estado no prototipado. Idealmente, la próxima gran versión después del prototipo, donde se termina la prueba de concepto y se financia el proyecto, pero todos saben que el próximo intento tiene que saltar en calidad.

• Partes interesadas que se invierten en el proceso.

Lo he intentado siempre que sea posible, pero creo que realmente depende del entorno corporativo en el que te encuentres. Trabajé en la industria de los juegos durante muchos años (como artista por cierto), y no había un concepto de TDD, solo un enfoque de control de calidad de fuerza bruta. Pasé al desarrollo web y todavía tengo que trabajar en una agencia con algún reconocimiento formal (o conocimiento de ...) pruebas de unidad / TDD. Lo mismo ocurre con la mayoría de mis colegas en la industria, que trabajan en una amplia gama de disciplinas.

En una agencia enfocada en ventas, TDD ofrece muy poco ROI a corto plazo para el cliente, por lo que es difícil vender a los gerentes de línea cuando se define un proyecto. Sin embargo, cuanto más grande es un proyecto, más convincente se vuelve.

Dado que libros como Death March apuntan a un fenómeno frecuente, es decir, una industria plagada de "crunch" y "hito" impulsado por el desarrollo, apuesto a que TDD es probablemente raro fuera de startups bien financiadas o tiendas de empresas monolíticas. No es que la gente de allí no crea en el valor de TDD, sino que es demasiado abstracto para venderlo a sus clientes.

Estoy tratando de entrar en TDD yo mismo. Creo que siempre y cuando sigas rutas que ya conoces (el trabajo diario) es bastante simple. Pero no puedo entender las pruebas para las partes de la interfaz de usuario o cuando tiene que encontrar una nueva solución a algún problema que no haya encontrado antes. O usando un marco que no conoces.

Así que supongo que tienes que hacer algún tipo de LearningTests, separar pruebas de conceptos y reescribirlas después, etc. ¿o me equivoco?

Y (sé que es antiguo, pero todavía no he visto una buena respuesta): ¿cómo codifica los algoritmos con TDD (cuando los resultados pueden ser complejos para realmente "Afirmar" con facilidad)?

Realmente puedo ver los aspectos positivos de TDD y estoy en el barco, pero es muy difícil para los principiantes cuando el código que escribes te lleva casi el doble de tiempo (y tienes compañeros que no ven a los profesionales y se burlan de ti con RAD)

Lo intenté varias veces y funcionó muy bien. Desafortunadamente, la mayoría de las veces, si puedo probar manualmente mi aplicación, pospongo las pruebas unitarias hasta que me siento demasiado aburrido para implementar otra cosa o hay un error que no puedo solucionar fácilmente.

Lo hago. El progreso de nuestras historias de usuario se rastrea en un tablero Kanban, que tiene un "¿Tiene una prueba?" columna a la izquierda (aguas arriba) de Desarrollo.

Este diseño algo inusual hace explícita una política: debe existir una prueba de aceptación automatizada fallida (generalmente, algunas de ellas). Debe ser rastreable a un requerimiento del cliente. Las pruebas de aceptación surgen de condiciones de satisfacción , que resultan de conversaciones que comienzan con un tarjeta de historia . Facilito talleres regulares donde hacemos una lluvia de ideas sobre los requisitos, identificamos vacíos y descubrimos las pruebas de aceptación clave que aseguran que el valor del usuario se entregue cuando pasan (la definición de hecho ). Es una actividad de colaboración entre programadores, analistas de negocios y, a veces, probadores.

El ciclo de retroalimentación de las pruebas de aceptación es bastante largo: puede llevar varios días completar la historia. El desarrollo tiene sus propios circuitos de retroalimentación TDD más cortos.

"[... sin estilo de prueba primero ...] Más parecido a Agile ..."

Esta es una tergiversación completa de Agile. La definición de hecho es un componente clave de Agile y uno de los pilares en los que se basa es la prueba de aceptación automática (lo que describí anteriormente es una forma de hacerlo). Si la programación extrema (XP) se usa como un método de implementación ágil, entonces Se prescriben ATDD / BDD y TDD.

Lo hago, pero generalmente solo para componentes que no son ui, y cuando sé que no puedo mantener todo el algoritmo para un módulo en mi cabeza al mismo tiempo, o cuando el módulo es una parte nueva de cualquier sistema en el que estoy trabajando, así que no puedo confiar en que la mayoría de las bibliotecas que estoy usando hayan sido altamente depuradas.

Esencialmente, lo hago cuando la complejidad del requisito significa que podría perderme en el código.

Es un hábito difícil de comenzar, y requiere la aceptación de la administración, pero, cuando sus pruebas comienzan a romperse a la mitad del desarrollo, ¡puede ser un salvavidas!

Quería hacer esta misma pregunta, para ver cuántas empresas realmente practicaban TDD.

En los 11 años que he estado programando profesionalmente, solo las dos últimas organizaciones estaban al tanto de TDD (eso abarca casi 5 años, antes de lo cual TDD no era tan popular como lo es hoy). Iré al grano y responderé a tu pregunta antes de pasar a mi argumento de venta para TDD :)

En la última empresa para la que trabajé (editor académico en línea de colecciones de humanidades y ciencias), sabíamos que necesitábamos practicar TDD, pero nunca llegamos allí. En nuestra defensa, teníamos una base de código de 250k, por lo que agregar pruebas a una base de código no comprobable de ese tamaño se sentía insuperable (¡ahora me siento culpable al escribir eso!). Incluso los mejores cometemos errores .

Cualquiera que haya hecho incluso una pequeña cantidad de TDD sabe cuán dolorosas pueden ser las pruebas de adaptación al código no comprobable de campo marrón ... Las causas principales son las dependencias implícitas (no puede tirar de todas las palancas para afirmar los resultados del código; no puede burlarse escenarios) y la violación del principio de responsabilidad única (las pruebas son complicadas, artificiales, requieren demasiada configuración y son difíciles de entender ).

Crecimos temporalmente nuestro equipo de control de calidad (de una, quizás dos personas a media docena o más) para probar la plataforma antes de cualquier lanzamiento. Fue enormemente costoso en cuanto al tiempo y económicamente, algunos lanzamientos tomarían tres meses para completar la 'prueba'. Incluso entonces sabíamos que íbamos a enviar problemas, simplemente no eran 'bloqueadores' o 'críticos', solo 'de alta prioridad'.

Si tiene una experiencia comercial de años, apreciará que todas las empresas afirmen tareas críticas y luego inventen un nivel de prioridad más alto por encima de eso, y muy probablemente uno por encima de eso también, especialmente cuando alguien de arriba está presionando una función / corrección de errores. Me estoy desviando ...

Me complace informar que estoy practicando TDD en mi empresa actual (casa de desarrollo de aplicaciones de telecomunicaciones, web y móviles), junto con Jenkins CI para dar otros informes de análisis estático (la cobertura de código es la más útil después de afirmar los pases de la suite de pruebas) . Los proyectos en los que he utilizado TDD son un sistema de pago y un sistema de computación grid.

El argumento de venta ...

A menudo puede ser una lucha cuesta arriba que justifica las pruebas automatizadas para los miembros del equipo no técnicos. Escribir pruebas agrega más trabajo al proceso de desarrollo, pero ... el tiempo que invierta en las pruebas ahora, ahorrará esfuerzos de mantenimiento más adelante. Realmente solo estás prestando tiempo . Cuanto más tiempo esté en uso el producto, mayor será el ahorro que obtendrá, y lo ayudará a evitar la gran reescritura .

Probar primero significa que está codificando su intención primero, y luego confirmando que su código cumple esa intención. Esto proporciona enfoque y destila su código para hacer solo lo que se pretende y no más (leer sin hinchazón). Es una especificación ejecutable y documentación al mismo tiempo (si su prueba está bien escrita, y las pruebas deberían ser tan legibles / limpias como el código de su sistema, ¡si no más!).

Los no programadores (a menudo) no tendrán esta información y, por lo tanto, TDD no tiene mucho valor para ellos, y se considera un acceso directo desechable a una fecha de lanzamiento anterior.

La programación es nuestro dominio, y en mi opinión esto hace que sea nuestra responsabilidad , como profesionales, asesorar sobre las mejores prácticas como TDD. No es para que los gerentes de proyecto decidan si se hace para reducir el tiempo de desarrollo, está fuera de su jurisdicción . De la misma manera que no le dicen qué marco, solución de almacenamiento en caché o algoritmo de búsqueda usar, no deberían decirle si debe emplear pruebas automatizadas.

En mi opinión, la industria del desarrollo de software (en general) está rota en la actualidad, el hecho de que realizar pruebas para su software NO es la norma.

Imagine esto en otras industrias: médica, aviación, automóvil, cosméticos, peluches, bebidas alcohólicas, etc. ¡Le pedí a mi prometida que nombrara una industria en la que no probaran el producto y ella no pudo!

Tal vez sea injusto decir que no se realizan pruebas porque sí ... pero en empresas sin pruebas automatizadas, es un proceso muy manual / humano (lectura torpe y a menudo propensa a errores).

Un punto que diría en tu pregunta ...

Por lo general, querían que el desarrollo comenzara de inmediato, o después de una breve etapa de diseño. Más parecido a Agile.

Ser "ágil" no prescribe proceder sin pruebas, el primer miembro que aparece en agilemanifesto.org es Kent Beck , el creador de XP y TDD.

Dos libros que recomiendo encarecidamente si estás interesado en TDD, o simplemente si no los has leído y eres un programador entusiasta (¿son todos los que leen esto, verdad?)

Creciente software orientado a objeciones guiado por pruebas

Código limpio - Serie Robert C Martin ("Tío Bob")

Estos dos libros se complementan entre sí y condensan mucho sentido en pocas páginas.

Gracias por hacer esta pregunta :)

Los que implementan clones. No puedo pensar en un mejor proceso cuando desarrollas algo, que funciona exactamente como un programa existente.

Obviamente, este es un caso bastante inusual, pero los desarrolladores de SQLite usan pruebas extensivamente. (Supongo que su proceso de desarrollo es primero de prueba, aunque no estoy seguro).

• 73,000 líneas de código
• 91,378,600 líneas de código de prueba

Ver http://www.sqlite.org/testing.html