Si las pruebas unitarias son tan buenas, ¿por qué no lo hacen más empresas? [cerrado]

La primera empresa de software real en la que trabajé tenía que ver con las pruebas unitarias (NUnit). No sé si éramos muy estrictos en ese entonces; no tengo idea de cómo era nuestra cobertura de código y estaba escribiendo la mayoría de las pruebas unitarias. Desde entonces, me he encontrado con algunas empresas que hacen muchas pruebas, pero es una prueba de silla: depende de la presencia de una persona, tiene poca repetibilidad y pocas posibilidades de detectar errores. La otra actitud es: era algo con lo que querían empezar "en el futuro"; básicamente cuando el dinero cae del cielo.

Extraño las pruebas unitarias, simplemente hace la vida más fácil. Pero descubro que cuando busco un nuevo trabajo, las pruebas unitarias son algo que a las empresas les gustaría "empezar" en el futuro o algo que no hacen en absoluto (uhh, ha existido por un tiempo ¡ahora!). Yo diría que entre el 60 y el 75% de los requisitos de trabajo que he examinado durante los últimos 2 años no incluyen pruebas unitarias en absoluto. Solo puedo pensar en uno o dos que tuvieran experiencia en pruebas unitarias como requisito (para un puesto de desarrollador de nivel medio).

Entonces la pregunta es, ¿qué falta ? Creo que hace que la gente sea más productiva, pero eso solo después de pasar una gran cantidad de tiempo realmente haciéndolo. ¿No hay buenos estudios sobre el ahorro de costes de las pruebas unitarias? ¿Es el tipo de empresa que estoy viendo?

Editar: aunque el título es un poco defensor de los demonios, me considero un proponente de pruebas unitarias.

En mi experiencia, hay un par de factores involucrados en esto:

1. La gerencia no comprende realmente qué son las pruebas unitarias o por qué tienen un valor intrínseco real para ellos.
2. La gerencia tiende a estar más preocupada por la entrega rápida del producto y (incorrectamente) ve las pruebas unitarias como contraproducentes para ese objetivo.
3. Existe la idea errónea de que las pruebas pertenecen únicamente al componente de control de calidad. Los desarrolladores son programadores y no pueden escribir pruebas.
4. Existe la idea errónea de que la administración tendrá que gastar dinero para realizar las pruebas unitarias correctamente, a pesar de que las herramientas están disponibles gratuitamente. (Por supuesto, hay que considerar el tiempo de aceleración del desarrollador, pero no es realmente prohibitivo).
5. La respuesta de Will completará esta respuesta: es muy difícil determinar el valor del código de prueba (editar jcollum)

Naturalmente, hay otros factores, pero esos son los que me he encontrado hasta ahora.

1) Es difícil
2) Se necesita tiempo
3) Es muy difícil determinar el valor del código de prueba

El punto 3 es pegajoso. Las buenas pruebas unitarias reducen los errores. Pero también lo hace un buen código de producción. ¿Cómo determina cuántos errores no existen debido a sus pruebas unitarias? No se puede medir lo que no existe. Puede señalar estudios, pero no encajan bien en la hoja de cálculo de su gerente comercial.

Es fácil echarle toda la culpa a la "gestión". Pero, ¿la gerencia realmente le está diciendo que específicamente no realice ninguna prueba unitaria?

La administración en general no le dice (y probablemente no debería) cómo hacer su trabajo, ya sea modularización, tipos de datos abstractos, patrones de diseño o pruebas unitarias. Estas son herramientas comerciales que aplica un ingeniero de software competente y exitoso, pero no un ingeniero deficiente.

Creo que la verdadera respuesta a tu pregunta es: las pruebas unitarias son realmente difíciles y los estudiantes de informática no están capacitados para ello.

Es fácil cuando está escribiendo su propia clase de cadena. Cuando está probando un producto de la vida real, se encuentra con desafíos de los que nadie le habló en las diapositivas de PowerPoint:

