¿Debo exigir pruebas unitarias a los programadores? [cerrado]

Trabajo en un lugar donde compramos muchos proyectos de TI. Actualmente estamos produciendo un estándar para requisitos de sistemas para la solicitud de proyectos futuros. En ese proceso, estamos discutiendo si podemos exigir o no pruebas unitarias automatizadas a nuestros proveedores.

Creo firmemente que las pruebas unitarias automáticas adecuadas son la única forma de documentar la calidad y la estabilidad del código. Todos los demás parecen pensar que las pruebas unitarias son un método opcional que concierne solo al proveedor. Por lo tanto, no exigiremos pruebas unitarias automatizadas, pruebas continuas, informes de cobertura, inspecciones de pruebas unitarias ni nada por el estilo. Encuentro esta política extremadamente frustrante.

¿Estoy totalmente fuera de lugar aquí?

Proporcione argumentos para cualquiera de las opiniones.

Creo firmemente que las pruebas unitarias automáticas adecuadas son la única forma de documentar la calidad y la estabilidad del código.

La cuestión es que no (o al menos muy rara vez) obtendrá una prueba unitaria automatizada adecuada al forzarla a las personas. Esa es una buena manera de obtener pruebas de mierda y aumentar el costo de los proyectos.

Personalmente, miraría hacia alguna demanda o SLA que implique calidad; independientemente de cómo se logre. Hace 10 años, las pruebas unitarias eran poco frecuentes en el mejor de los casos. No querrá esposar a sus proveedores en 10 años cuando tengamos mejores métodos para garantizar la calidad, pero su política desactualizada requiere que usen la forma tradicional.

Personalmente, creo que en su caso debería pensar en términos de pruebas de aceptación:

• Le han dado una caja negra y espera que se comporte de cierta manera.
• No pagará hasta que lo haga.
• Escriba pruebas unitarias que ejerciten el comportamiento que necesita ver, y si fallan, tienen que arreglarlo.

También tenga en cuenta que esto es una cuestión de confianza. Si no confía en su proveedor, entonces necesita obtener el código fuente, inspeccionarlo y compilarlo usted mismo. Cualquier cosa menor que la media que al menos la confianza de ellos alguna .

Creo firmemente que las pruebas unitarias automáticas adecuadas son la única forma de documentar la calidad y la estabilidad del código.

Me sorprende lo común que es este pensamiento. Automatizado, si. Pruebas unitarias (solo), no. Las pruebas de software automatizadas son mucho más que las pruebas unitarias solas. ¿Qué pasa con la integración, sistema, funcional, control de calidad? Por alguna razón, las personas tienden a pensar: "Ok, entonces tenemos pruebas unitarias adecuadas. Hecho con las pruebas, ¡llámalo el viernes por la noche!" . Las pruebas unitarias son solo el comienzo.

De todos modos, volvamos al tema. Estoy de acuerdo con que otros dicen que forzar cualquier cosa sobre alguien probablemente producirá resultados opuestos a los deseados. Nunca se sabe cómo funciona el equipo, tal vez obtuvieron un departamento de pruebas por valor de un millón de dólares y nunca escribieron pruebas de una sola unidad.

En mi primer trabajo, solía trabajar en un lugar donde teníamos 0 pruebas unitarias (éramos un montón de jóvenes lanzando cosas más o menos serias). Lo creas o no, funcionó. Claro, a nadie se le confió por qué se solucionó este error o qué se rompió, pero funcionó. Hubo momentos en que aparecía algún error absolutamente aleatorio, perobate de béisbol y riesgo de quemar su apartamentoAlgunas horas extra pueden hacer maravillas. ¿Quizás sus proveedores usan técnicas similares ?

Dudo mucho que su gerencia esté dispuesta a pagar por las pruebas de unidad adecuadas en un contrato. Las pruebas unitarias adecuadas cuestan tanto como el código que prueban, pero otorgan poco valor percibido al usuario final para que no se consideren igualmente valiosas. Ninguna empresa de desarrollo de calidad estará dispuesta a gastar el esfuerzo de desarrollo en pruebas unitarias por un costo menor que otras partes, ya que no están perjudicando el trabajo, pueden hacer más para encontrar 2 contratos que toman la misma cantidad de tiempo sin requisitos de prueba unitaria.

Es probable que las pruebas unitarias exigentes aumenten las cotizaciones recibidas a un nivel irrazonable, y es probable que sea la primera concesión hecha para obtener un precio más bajo.

El costo de no tener pruebas unitarias depende de cuánto van a extender / admitir el código ustedes mismos. También sería importante llegar a inspeccionar partes del código para tener una idea de la calidad.

