¿Las grandes empresas utilizan burlas/trozos?

Question

¿Alguien ha trabajado en una compañía grande, o en un proyecto muy grande, que utilizó pruebas unitarias con éxito?

Nuestra base de datos actual tiene ~ 300 tablas, con ~ 100 raíces agregadas. En general, hay ~ 4000 columnas, y tendremos ~ 2 millones de líneas de código cuando se complete. Me preguntaba: ¿las compañías con bases de datos de este tamaño (o mucho más grandes) realmente realizan el esfuerzo de simular y anotar sus objetos de dominio para probar? Han pasado dos años desde que trabajé en una empresa grande, pero en ese momento todas las aplicaciones grandes se probaron a través de pruebas de integración. Las pruebas unitarias generalmente fueron desaprobadas si requirieron mucha configuración.

Empiezo a sentir que las pruebas unitarias son una pérdida de tiempo para todo menos métodos estáticos, ya que muchos de nuestros métodos de prueba tardan tanto o más en escribir que el código real ... en particular, la configuración/organizar los pasos. Para empeorar las cosas, uno de nuestros desarrolladores sigue citando cómo Unit Testing y los métodos ágiles fueron una falla tan abyecta en el proyecto Chrysler de Kent Beck ... y que simplemente no es una metodología que se adapte bien.

Cualquier referencia o experiencia sería genial. A la gerencia le gusta la idea de Unit Testing, pero si ven la cantidad de código adicional que estamos escribiendo (y nuestra frustración), estarán encantados de dar marcha atrás.

Answer 1

He visto TDD funcionan muy bien en proyectos grandes, especialmente para ayudarnos a tener bajo control una base de código heredada. También he visto trabajar a Agile a gran escala, aunque solo hacer prácticas ágiles por sí solo no es suficiente, creo. Richard Durnall escribió una gran publicación sobre cómo se rompen las cosas en una empresa a medida que Agile gana terreno. Sospecho que Lean puede estar mejor en niveles más altos en una organización. Ciertamente, si la cultura de la empresa no es una buena opción para Agile cuando comienza a usarse en múltiples proyectos, no funcionará (pero tampoco lo hará), terminará con una empresa que no puede responder de manera efectiva al cambio. de cualquier manera).

De todos modos, volvemos a TDD ... A veces, probar unidades independientes de código puede ser complicado, y si hay un gran objeto de dominio basado en datos involucrado, con frecuencia no me burlo. En su lugar, utilizo un patrón de generador para facilitar la configuración de ese objeto de dominio de la manera correcta.

Si el objeto de dominio tiene un comportamiento complejo, podría simular eso para que se comporte de manera predecible.

Para mí, el propósito de escribir pruebas unitarias no es realmente para las pruebas de regresión. Me ayuda a pensar sobre el comportamiento del código, sus responsabilidades y cómo utiliza otras piezas de código para ayudarlo a hacer lo que hace. Proporciona documentación para otros desarrolladores y me ayuda a mantener mi diseño limpio. Los considero ejemplos de cómo puedes usar un código, por qué es valioso y el tipo de comportamiento que puedes esperar de él.

Al pensar en ellos de esta manera, tiendo a escribir pruebas que hacen que el código sea fácil y seguro de cambiar, en lugar de fijarlo para que nadie pueda romperlo. Descubrí que centrarse en burlarse de todo, especialmente los objetos de dominio, puede causar pruebas bastante frágiles.

El propósito de TDD es no probar. Si quieres probar algo, puedes pedirle a un verificador que lo mire manualmente. La única razón por la que los evaluadores no pueden hacer eso siempre es porque seguimos cambiando el código, por lo que el objetivo de TDD es hacer que el código sea fácil de cambiar. Si su TDD no le facilita las cosas, busque una forma diferente de hacerlo.

Answer 2

He tenido buenas experiencias con objetos simulados y pruebas unitarias en proyectos en los que había mucho diseño inicial y una línea de tiempo cómoda para trabajar. Desafortunadamente, a menudo es un lujo que la mayoría de las empresas no pueden permitirse arriesgarse Las metodologías GTD y GTDF tampoco ayudan realmente al problema, ya que ponen a los desarrolladores en una cinta de lanzamiento.

El gran problema con las pruebas unitarias es que si no se adhiere a un equipo completo, lo que sucede es que un desarrollador mira el código con gafas de color rosa (y no por su propia cuenta) implementa solo el feliz pruebas de ruta que son lo que se les ocurre. Las pruebas unitarias no siempre se mantienen tan bien como deberían debido a que los casos en las esquinas pasan desapercibidos, y no todos beben Kool-Aid. Las pruebas son una mentalidad muy diferente a la de los algoritmos, y muchos desarrolladores simplemente no saben cómo pensar de esa manera.

Cuando las iteraciones y los ciclos de desarrollo son ajustados, me encuentro ganando más confianza en la calidad del código confiando en herramientas de análisis estáticos y de complejidad. (FindBugs, PMD, Clang llvm, etc.) Incluso si se encuentran en áreas que no puedes abordar directamente, puedes marcarlas como minas terrestres y ayudar a determinar mejor el riesgo al implementar nuevas funciones en esa área.

Answer 3

Si encuentra que la burla/el punteado es doloroso y lleva mucho tiempo, es probable que tenga un diseño que no esté hecho para la prueba de la unidad. Y luego usted refactoriza o vive con eso.

Me gustaría refactorizar.

Tengo una gran aplicación y no veo problemas para escribir pruebas unitarias y cuando lo hago, sé que es hora de refactorizar.

Por supuesto, no hay nada de malo con la prueba de integración. De hecho, también tengo esos para probar el DAL u otras partes de la aplicación.

Toda la prueba automática debe formar un todo, la prueba de unidad es solo una parte de ellos.

Answer 4

Sí lo hacen. Bastante extensivamente.

La parte difícil es conseguir la disciplina en lugar de escribir código limpio - y (la parte más difícil) la disciplina para hacer mella a mal código de refactorización a medida que avanza.

He trabajado en uno de los bancos más grandes del mundo en un proyecto que se ha utilizado desde Nueva York, Londres, París y Tokio. Usó burlas muy bien y con mucha disciplina teníamos código bastante limpio.

Dudo que los burladores sean el problema, son solo una herramienta bastante simple. Si tiene que confiar mucho en ellos, suponga que necesita burlarse de los simulacros de devolución de burlas, entonces algo ha salido mal con la prueba o el código ...