• La interacción del usuario. La mitad de su aplicación es la lógica de la interfaz de usuario. ¿Cómo lo prueba de forma automatizada, que no se estropea si mueve un botón?
• Interacción con API y frameworks externos. Si está escribiendo un controlador de kernel de Windows, ¿cómo lo prueba unitariamente? ¿Escribe stubs para cada IRP y función del kernel que usa, creando efectivamente una simulación del kernel del sistema operativo?
• Las comunicaciones en red son cosa del siglo XXI. ¿Cómo se coordina una prueba unitaria que consta de varios componentes distribuidos?
• ¿Cómo eliges buenos casos de prueba? Normalmente veo gente que intenta el enfoque de "hacer cosas al azar en un ciclo de 1000 iteraciones y ver si se rompe". Cuando hace esto, el esfuerzo es mayor que los retornos, se pasan por alto errores importantes y se abandonan las pruebas unitarias.
• ¿Cómo prueba que se cumplen los requisitos de desempeño?
• El conocimiento de los patrones en las pruebas es escaso: stubs, respuestas enlatadas, pruebas de regresión son conceptos que la mayoría de la gente no conoce. ¿Cuántos en su lugar de trabajo leen realmente un libro sobre pruebas unitarias?

Lo único por lo que podemos culpar a la administración es que las especificaciones de requisitos rara vez contienen requisitos sobre el nivel de calidad del producto entregado.

La próxima vez que su jefe le pida que haga una estimación de tiempo, incluya el tiempo para escribir una prueba de unidad y vea qué sucede.

La mayoría de las pruebas no prueban nada.
Escribe una función fileopen () y un unittest que falla si el archivo no existe y tiene éxito si el archivo existe. ¡Excelente! ¿Ahora comprobaste si funciona con el nombre de archivo en chino BIG5? en un recurso compartido de NFS? en Vista con el archivo en una llave USB y UAC encendido?

El problema es que las pruebas unitarias las escribe el mismo programador que escribió la función, con el mismo conjunto de supuestos y con el mismo nivel de habilidad. Para que realmente funcionen, las pruebas deben ser escritas por otra persona, solo con las especificaciones publicadas sin que ellos vean el código. - ¡En la mayoría de las empresas, obtener especificaciones escritas sería un gran avance!

Las pruebas unitarias verifican errores en el código de funciones individuales. Pueden trabajar para capas de acceso a datos, bibliotecas matemáticas, etc., donde las entradas / salidas son bien conocidas y la estructura interna es compleja, pero en muchos casos son solo una pérdida de tiempo.
Fallan cuando los errores se deben a interacciones entre diferentes partes del código o con el sistema operativo y el usuario. Problemas como configuraciones de PPP alto / bajo que estropean un cuadro de diálogo o una configuración de idioma extranjero al cambiar un '.' y ',' no suelen encontrarse.

Se han realizado estudios sobre el ROI de las pruebas unitarias; consulte esta pregunta .

Encontré muchos desarrolladores que no están interesados ​​en las pruebas unitarias. Siempre parece mucho trabajo con poca recompensa cuando empiezas. Nadie quiere apuntarse a un trabajo extra y por eso se resisten. Una vez que las personas comienzan, por lo general se mantienen con entusiasmo, pero comenzar puede ser difícil.

Aparte del problema de la adopción de las pruebas unitarias, las pruebas unitarias no siempre valen la pena, aunque en general creo que lo es, cuando se aplican correctamente. No hay nada especial en las pruebas unitarias que las salve de ser vulnerables a una construcción deficiente.

Las pruebas unitarias tienen costos (creación, mantenimiento y ejecución) y solo valen la pena si brindan mayores beneficios que esos costos. La creación de pruebas es una habilidad como cualquier otra, requiere experiencia y conocimientos específicos para tener éxito. Sin la experiencia suficiente, es muy fácil, incluso para los desarrolladores con experiencia, crear pruebas unitarias de baja calidad, bajo valor y / o alto costo que no valen la pena. Especialmente teniendo en cuenta lo difícil que puede ser juzgar el valor de una prueba unitaria.

Además, las pruebas unitarias son solo una forma de mejorar la calidad del código, pero no es la única. En algunas circunstancias y con algunos equipos, puede que no sea la forma más eficaz de aumentar la calidad del software.

Tenga en cuenta que poner mucho esfuerzo en las pruebas unitarias no es garantía de software de calidad. Y, también, es posible producir software de la más alta calidad sin ninguna prueba unitaria.

Bueno, mi empresa no ha optado por TDD o Unit Testing. Para ser honesto, no estamos seguros de cómo hacerlo. Obviamente, podemos hacerlo para funciones estúpidas como CapitalizeString (), etc., pero no sabemos cómo hacerlo para sistemas muy complejos con objetos complicados. Además, la mayoría de las personas entrevistadas no tienen experiencia o tienen experiencia limitada. Parece que Unit Testing es grande entre la multitud SO, pero no particularmente grande en el grupo de trabajo disponible.

