unit-testing - tipos - pruebas unitarias php
Si las pruebas unitarias son tan buenas, ¿por qué no lo hacen más compañías? (30)
La primera compañía de software real en la que trabajé tenía que ver con la prueba unitaria (NUnit). No sé si éramos realmente reacios a eso en aquel 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 encontré con algunas compañías que hacen muchas pruebas, pero es una prueba de sillas: depende de que haya una persona allí, tiene poca repetibilidad y pocas posibilidades de atrapar insectos. La otra actitud es: era algo que querían poner en práctica con "en el futuro"; Básicamente cuando el dinero cae del cielo.
Extraño las pruebas unitarias, solo hace la vida más fácil. Pero me doy cuenta de que cuando busco un nuevo trabajo, las pruebas unitarias son algo que a las empresas les gustaría "poner en práctica" en el futuro o algo que no hacen en absoluto (uhh, ha existido por un tiempo). ¡ahora!). Diría que el 60-75% de los requisitos de trabajo que he analizado en los últimos 2 años no han incluido ninguna prueba de unidades. Solo puedo pensar en uno o dos que tenían experiencia en pruebas unitarias como requisito (para un puesto de desarrollador de nivel medio).
Entonces la pregunta es, ¿qué falta ? Creo que hace que las personas sean más productivas, pero eso es solo después de pasar una gran cantidad de tiempo realmente haciéndolo. ¿No hay buenos estudios sobre el ahorro de costos de las pruebas unitarias? ¿Es el tipo de compañía que estoy buscando?
Editar: a pesar de que el título es un poco diabless-advocate, me considero un proponente de pruebas unitarias.
Extraño las pruebas unitarias, solo hace la vida más fácil.
Eso no es, en realidad, una razón suficiente para que una empresa adopte pruebas unitarias.
Una razón suficiente podría ser "más barata" (y / o "mejor"): lo cual no es tan fácil de probar acerca de las pruebas unitarias.
La única buena razón podría ser "escribir pruebas unitarias es el mejor uso del tiempo de los desarrolladores", que es realmente difícil de demostrar OMI: y puede ser cierto en algunos lugares, para algunos programas, con algunos desarrolladores, y no es cierto en otros lugares.
Hay muchos desarrolladores que no piensan en el mundo de las pruebas unitarias: incluidos algunos que piensan que otras formas de prueba (por ejemplo, pruebas integradas / funcionales) pueden ser más baratas y valiosas, por ejemplo, ¿soy el único desarrollador que no lo hace? ¿Te gustan las pruebas unitarias?
1) Es difícil
2) Lleva 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 se determina cuántos errores no existen debido a las pruebas de su unidad? No puedes medir lo que no existe. Puede señalar estudios, pero no encajan bien en la hoja de cálculo de su gerente de negocios.
Aparte del tema de la adopción de pruebas unitarias, las pruebas unitarias no siempre son útiles, aunque, en general, creo que sí, cuando se aplican correctamente. No hay nada especial acerca de las pruebas unitarias que les evite ser vulnerables a una construcción deficiente.
Las pruebas unitarias tienen costos (creación, mantenimiento y ejecución) y solo valen la pena si proporcionan mayores beneficios que esos costos. La creación de pruebas es una habilidad como cualquier otra, requiere experiencia específica y conocimiento para el éxito. Sin suficiente experiencia es muy fácil para los desarrolladores experimentados crear evaluaciones de unidades de baja calidad, bajo valor y / o alto costo que no valen la pena. Sobre todo 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 efectiva 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 de unidad alguna.
Bueno, mi compañía no se ha ido con 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 una experiencia limitada. Parece que Unit Testing es grande del grupo SO, pero no particularmente grande en el grupo de trabajo disponible.
TDD es un tema separado. Estamos moralmente opuestos a TDD. No somos codificadores de vaqueros, pero sí creemos que impide la creatividad y la flexibilidad en un proyecto. Además, tener el codificador que escribió la función de prueba de la unidad no tiene sentido. Cuando hago algo, codigo todos los casos extremos en los que puedo pensar. Lo que necesito es otro cerebro para buscar cosas que podría haber perdido. No tenemos eso. Los equipos son pequeños y autónomos.
En resumen, no creemos en TDD, pero nos gustaría probar la unidad. Simplemente no tenemos la experiencia para hacerlo, y no podemos encontrarlo fácilmente.
Como la mayoría de las buenas ideas, la adopción tiene más que ver con la dependencia de la ruta organizacional que con la calidad de la idea.
En la mayoría de las compañías que han enviado productos, se ha creado una división sustancial de control de calidad con un jefe de GC de alto nivel. Las pruebas son el feudo del equipo de QA.
Es improbable que el equipo de QA escriba el código de prueba de la unidad porque la compañía generalmente no cuenta con personal para el equipo de QA con sus codificadores de trabajo pesado.
El equipo de programación es reacio a escribir código de prueba porque crea un conflicto con el equipo de control de calidad.
He estado viendo más interés y adopción de pruebas unitarias en grupos donde el control de calidad no se ha dividido en una función de trabajo separada
Creo que el programador tiene que comenzar a hacerlo. Algunas pruebas simples para comenzar son fáciles de justificar como parte del desarrollo.
Algo así como una prueba unitaria es casi siempre necesaria para obtener una depuración rápida. Simplemente explique cuánto más rápido es iniciar la prueba de lo que es organizar la entrada correcta, establecer un punto de interrupción del depurador, iniciar la aplicación, etc.
Documenta la prueba en tu código. Simplemente haga un comentario explicando dónde está la prueba y cómo ejecutarla. ¡Los futuros programadores lo verán y con suerte las pruebas se extenderán!
Creo que parte del problema es que los desarrolladores esperan que las personas de negocios tengan el mismo conjunto de valores y que realmente se preocupen por la respuesta a "¿deberíamos probar la unidad o no?". No obtenemos aprobación previa del negocio para usar un lenguaje de alto nivel en lugar de un lenguaje ensamblador; por lo general, es la forma más inteligente 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 realiza, como cuestión de política, pruebas unitarias (o nombre-su-método-del-día) generalmente no significa que no pueda hacerlo.
La verdad es que no podemos demostrar el ROI en la mayoría de las cosas que hacemos en una granularidad demasiado fina. La razón por la cual las pruebas unitarias se llevan a cabo con este estándar de prueba irracional / no típico me supera ...
Dos cosas son obstáculos para las pruebas unitarias
- Todo lo nuevo es difícil de hacer
- Todo lo que no tiene un beneficio mensurable, es malo.
- Los humanos son flojos. Desarrolladores, de hecho.
En mi empresa (> 5.000 emp) pruebas de unidad "están ahí", pero no hay posibilidad de hacer TDD u obtener una gran cobertura de código. Es difícil de lograrlo.
En mi experiencia, hay un par de factores involucrados en esto:
- La gerencia realmente no entiende qué es realmente la prueba unitaria, o por qué tiene un valor intrínseco real para ellos.
- La administración tiende a preocuparse más por la entrega rápida de productos y (incorrectamente) considera que las pruebas unitarias son contraproducentes para ese objetivo.
- Existe una percepción errónea de que las pruebas pertenecen únicamente a la pervivencia de la garantía de calidad. Los desarrolladores son codificadores y no pueden escribir pruebas.
- Existe una percepción errónea común de que la administración tendrá que gastar dinero para hacer las pruebas unitarias correctamente, a pesar del hecho de que las herramientas están disponibles gratuitamente. (Por supuesto, hay que considerar el tiempo de desarrollo del desarrollador, pero en realidad no es prohibitivo).
- La respuesta de Will redondeará esta respuesta: es muy difícil determinar el valor del código de prueba (edite jcollum)
Naturalmente, hay otros factores, pero esos son solo los que me he encontrado hasta ahora.
En mi experiencia, realmente depende del software que estás escribiendo. Descubrí que es extremadamente difícil escribir pruebas unitarias para una IU. Solo uso pruebas unitarias para partes del sistema que tienen una entrada / salida definida.
Es fácil echarle toda la culpa a la "administración". Pero, ¿la dirección realmente le está diciendo que específicamente no haga ninguna prueba unitaria?
La gerencia 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 de unidades. Estas son herramientas de comercio que aplica un ingeniero de software competente y exitoso, pero un ingeniero deficiente no.
Creo que la verdadera respuesta a su pregunta es: las pruebas unitarias son realmente difíciles, y los estudiantes de ciencias de la computación no están capacitados para ello.
Es fácil cuando estás escribiendo tu propia clase de cuerda. Cuando prueba 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 manera automática, que no se descompone si mueve un botón?
- Interacción con API y marcos externos. Si está escribiendo un controlador de núcleo de Windows, ¿cómo lo prueba unitario? ¿Escribes stubs para cada IRP y función kernel que utilizas, creando efectivamente una simulación del kernel OS?
- Las comunicaciones de 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? Comúnmente veo personas que intentan el enfoque "hacer cosas aleatorias en un ciclo de 1000 iteraciones y ver si se rompe". Cuando haces esto, el esfuerzo es más alto que el rendimiento, se pierden errores importantes y se abandonan las pruebas unitarias.
- ¿Cómo se prueba que se cumplen los requisitos de rendimiento?
- El conocimiento de los patrones en las pruebas es escaso: los stubs, las respuestas enlatadas, las pruebas de regresión son conceptos que la mayoría de las personas desconoce. ¿Cuántos en su lugar de trabajo realmente leen un libro sobre pruebas unitarias?
Lo único que podemos culpar a la administración es que las especificaciones de los requisitos rara vez contienen requisitos sobre el nivel de calidad del entregable.
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.
Es probablemente una combinación de un par de cosas que ya has mencionado. Es difícil medir el ahorro de costes de TDD. Si desea externalizar su TI, puede mostrar cuánto paga por año a los empleados 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 ..."?
Hay muchas compañías que realmente no hacen nada según las mejores prácticas. Sin revisiones de código, sin pruebas de unidades, sin planes de prueba, sin nada, solo por el asiento de sus pantalones.
¡Aproveche esto como una oportunidad para que utilicen una plataforma de integración continua y desarrollen pruebas unitarias! Una forma sencilla de impresionar a los poderes fácticos y aumentar la calidad y la 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 las pruebas de CI y de unidades sean extraordinariamente fáciles.
He encontrado muchos desarrolladores que no están interesados en las pruebas unitarias. Siempre parece mucho trabajo con poco beneficio cuando comienzas. Nadie quiere inscribirse para un trabajo extra y por eso se resisten. Una vez que las personas comienzan, generalmente se quedan con entusiasmo, pero comenzarlas puede ser difícil.
La mayoría de las compañías son inútiles. No es el que usted (o yo) trabaja, obviamente.
La mayoría de las pruebas no prueban nada.
Usted escribe una función fileopen () y una prueba de unidad que falla si el archivo no existe y tiene éxito si el archivo existe. ¡Estupendo! ¿Comprobaste si funciona con el nombre de archivo en BIG5 chino? en un recurso compartido NFS? en vista con el archivo en una llave USB y el UAC encendido?
El problema es que las pruebas unitarias son escritas por el mismo programador que escribió la función, con el mismo conjunto de suposiciones y con el mismo nivel de habilidad. Para realmente trabajar, las pruebas deben ser escritas por otra persona, solo para las especificaciones publicadas sin que ellas vean el código. - ¡En la mayoría de las empresas, solo obtener las especificaciones escritas sería un gran avance!
Las pruebas unitarias verifican los errores en el código de funciones individuales. Pueden funcionar para capas de acceso a datos, bibliotecas de matemáticas, etc. donde las entradas / salidas son bien conocidas y la estructura interna es compleja, pero en muchos casos son simplemente 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 la configuración de DPI alto / bajo arruinando un cuadro de diálogo o una configuración de idioma extranjero intercambiando un ''.'' y '','' generalmente no se encuentran.
La razón por la que algunos lugares no lo usan es simplemente porque requiere mucho trabajo tanto para comenzar como para continuar. El hecho de que las pruebas de unidad de escritura ocupen tanto tiempo como la escritura de la funcionalidad real parece que para algunos gerentes es como si estuviera reduciendo la productividad de su desarrollador a la mitad.
Además de eso, el equipo de construcción (o alguien) necesita poner la infraestructura en su lugar y mantenerla.
Y como dice Alan , muchos lugares simplemente no usan las mejores prácticas, solo quieren ver algo tangible.
La razón principal es que muchos desarrolladores y administradores de desarrollo no tienen idea de que existen pruebas unitarias o cómo usarlas.
La segunda razón es que las pruebas unitarias solo se pueden usar (de manera sensata) con un código que ya cumpla con algunos estándares de calidad. Es probable que alguna base de código existente no entre en esa categoría.
La tercera razón es la pereza y / o la baratura.
Las empresas no realizan pruebas unitarias, por la misma razón que muchos sitios web están mal escritos: ignorancia y personas que se apegan a los viejos hábitos. En mi empresa, desde que empezamos las pruebas unitarias (con Nunit y Typemock ), alcanzamos una mayor cobertura de código y lanzamos el software en menos tiempo al mercado.
Las personas son flojas y solo adoptan cambios cuando se les obliga a hacerlo.
Las pruebas unitarias deben ser solo una parte natural del flujo de trabajo de desarrollo de código, tal como lo es el compilador.
Sin embargo, esto requiere educar a la administración sobre los beneficios de las pruebas unitarias. Sin embargo, los desarrolladores junior tienen relativamente pocas posibilidades de tener tal influencia. Por lo tanto, si una empresa es un proponente de las pruebas unitarias depende de si tienen un desarrollador principal o arquitecto que defiende las pruebas unitarias.
Creo que esta es la respuesta a su pregunta "qué es lo que falta y por qué no hay más empresas haciendo pruebas unitarias" . :-)
Las pruebas unitarias son uno de esos términos de recuadro negro que la mayoría de la gente ha escuchado, pero no saben exactamente qué constituye una prueba unitaria, por dónde empezar, cómo escribirlos, cómo ejecutar realmente las pruebas, exactamente qué 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.
Mis 2 centavos:
- Requiere un poco de educación y disciplina, pero los nuevos graduados ya cuentan con el conocimiento adecuado.
- La sobrecarga de las pruebas se puede reducir con mejores herramientas y esto también está sucediendo (refactorización, etc.)
Entonces, es solo una 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".
No creo que la pereza sea la causa de las malas pruebas unitarias. Para mi empresa, las limitaciones de tiempo y la actitud de "solo hazlo" son los mayores impedimentos para hacer 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 pruebas), no 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.
Por lo que he visto, muchas compañías tienen bases de códigos enormes y altamente acopladas que no son prácticamente comprobables por unidad. Tampoco tienen requisitos comprobables decentes, por lo que las pruebas unitarias probarían contra los requisitos de facto "tal como están construidos".
Por supuesto, en el mundo ideal, no puede argumentar en contra de tener una prueba unitaria.
Sin embargo, si escribe una prueba unitaria depende de varias cosas:
Cómo se usará el software. Si estuvieras escribiendo software solo para ti, ¿escribirías pruebas unitarias? Probablemente no. Si estaba escribiendo software preempaquetado para venderlo comercialmente, probablemente sí.
Cuántas personas mantienen el código ... si es solo usted, entonces puede que lo sepa lo suficientemente bien como para ser lo suficientemente seguro después de hacer un cambio que un recorrido rápido del código es suficiente para asegurar que nada se ha roto. Si otras personas que originalmente no escribieron el código deben ahora mantenerlo, entonces una prueba unitaria les ayudará a confiar en 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 prueba. Un método de 50 líneas con múltiples rutas de ejecución probablemente sí lo haga.
Consideraciones comerciales comerciales prácticas: El hecho es que las pruebas de unidades de escritura toman más tiempo que no hacerlo. Si está escribiendo un prototipo de software, que tiene un futuro comercial incierto, entonces hay una recompensa entre tener un código rápido, ahora, que funcione suficientemente bien versus tener un código probado en 2 semanas que funcione mejor. A veces vale la pena averiguar rápidamente (apetito del consumidor) si el software tendrá un estante corto y pasar al siguiente proyecto.
y como otros han señalado, una prueba es tan buena como la persona que la escribió.
Se han realizado estudios sobre el ROI de las pruebas unitarias: vea esta pregunta .
Simple, cuesta dinero escribir y actualizar pruebas unitarias. La mayoría del software anterior de las compañías no tiene pruebas unitarias y costará demasiado escribir. Por lo tanto, no lo hacen y agrega tiempo al proceso de desarrollo, por lo que tampoco lo agregan a las nuevas funciones.
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 uno, no voy a invertir mucho en pruebas unitarias porque las pruebas unitarias no dan resultado en mi negocio. En esos tipos de proyectos voy a probar cosas con las que no estoy seguro / estoy familiarizado o que pueden 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 una tarea más grande, con la 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. De nuevo, la prioridad de las pruebas gira en torno al código incierto / desconocido / cambiante.
Creo que las pruebas unitarias deben girar en torno a la complejidad de una tarea, así como también si van a dar frutos. No tiene sentido escribir un código adicional que no vaya a usarse.
Si quiere vender a todos en las pruebas, haga lo siguiente:
- Escribe un montón de pruebas.
- Notifique a los otros desarrolladores que cambian el código y fallan su (s) prueba (s).
- Arreglarán su código.
- Ahora puedes lanzar sin esos errores en particular.
Incluso un gerente podría entender esto.