Si solo está comprando los proyectos para poder usarlos como una biblioteca de terceros y no cree que los modificará, entonces el riesgo de un código de menor calidad es menor, siempre que realmente funcione.

Estas son, en última instancia, decisiones comerciales, aunque también debe asegurarse de que quien tome la decisión esté al tanto de la valoración técnica. Si necesita explicárselo a la gerencia, explíquele que es como comprar un automóvil usado. En última instancia, depende del comprador decidir si vale la pena, pero llevarlo a un mecánico es una buena idea para que sepa que no obtendrá un limón.

Usted está pagando, puede exigir lo que quiera, incluidas copias / informes de todas sus pruebas unitarias.

Incluso podría escribir las pruebas, o al menos las especificaciones de la prueba usted mismo.

Estoy de acuerdo con su opinión en que es una muy buena medida de la calidad del código. Si un proveedor rechazara esta demanda, sonaría la alarma, ¿por qué no querrían hacerlo, tienen bajos estándares de calidad y toman atajos?

Tiene toda la razón en que su proyecto necesita pruebas unitarias automatizadas, pruebas continuas, informes de cobertura e inspecciones de pruebas unitarias.

Sin embargo, las cosas exigentes no lograrán los resultados que desea como otros han detallado.

Su desafío es explicar y persuadir a las personas, ¡habilidades mucho más difíciles!

Comenzaría inicialmente con la administración, explicando los pros y los contras de las pruebas y los beneficios en el futuro. Tenga cuidado de no comunicar la emoción detrás de declaraciones como "Escribo pruebas unitarias CORRECTAS" (mayúsculas). No querrás 'gritar' las palabras (como implica TODAS LAS MAYÚSCULAS), convencerás y convencerás a las personas para que ellas mismas puedan elegir la solución correcta.

En última instancia, si no puede introducir estas metodologías y lograr que se adopten donde está, además, si le apasiona tanto como dice (¡lo cual es bueno!), Iría a una compañía diferente, ya que hay muchas que valoran estas cosas. y te daría la bienvenida a bordo. Solo asegúrate de estar al frente de ellos en las entrevistas para que sepan dónde están tus pasiones y si encajarás bien.

Forzar la prueba automatizada en alguien no logrará los resultados que desea, como señalaron @Joachim Sauer y @Telastyn en sus comentarios. Para muchas personas, las pruebas unitarias automatizadas son un gran cambio en su pensamiento. Porque mucha gente escribe código que funciona, pero no es muy comprobable. Podría escribir una página web ASP.NET donde toda la lógica, la consulta de la base de datos, las reglas de negocios, los objetos, etc., se encuentran en el código subyacente. ¿Funcionará la página? Sí. ¿Es comprobable utilizando pruebas unitarias automatizadas? Absolutamente no. Si un proveedor no cuenta con pruebas unitarias automatizadas, se necesitará un gran esfuerzo para aprender a escribir pruebas unitarias correctamente y, como resultado de esto, volver a escribir o refactorizar su código para que sea más fácil de probar. Lo más probable es que te pasen ese costo.

El hecho es que el proveedor le está dando un producto, ya sea un .dll o una aplicación de Windows, y espera que funcione el 99% del tiempo. Claro que hay errores aquí y allá, pero en su mayor parte debería funcionar. Esa es una expectativa razonable, especialmente si el proveedor quiere retener su negocio. Si es una caja negra, entonces realmente no importa cómo lo hagan funcionar, podrían usar una ola humana de probadores, o una habitación llena de monos golpeando teclas al azar. Mientras funcione. Pero tendrían que proporcionarle algún otro tipo de documentación sobre cómo usarlo.

Sin embargo, si le dieron el código fuente para que pueda modificarlo, entonces esperaría pruebas unitarias. No trabajaría con una empresa que no suministra pruebas unitarias. ¿De qué otra forma sabrías que una modificación que realizas no lo controla todo?

Las pruebas unitarias son una indicación de cómo ese proveedor maneja los riesgos durante el ciclo de desarrollo. Aquellos que usan pruebas unitarias valoran reducir el riesgo y la calidad de esas pruebas es una indicación de cuánto riesgo se ha manejado.

Dicho esto, las pruebas unitarias no definen qué nivel de riesgo intenta abordar ese proyecto. Tampoco juega ningún papel en la reducción del riesgo introducido por las malas prácticas de programación.

Por lo tanto, podría tener un proveedor que tenga prácticas de prueba sólidas pero que continúe escribiendo código de alto riesgo, mientras que otro proveedor que realice cero pruebas pero escriba código de bajo riesgo. Si los dos proveedores ofrecen el mismo producto, lo mejor es ir con el proveedor de bajo riesgo.

Esto solo puede medirse entrevistando, asesorando y aprendiendo sobre las personalidades y habilidades de las personas involucradas con ese proveedor.