TDD es un tema aparte. Nos oponemos moralmente a TDD. No somos programadores vaqueros, pero creemos que atrofia la creatividad y la flexibilidad en un proyecto. Además, tener al codificador que escribió la función de prueba unitaria no tiene sentido. Cuando hago algo, codifico todos los casos extremos que se me ocurren. Lo que necesito es otro cerebro para buscar cosas que podría haber pasado por alto. No tenemos eso. Los equipos son pequeños y autónomos.

En resumen, no creemos en TDD, pero nos gustaría hacer pruebas unitarias. Simplemente no tenemos la experiencia para hacerlo y no podemos encontrarlo fácilmente.

Hay muchas empresas que realmente no hacen nada de acuerdo con las mejores prácticas. Sin revisiones de código, sin pruebas unitarias, sin planes de prueba, sin nada, solo en el asiento de sus pantalones.

¡Aproveche esto como una oportunidad para que usen una plataforma de Integración Continua y desarrollen pruebas unitarias! Una manera fácil de impresionar a los poderes fácticos y aumentar la calidad y estabilidad de su código al mismo tiempo

Editar: En cuanto a la razón, creo que simplemente no están al tanto de las herramientas actuales que hacen que la IC y las pruebas unitarias sean extraordinariamente fáciles.

No creo que la pereza sea la causa principal de las pruebas unitarias incorrectas. Para mi empresa, las limitaciones de tiempo y la actitud de "simplemente hágalo" son los mayores impedimentos para realizar pruebas unitarias. Además, los lugares donde nuestros sistemas fallan tienden a ser más en el nivel de integración (servicios, accesos a bases de datos, consultas complejas que requieren datos específicos para las pruebas), no en el "nivel de unidad". Estas cosas son más difíciles de probar, y si apenas tiene tiempo suficiente para realizar la función, probablemente no tendrá tiempo para realizar pruebas útiles al mismo tiempo.

Las pruebas unitarias deberían ser solo una parte natural del flujo de trabajo de desarrollo de código, al igual que el compilador.

Sin embargo, esto requiere educar a la gerencia sobre los beneficios de las pruebas unitarias. Sin embargo, los desarrolladores junior tienen posibilidades relativamente bajas de tener tal influencia. Por lo tanto, si una empresa propone las pruebas unitarias depende de si tiene un desarrollador o arquitecto senior que defienda las pruebas unitarias.

Creo que esta es la respuesta a su pregunta "qué falta y por qué no hay más empresas que realicen pruebas unitarias" . :-)

Probablemente sea una combinación de un par de cosas que ya mencionaste. Es difícil medir los ahorros de costos de TDD. Si desea subcontratar su TI, puede mostrar cuánto paga por año por las personas que tiene en el personal frente al costo de contratarlo; es muy concreto. ¿Cómo se dice: "Oh, esta prueba detectó un error que me habría llevado 4 horas depurar y corregir ..."?

La razón por la que algunos lugares no lo usan es simplemente porque se necesita mucho trabajo tanto para comenzar como para continuar. El hecho de que escribir pruebas unitarias lleve tanto tiempo como escribir la funcionalidad real les parece a algunos gerentes como si estuviera reduciendo la productividad de su desarrollador a la mitad.

Además de eso, construyes un equipo (o alguien) necesita poner la infraestructura en su lugar y mantenerla.

Y como dice Alan , muchos lugares simplemente no utilizan las mejores prácticas, solo quieren ver algo tangible.

Por lo que he visto, muchas empresas tienen bases de código enormes y altamente acopladas que no son prácticamente probables por unidades. Tampoco tienen requisitos comprobables decentes, por lo que las pruebas unitarias se compararían con los requisitos de facto "tal como se construyeron".

Creo que el programador tiene que empezar a hacerlo. Algunas pruebas sencillas para empezar son fáciles de justificar como parte del desarrollo.

Algo como una prueba unitaria es casi siempre necesario para obtener una depuración rápida. Simplemente explique cuánto más rápido es iniciar la prueba que organizar la entrada correcta, establecer un punto de interrupción del depurador, iniciar la aplicación, etc.

Documente la prueba en su código. Simplemente escriba un comentario que explique dónde está la prueba y cómo ejecutarla. Los futuros programadores lo verán y esperamos que las pruebas se extiendan.

