¿Cuál es la forma más convincente de requerir pruebas unitarias formalizadas?

Question

Esto ciertamente presupone que las pruebas unitarias son algo bueno. Nuestros proyectos tienen cierto nivel de pruebas unitarias, pero es inconsistente en el mejor de los casos.

¿Cuáles son las formas más convincentes que ha utilizado o ha utilizado para convencer a todos de que las pruebas unitarias formalizadas son buenas y que hacerlo es realmente lo mejor para los proyectos 'más grandes' que trabajamos en. No soy desarrollador, pero estoy en Quality Assurance y me gustaría mejorar la calidad del trabajo entregado para garantizar que esté listo para la prueba.

Por unidad de pruebas formales, simplemente estoy hablando de

• La identificación de las pruebas unitarias para ser escritas
• La identificación de los datos de prueba (o describirlo)
• Escribiendo estas pruebas
• Seguimiento estas pruebas (y reutilizar según sea necesario)
• Haciendo que los resultados estén disponibles

Answer 1

Por lo tanto, dos años después de hacer esta pregunta, encuentro que una respuesta inesperada fue que cambiar a un nuevo SDLC era lo que se necesitaba. Hace cinco años, establecimos nuestro primer SDLC formal. Mejoró nuestra situación, pero omitió algunas cosas importantes, como la automatización. Ahora estamos en el proceso de establecer un nuevo SDLC (bajo nueva administración) donde uno de los inquilinos es la automatización. No solo pruebas unitarias automatizadas, sino pruebas funcionales automatizadas.

Supongo que la lección es que estaba pensando demasiado pequeño. Si va a cambiar la forma en que crea el software, vaya a "cerdo entero" y haga un cambio drástico en lugar de proponer un cambio incremental si no está acostumbrado a eso.

Answer 2

Recuérdele a su equipo u otros desarrolladores que son profesionales, no amateurs. ¡Trabajó para mi!

Además, es un estándar de la industria en estos días. Sin experiencia en pruebas de unidades, son menos deseables y menos valiosos como empleados para futuros empleadores potenciales.

Answer 3

La primera vez que solo tiene que seguir adelante y escribir y mostrar a la gente que vale la pena. He descubierto en tres proyectos que es la única forma de convencer a la gente. Algunas personas que no codifican (por ejemplo, gerentes de proyecto junior) no podrán ver el valor hasta que no los mire directamente a la cara.

Answer 4

El evento que me convenció fue cuando logramos retroceder un error tres veces, en tres lanzamientos consecutivos. Una vez que me di cuenta de lo mucho más productivo que era como programador cuando no estaba constantemente solucionando errores triviales después de que habían ido al cliente, y podía tener una sensación cálida y confusa de que el código de colegas haría lo que afirmaban que sería, me volví un converso

Answer 5

Una forma muy convincente es hacer la prueba de la unidad formalizada, independientemente de lo que haga su equipo/compañía. Esto podría requerir un esfuerzo adicional de tu parte, especialmente si no tienes experiencia con este tipo de práctica.

Cuando pueda, entonces, muestre que su código es mejor y que está siendo más productivo que sus compañeros desarrolladores, ellos querrán saber por qué. Luego, proporciónales tus métodos de prueba de unidad favoritos.

Una vez que hayas convencido a tus compañeros desarrolladores, convence a la gerencia.

Answer 6

En mi equipo de software, tendemos a escribir un caso de pequeña empresa sobre estos problemas y presentarlo a la gerencia para tener el tiempo disponible para crear y rastrear pruebas. Explicamos que el tiempo necesario para realizar la prueba está bien compensado cuando llega el momento crucial y todo está en juego. También configuramos un servidor de compilación Hudson para centralizar el seguimiento de las pruebas unitarias. Esto hace que sea mucho más fácil para los desarrolladores hacer un seguimiento de las pruebas fallidas y descubrir problemas recurrentes.

Answer 7

Educación y/o certificación.

Proporcione a los miembros de su equipo una capacitación formal en el campo de las pruebas, tal vez con un examen de certificación (dependiendo de los miembros de su equipo y de su propia actitud hacia la certificación). Llevarás las pruebas a un nivel más alto de esa manera, y los miembros de tu equipo tendrán más probabilidades de adoptar una actitud profesional hacia las pruebas.

Answer 8

Algunas veces, por ejemplo, es la mejor manera. También encuentro que recordar a la gente que ciertas cosas simplemente no ocurren cuando las cosas están bajo prueba. La próxima vez que alguien te pida que escribas algo, hazlo con exámenes independientemente. Eventualmente, sus pares estarán celosos de la facilidad con la que puede cambiar su código y saber que todavía funciona.

En cuanto a la gestión, debe enfatizar cuánto tiempo se desperdicia debido a la explosión nuclear que ocurre cuando necesita realizar un cambio en la base de código X que no está bajo prueba.

Muchos desarrolladores no se dan cuenta de cuánto refactorizan sin asegurarse de que están conservando el comportamiento en todo el sistema. Para mí, este es el mayor beneficio para las pruebas unitarias y TDD en mi opinión.

1. Requisitos de software cambian
2. cambios en el software para satisfacer los requisitos

La única certeza es el cambio. Cambiar el código que no está bajo prueba requiere que el desarrollador esté al tanto de todos los efectos colaterales de comportamiento posibles. La realidad es que los codificadores que piensan que pueden leer en cada permutación, lo hacen mediante un proceso de ensayo y error hasta que nada se rompe, obviamente. Llegados a este punto, se registran.

El programador pragmático reconoce que no es perfecto y lo sabe todo, y que las pruebas son como una red de seguridad que les permite caminar la cuerda floja de refactorización de forma rápida y segura.