Encontré este artículo sobre la compra de software personalizado bastante útil: http://blog.8thlight.com/paul-pagel/2012/06/20/entrepreneurs-guide-to-buying-software.html

La pregunta número uno que recomiendan hacer es si el proveedor escribe pruebas.

Acordar con otros que exigen pruebas unitarias conduciría a pruebas por el bien de las pruebas; algo que es muy contrario a lo que quieres.

En el proceso de examinar a sus proveedores; pregúnteles cuál es su proceso de desarrollo , ya que las pruebas son solo una parte de ese proceso.

¿Tienen un proceso de construcción automatizado? ¿Siguen algún paradigma de gestión? ¿Tienen probadores debidamente capacitados y un equipo de garantía de calidad independiente ? ¿Qué hay de los estándares de documentación?

Estos lo ayudarán a juzgar la calidad general de su proceso y, a su vez, la calidad de lo que producen.

Me parece que incluir este requisito tendría pocos beneficios prácticos, ya que sería imposible de cumplir.

Puede exigir el código para las pruebas reales o un informe de qué pruebas reales se ejecutaron y pasaron. Si se trata de un proyecto patentado, el proveedor probablemente no querría proporcionarlo, ya que probablemente sería muy sugestivo de los detalles del código, y puede que se enoje al hacer que proporcione detalles de implementación de bajo nivel y le diga cómo hacer su trabajos. En algún momento, tiene que haber algo de confianza.

Si no lo hace, podrían hacerlo volar, pero simplemente marcando la casilla junto a "ejecuta un conjunto de pruebas unitarias" para cumplir con el requisito escribiendo una sola prueba que pase si su utilidad se compila y ejecuta o un medio similar. esfuerzo.

Entonces, aunque las pruebas unitarias automatizadas son una práctica recomendable, no creo que sea práctico insistir en ello por parte de proveedores externos.

Como muchas personas han señalado, obligar a los vendedores a escribir pruebas unitarias (o mejor, una combinación de pruebas automatizadas de unidad e integración) para cumplir un contrato probablemente no arrojará resultados de alta calidad. Por otro lado, estoy de acuerdo en que las pruebas automatizadas son, con mucho, el mejor método actualmente en uso para garantizar la calidad del código.

Creo que el código escrito con pruebas unitarias es mucho más fácil de mantener que el código que se escribió primero y luego se agregaron pruebas unitarias. Fuerza la modularidad y las dependencias mínimas. Las pruebas de integración también son necesarias para verificar la corrección del código, pero no tienen el mismo impacto en la calidad del código que está escrito. En esencia, las pruebas de integración automatizadas podrían agregarse después del hecho, pero las pruebas unitarias tienen el mayor impacto cuando se escriben con el código original.

Mi consejo para su situación es buscar vendedores que prefieren escribir código con pruebas unitarias, y elegirlos entre los vendedores que tienden a no escribir código con pruebas unidas. Si la gerencia lo paga, incluya pruebas automatizadas en el contrato, pero SOLO SI EL VENDEDOR SE UTILIZA PARA ESCRIBIR EL CÓDIGO CON LAS PRUEBAS DE LA UNIDAD.

Vamos a aclarar las prioridades primero ...

En su rol de cliente, su principal preocupación no es la prueba unitaria

Si está utilizando proveedores que producen software para usted, entonces realmente no debería preocuparse si están utilizando una metodología u otra. Lo que está en juego es adquirir algún tipo de solución que lo ayudará a alcanzar sus objetivos. Lo único que debería importarle es si esa solución es aceptable o no. Es por eso que tenemos pruebas de aceptación, ya que recae en su responsabilidad de asegurarse de que obtenga lo que desea. Es en el momento crucial de la aceptación del cliente que el dinero se transferirá de los bolsillos de su empresa al bolsillo del proveedor.

Podría exigir pruebas unitarias como requisito de entrega, pero hay varios problemas de herencia con ellos, el más grave es que no hay una forma segura de determinar las métricas de antemano:

• ¿Cuál es la cantidad aceptable de pruebas unitarias?

¿Debería haber 10 pruebas? ¿Qué tal 100 pruebas? ¿Qué tal 1000 pruebas? En realidad, es bastante difícil determinar al principio cuántas pruebas necesitará. El número real es indeterminable realmente ... como el problema de detención ... pero no estamos resolviendo ese problema.

Solo desea un software que tenga pruebas unitarias para que pueda continuar el desarrollo. Las pruebas unitarias aún no dicen lo que has roto, pero son increíblemente adecuadas para decirte cuándo el código tiene un error de regresión.

• ¿Cuál es un nivel aceptable de cobertura de código?