La prueba unitaria es uno de esos términos de caja negra que la mayoría de la gente ha escuchado, pero no sabe qué constituye exactamente una prueba unitaria, por dónde empezar, cómo escribirlos, cómo ejecutar realmente las pruebas, qué es exactamente lo que deberían probar, etc. . etcétera etcétera.

En muchos casos, es más fácil para el desarrollador inseguro simplemente descartarlos como innecesarios o como algo que solo los "desarrolladores de nivel empresarial" necesitan.

Soy un gran admirador de las pruebas unitarias y también soy socio de una empresa que realiza proyectos de desarrollo de contratos para varios tipos de clientes. En un mes, tocaremos 3-4 proyectos diferentes de diferentes tamaños.

Si un proyecto parece que va a ser único, no voy a invertir mucho en pruebas unitarias porque esas pruebas unitarias no dan resultado para mi negocio. En ese tipo de proyectos, voy a realizar pruebas unitarias con cosas con las que no estoy seguro / no estoy familiarizado o que podrían cambiar con frecuencia (como un analizador para una fuente de datos que no controlo).

Mientras que si estoy construyendo algo que sé que va a tener una larga vida útil, es un trabajo más grande, con el que trabajaré a través de múltiples iteraciones, o tendrá un gran impacto en mis clientes si ocurre un error. , Voy a invertir en más pruebas unitarias. Una vez más, la prioridad de las pruebas gira en torno al código incierto / desconocido / cambiante.

Creo que las pruebas unitarias deberían girar en torno a la complejidad de una tarea, así como a si van a dar sus frutos. No tiene sentido escribir código adicional que no se vaya a utilizar.

En mi experiencia, realmente depende del software que esté escribiendo. Descubrí que es extremadamente difícil escribir pruebas unitarias para una interfaz de usuario. Solo uso pruebas unitarias para partes del sistema que tienen una entrada / salida definida.

Extraño las pruebas unitarias, simplemente hace la vida más fácil.

En realidad, esa no es una razón suficiente para que una empresa adopte las pruebas unitarias.

Una razón suficiente podría ser "más barata" (y / o "mejor"): lo cual no es tan fácil de demostrar sobre las pruebas unitarias.

La única buena razón podría ser "escribir pruebas unitarias es el mejor uso del tiempo de los desarrolladores", lo cual es realmente difícil de probar en mi opinión: y puede ser cierto en algunos lugares, para algún software, con algunos desarrolladores, y no en otros.

Hay muchos desarrolladores que no piensan en el mundo de las pruebas unitarias: incluidos algunos que piensan que otras formas de pruebas (por ejemplo, integración automatizada / pruebas funcionales) pueden ser más baratas y valiosas, por ejemplo, ¿Soy el único desarrollador que no? ¿Te gustan las pruebas unitarias?

Por supuesto, en el mundo ideal, no se puede argumentar en contra de tener una prueba unitaria.

Sin embargo, si escribe una prueba unitaria depende de varias cosas:

• Cómo se utilizará el software. Si estuviera escribiendo software solo para usted, ¿escribiría pruebas unitarias? Probablemente no. Si estuviera escribiendo software preempaquetado para venderlo comercialmente, probablemente sí.

• Cuántas personas mantienen el código ... si solo eres tú, entonces es posible que lo conozcas lo suficientemente bien como para estar lo suficientemente seguro después de hacer un cambio de que una ejecución rápida del código es suficiente para garantizar que nada se haya roto. Si otras personas que no escribieron originalmente el código ahora deben mantenerlo, entonces una prueba unitaria les dará la confianza de que cuando actualicen el código para arreglar un problema grande (¡que obviamente no fue capturado en la prueba unitaria!) No han roto nada. .

• complejidad del código: solo código de prueba que necesita una prueba. Un método de asignación de variable de una línea no necesita pruebas. Un método de 50 líneas con múltiples rutas de ejecución probablemente lo haga.

• Consideraciones comerciales comerciales prácticas: el hecho es que escribir pruebas unitarias lleva más tiempo que no hacerlo. Si está escribiendo un software prototipo, que tiene un futuro comercial incierto, entonces hay una recompensa entre tener un código rápido, ahora, que funciona suficientemente bien, versus tener un código probado por unidad en 2 semanas que funciona mejor. A veces vale la pena averiguar rápidamente (apetito del consumidor) si el software tendrá un estante corto como y pasar al siguiente proyecto.