En cuanto a cuándo escribir la prueba en el código greenfield, tendría que abogar tanto como sea posible. Pase el tiempo definiendo los comportamientos que desea que salgan de su sistema y escriba pruebas inicialmente para expresar esas construcciones de alto nivel. Las pruebas unitarias pueden venir cuando los pensamientos cristalizan.

Espero que esto ayude.

Answer 9

Uso Maven con los complementos Surefire y Cobertura para todas mis compilaciones. Los casos de prueba reales se crean con JUnit, DbUnit y EasyMock.

La identificación de pruebas unitarias trato de seguir Test Driven Development, pero para ser honestos, por lo general sólo hacer eso por el puñado de los casos de prueba y luego volver y la creación de test para el borde y los casos de excepción después.

Identificación de datos de prueba DbUnit es ideal para cargar datos de prueba para las pruebas de su unidad.

Escritura de casos de prueba Uso JUnit para crear casos de prueba. Intento escribir casos de prueba autodocumentados pero usaré Javadocs para comentar algo que no es obvio.

Seguimiento & haciendo que los resultados disponibles que integran la unidad de pruebas en mi ciclo de acumulación Maven usando el plugin de éxito seguro y yo uso el plugin Corbertura para medir la cobertura alcanzada en dichas pruebas. Siempre genero y publico un sitio web que incluye los informes de Surefire y Cobertura como parte de mi compilación diaria para poder ver qué pruebas fallaron/pasaron.

Answer 10

Ya en el día en que desarrollé Cobol en mainframes lo hicimos religiosamente en las varias compañías en las que trabajé y fue aceptado como la forma en que hacía las cosas porque el entorno lo imponía. Creo que era un esquema muy típico para la época y quizás algunas de las razones podrían aplicarse a usted:

Al igual que la mayoría de los entornos de mainframe, teníamos tres dominios, desarrollo, control de calidad y producción. Los programadores se desarrollaron en desarrollo y unidades probadas allí, y una vez que firmaron y estaban contentos, la unidad se migró al entorno de control de calidad (con los documentos de prueba y resultados) donde el personal de control de calidad lo probó en el sistema. El desarrollo de la migración de control de calidad fue un paso formal que sucedió de la noche a la mañana. Una vez que QA'ed el código se migró a producción, y tuvimos muy pocos errores.

La motivación para realizar las pruebas de la unidad correctamente fue que si no lo hacía y el personal de control de calidad encontró un error, era obvio que no había hecho el trabajo. En consecuencia, su reputación depende de cuán riguroso sea. Por supuesto, la mayoría de la gente terminaría con el error ocasional, pero los programadores que produjeron código sólido probado todo el tiempo pronto obtuvieron una reputación de estrella y también se notó a los que produjeron código defectuoso. El impulso siempre sería mejorar tu juego, y en consecuencia, la cultura producida fue una que empujó hacia el código libre de errores entregado por primera vez.

Extracción de puntos pertinentes -

1. Coder reputación atado con entrega de error de código probado libre
2. sobrecarga significativa asociada con el movimiento de código probado unidad al siguiente nivel, por lo que la motivación no repetir este y conseguir que bien la primera vez.
3. Pruebas del sistema realizadas por diferentes personas para la prueba de la unidad - idealmente un equipo diferente.

Estoy seguro de que su entorno será diferente, pero los principales podrían ser traducibles.

Answer 11

Como líder de equipo, es mi responsabilidad garantizar que mis programadores realicen pruebas unitarias en todos los módulos en los que trabajan. Supongo que en este punto, ni siquiera es una cuestión de cómo convencerlos, es obligatorio. No a veces, no en proyectos grandes, todo el tiempo. Las pruebas unitarias son la primera línea de defensa contra poner algo en producción que tendrá que mantener. Si se pone en producción algo que no ha sido completamente probado por la unidad y el sistema, volverá a morderlo. Supongo que una de las políticas que tenemos aquí para respaldar esto es que si se dispara la producción o causa problemas, entonces el programador responsable de codificar y probar ese módulo será el que tenga que encargarse de los problemas, hacer la limpieza. , etc. Eso solo es un motivador bastante bueno.
El otro es que se trata de orgullo. Trabajo en una tienda de alrededor de 75 codificadores, aunque eso es grande según algunos estándares, es lo suficientemente pequeño para que todos nos conozcamos. También es lo suficientemente pequeño como para saber en qué está trabajando el otro, y cuando pasa a producción, somos conscientes de cualquier terminación, falla, etc. Si tiene cuidado, realice las pruebas de unidad y sistema, las posibilidades de mover algo a la producción sin causar fallas aumenta significativamente. Puede tomar un tiempo o dos para mover algo a la producción y no darse cuenta de ello, pero hay grandes recompensas involucradas en no estropear.Es muy lindo escuchar felicitaciones en el pasillo cuando mueves un proyecto y no se arruina.

Answer 12

Hay una gran diferencia entre convencer y requiere.

Si encuentra una manera de convencer a sus colegas para que los escriban, genial. Sin embargo, si crea algunas reglas formalizadas y les exige que escriban pruebas unitarias, encontrarán una forma de superar esto. Como resultado obtendrá un conjunto de pruebas unitarias que no valen nada: Habrá una prueba unitaria para cada clase individual disponible y probarán a los setters y getters.

Piense dos veces antes de crear y aplicar las reglas. Los desarrolladores son buenos para superarlos.

Answer 13

Escriba un montón de ellas y demuestre que las pruebas unitarias han mejorado su productividad y la calidad de su código. Sin algún tipo de prueba, a veces las personas no creerán que vale la pena.