"100%, por supuesto!" pensarías Lamentablemente, esa métrica es engañosa; incluso si tuviera una cobertura de código del 100%, ¿está realmente seguro de que las cosas funcionan como se esperaba? Es posible tener una cobertura del 100%, pero no se puede hacer.

Lo que realmente necesita hacer es una prueba exploratoria, es decir, encontrar a alguien que sea realmente bueno rompiendo cosas y dejar que haga la prueba. Para encontrar los errores que ningún desarrollador ha pensado.

Además, el 100% a veces es inalcanzable con pruebas unitarias puras si tiene algunos trucos de rendimiento necesarios y usa patrones de diseño que son difíciles de probar (busque "singleton" y "tdd" en su motor de búsqueda favorito y encontrará algunos ejemplos).

Desea que el software entregado funcione y el documento de especificación es su única garantía de que lo hará.

Va a necesitar un mayor nivel de prueba

Su documento de especificación tiene que ser verificado de alguna manera. Cada punto tiene que pasar con sus proveedores que tengan objetivos claros y criterios de aceptación. Una organización de control de calidad que funcione bien (o un probador impresionante si tiene un presupuesto limitado y un alcance limitado) proporcionaría los casos de prueba para verificar estos criterios de aceptación. También necesita a alguien para verificar esos criterios de aceptación.

Hay varias formas de verificar sus objetivos, y si alguien me dice que no puede establecer objetivos razonables de calidad, rendimiento y eficiencia, los alcanzaré en la cabeza con libros grandes y pesados ​​sobre pruebas exploratorias, de rendimiento y de usabilidad, respectivamente. Puede ser fácil exagerar con los objetivos, pero el conocimiento y la comunicación lo ayudarán a establecer objetivos realistas.

No soy un abogado, pero la mayoría de los contratos de proyectos (que es básicamente la madre de todas las especificaciones para el proyecto) que he leído generalmente tienen un criterio de relación de defectos que estipula cuántos errores se consideran aceptables. Los errores generalmente se determinan a través de la gravedad, los errores que detienen la exposición que se encuentran por QA tienen una baja tolerancia, mientras que las imperfecciones menores tienen una alta tolerancia. En proyectos reales es difícil exigir que el software tenga 0 defectos. Los plazos generalmente ponen fin a esa práctica. Es en estas situaciones que debe comenzar a negociar el alcance.

La mayoría del software suministrado que he visto generalmente no se entrega con pruebas unitarias. Podría argumentar que los proveedores deben ser lo suficientemente profesionales como para entregar esto, sin embargo, la razón principal por la que desea que se le entreguen las pruebas unitarias es para asegurarse de que no obtenga errores de regresión y también permita la refactorización. En la vida real con proyectos con plazos ajustados, tanto el proveedor como el cliente reducirán el alcance y las pruebas unitarias generalmente desaparecerán y se eliminarán de la lista de resultados requeridos.

Es un poco triste que el software de código abierto de alto perfil se entregue con pruebas unitarias, pero un desarrollador de software profesional no puede, ¿verdad?

Entonces, ¿cuándo, como cliente, me preocupo por las pruebas unitarias?

Yo diría que la única vez que realmente le interesaría la prueba unitaria es si el software entregable es un componente autosuficiente que no se ejecuta como un programa independiente, para lo cual la prueba más gruesa que puede hacer es una prueba unitaria . Las bibliotecas de clases serían un tipo de producto que se puede entregar junto con pruebas unitarias.

¿Cómo sabe que los vendedores no están escribiendo pruebas unitarias?

Tal vez la gerencia y el vendedor tuvieron una reunión y el vendedor dijo que el código cuesta $ X y las pruebas unitarias cuestan $ Y. Penny pinching management dijo que solo queremos el código.

El vendedor decidió escribir pruebas unitarias de todos modos (debido a la calidad) y simplemente no compartirlas con usted (debido a la ventaja competitiva).

Ahora necesita hacer algunos ajustes importantes al software. Como posee el código, puede hacerlo usted mismo o contratarlo de manera competitiva (no necesariamente para el proveedor original). Pero como no compró las pruebas unitarias, el proveedor original podrá hacer un trabajo de calidad comparable a un precio más barato que cualquier competidor.

Hay muchos proyectos que tienen mucho éxito a pesar del hecho de que no utilizan pruebas unitarias. Solo mire el kernel de Linux, es un proyecto gigantesco con una complejidad mucho más allá de lo que encontraría en cualquier proyecto normal, y aún funciona. Entonces, si el resultado es un buen software, no debería importarle cómo lo lograron.

No, no es necesario que exija unidades de prueba completas y automatizadas. Es más importante que le proporcionen los documentos de estrategia de prueba adecuados. Lo estamos haciendo bien de esta manera.