y como otros han señalado, una prueba es tan buena como la persona que la escribió.

La razón principal es que muchos desarrolladores y gerentes de desarrollo no tienen ni idea de que existen pruebas unitarias o de cómo usarlas.

La segunda razón es que las pruebas unitarias solo se pueden usar (de manera sensata) con código que ya cumple con algunos estándares de calidad. Lo más probable es que algún código base existente no pertenezca a esa categoría.

La tercera razón es la pereza y / o la baratura.

Porque las pruebas unitarias solo son útiles si escribe código comprobable. Y escribir código comprobable es difícil. Y la gente es perezosa y / o tacaña.

EDITAR: matizado "vago" como "vago y / o barato"; En ocasiones excepcionales, las personas tienen la habilidad, la capacidad y la voluntad de redactar pruebas, pero tienen algo más que hacer que afecta más directamente a los resultados.

Creo que parte del problema es que los desarrolladores esperan que los empresarios tengan el mismo conjunto de valores y que realmente se preocupen por la respuesta a "¿deberíamos hacer una prueba unitaria o no?". No obtenemos la aprobación de antemano de la empresa para usar un lenguaje de alto nivel en lugar del lenguaje ensamblador; por lo general, es la forma más sensata de hacer el trabajo.

El punto es que somos los únicos calificados para hacer la llamada (lo que no quiere decir que todos tengamos el mismo conocimiento sobre el tema). Además, incluso si su equipo no hace, como política, pruebas unitarias (o nombra-su-método-del-día), por lo general no significa que usted no pueda hacerlo.

La verdad es que realmente no podemos demostrar el ROI en la mayoría de las cosas que hacemos con una granularidad demasiado fina. Por qué las pruebas unitarias se someten a este estándar de prueba irrazonable / atípico está más allá de mí ...

La gente es perezosa y solo adopta el cambio cuando se ve obligada a hacerlo.

Mis 2 centavos:

• Requiere algo de educación y disciplina, pero los nuevos graduados ya vienen con los conocimientos adecuados.
• Los gastos generales de las pruebas se pueden reducir con mejores herramientas y esto también está sucediendo (refactorización, etc.)

Entonces, es solo cuestión de tiempo.

Está el debate Martin-Coplien en el que Bob Martin afirma que:

"Hoy en día es irresponsable que un desarrollador envíe una línea de código que no ha ejecutado en una prueba unitaria".

[ http://www.infoq.com/interviews/coplien-martin-tdd]

Si desea vender a todos en las pruebas, haga lo siguiente:

1. Escribe un montón de pruebas.
2. Notifique a los otros desarrolladores que cambian el código y fallan en sus pruebas.
3. Ellos arreglarán su código.
4. Ahora puede lanzar sin esos errores particulares.

Incluso un gerente podría entender esto.

Las empresas no están realizando pruebas unitarias por la misma razón por la que muchos sitios web están mal escritos: ignorancia y gente que se apega a los viejos hábitos. En mi empresa, desde que comenzamos las pruebas unitarias (con Nunit y Typemock ), alcanzamos una mayor cobertura de código y lanzamos el software en un tiempo más corto de comercialización.

Como la mayoría de las buenas ideas, la adopción tiene más que ver con la dependencia de la ruta organizativa que con la calidad de la idea.

En la mayoría de las empresas que han enviado productos, se ha creado una importante división de control de calidad con un jefe de control de calidad de alto nivel. Las pruebas son el feudo del equipo de control de calidad.

Es poco probable que el equipo de control de calidad escriba un código de prueba unitario porque la empresa normalmente no proporciona al equipo de control de calidad sus codificadores de alta resistencia.

El equipo de programación es reacio a escribir código de prueba porque crea un conflicto con el equipo de QA.

He observado más interés y adopción de las pruebas unitarias en grupos donde el control de calidad no se ha dividido en una función de trabajo separada.

Sencillo: escribir y actualizar pruebas unitarias cuesta dinero. La mayoría de las empresas de software anterior no tienen pruebas unitarias y su escritura costará demasiado. Entonces no lo hacen y agrega tiempo al proceso de desarrollo para que tampoco lo agreguen a nuevas funcionalidades.

La mayoría de las empresas son inútiles. No para el que trabajamos tú (o yo), obviamente.