Cómo de comunes son los test unitarios que se hacen por cubrir código para llegar a X% de cobertura y que no sirven para absolutamente nada?
Yo tengo que hacerlos durante varios días en mi empresa cada sprint y la verdad es que me dan ganas de pegarme un tiro en los cojones, y tenia curiosidad por demás empresas.
Yo supongo que esto es normal solo en consultoras grandes pero ni idea.
Lo que más me jode es que no hagan la planificación teniendo en cuenta estas pruebas que quitan muchísimo tiempo de desarrollo y son un coñazo.
es habitual en cualquier sitio que usen el coverage como métrica y no tengan mucha idea de lo que implica. Para ellos es un trámite coñazo que se ha de hacer para que todos los checks del inspector estén en verde. Esas mismas empresas son las que desactivan el sonarqube cuando les da por culo o permiten eliminar tests que no pasan para poder subir cambios.
Resumiendo: empresa de IT gestionada por gente que no sabe de IT
Para mi aquí entra el deber de un programador. Si quieres código fiable debes hacerlos si o si. Eso si, a veces por tema tiempo/prioridad se pueden saltar, pero hacerlos mal y solo porque toca hacerlos es lo peor: quitan tiempo y el código sigue siendo igual de poco fiable.
Eso si, como el dia de mañana toque hacer un refactor y no esten bien hechos, te vuelve como un boomerang 
#5TitoBurns:Si quieres código fiable debes hacerlos si o si.
Código fiable
Consultora buscando 100% de test coverage
Pick one.
yo entiendo que el debate es si es util que sea solo de coverage sin testear nada, es decir que no tenga un triste assert. En el ecosistema salesforce en apex por ejemplo se da ese caso, te obligan a un 75% de coverage para desplegar pero da lo mismo que no compruebes nada de funcionabilidad.
#3Zh3RoX:pruebas que quitan muchísimo tiempo de desarrollo
Plot twist: el testing es desarrollo. Si no se estima una tarea de desarrollo teniendo en cuenta los tests se está estimando mal.
En cuanto a #1, el 100% de cobertura suele ser una chorrada salvo que trabajes en el código de un rover de la NASA.
Bienvenido al maravilloso mundo del desarrollo de software donde las buenas ideas se cogen y se destruyen por completo aplicándolas de forma abusiva o incorrecta.
Si pasase solo con los tests...
#9 Tienes razón. A mi me pasa continuamente:
"Fulanito tienes que hacer la tarea X en 5 jornadas"
"Ok" procede a mirar la documentación del proyecto y ve que en 5 jornadas puede hacerlo, pero va a ir justo.
Pasan 3 días
Aparte, no sé si a alguien más le pasa en su proyecto, pero no entiendo eso de que haya una persona de la propia empresa encargada de testear lo mismo que testeas tú como desarrollador, exactamente lo mismo, no le encuentro el sentido si a ti como desarrollador te están pidiendo X pruebas y esa persona hace las mismas pruebas que tú, es pagar por hacer el mismo trabajo dos veces.
#11 Un QA no hace ni de coña las mismas pruebas que tú. Pero ni de coñísima, vamos. Tienen unas herramientas para testear casos que a ti ni se te ocurren, entre otras cosas, porque testear tu propio código te sesga mogollón a la hora de buscar fallos. No es hacer dos veces el trabajo ni de lejos.
El problema es que los test deberian ser unitarios y funcionales.
Los test unitarios son una chorrada que rara vez van a fallar en despliegue. Y si lo hacen, ante un problema complejo, la mayoria optara por eliminarlos para poder llegar a plazos. Al final, en un proyecto de larga duracion, los test unitarios solo estan para perder el tiempo, porque tienen tantas excepciones que pueden devolver una mierda con ojos y seria valido porque en el caso de uso 35869453643558 puede darse el caso que venga una mierda con ojos, pero algun servicio posterior puede no aceptar esa mierda con ojos y va a petar aun habiendo pasado los test unitarios.
Para mi, todo test unitario debe ir acompañado de sus correspondientes test funcionales, y su juego de datos. En la linea de lo que dice #9 , el problema es que a un desarrollo de 4 horas, le tienes que sumar 15 minutos de picarte los unitarios, una hora de picarte los funcionales (happy y unhappy path), y otra hora de montar un juego de datos y los correspondientes scripts que generen la informacion para los test, y que borren la informacion (y todo lo generado por el desarrollo) al terminar tus pruebas.
Asi que de un desarrollo, le tienes que sumar un 60% en "desarrollar" las pruebas. Un proyecto de 1 año, se transforma en un proyecto de casi 2 años ... y eso es demasiado cuando realmente el beneficio a lo mejor no llegar a verlo nunca (el proyecto se abandona, o no tiene cambios importantes). Y al final, en ese año, siempre habra alguna urgencia o algun momento critico en el cual alguien dira "desactiva y tira ya lo arreglaremos" ... y ahi se va a quedar.
Y todo esto en proyectos nuevos, obviamente ni de coña vas a ponerte a cascar el plan de pruebas en un proyecto ya desarrollado, q depende de la edad y la tecnologia, algunas cosas funcionan y ni puta idea de porque funcionan.
#11 Existe mucho meme de eso, un buen equipo de QA es esencial, y aun asi puede fallar. Como desarrollador, muchas veces se obvia que el usuario es como un mono con pistolas.
#12 Nono, esta persona no es de QA.
Estoy seguro de que hace las mismas pruebas que yo porque básicamente he hablado en más de una ocasión con esta persona, me ha preguntado cosas y he visto trazas de sus pruebas y son las mismas que las que yo hago, por eso me resulta extraño xD
En QA sé que hacen pruebas mucho más complejas.
#1 hacer test de mierda por hacer es una gilipollez y probablemente implique que no se ha diseñado / está diseñando bien el software.
Todo lo que no te permita hacer inversión de dependencias para poder crear los objetos fuera de la clase y poder mockearlos para hacer test => golpe de remo.
#5 La cosa es que no testeas nada. Si a mí los tests unitarios me parecen de putísima madre, aseguras que funcionalidad sigue funcionando bien cuando introduces nuevos cambios y al final ahorras muchísimo tiempo (si están bien hechos).
Pero para eso tienes que hacer planes de pruebas y hacerlos bien, no solo cubrir líneas de código con test inútiles. Lo único que hace hacer estos test inútiles es que tarde más en compilar, y que tengas que perder el tiempo desarrollando las putas basuras de tests esos y arreglandolos cuando se rompen (porque están hechos fatal)
Por ejemplo en el proyecto en el que estoy ahora que es enorme y muy antiguo, tenemos que hacer una burrada de test de código que no se desarrolló para hacer test unitarios en el, y tienes que hacer chapuzas para alcanzar el 80% de cobertura porque un señor que no sabe nada de programación dice que lo hagas
#17 meter tests en un código que no es SOLID y/o no esté preparado para recibir tests es una gilipollez, qué haces, esto para el coverage?
public function amazing_useless_test()
{
$this->assertTrue(true);
}
#18 Nooo, tienes que crear objetos con 29288484 parámetros metidos para testear el método con sus doscientas causísticas, mockear mil clases que necesitas para que no explote el método cuando lo invocas.
Y luego extraer el código inalcanzable en los test a métodos privados porque no se puede testear debido a la arquitectura de la aplicación para poder cubrir esas líneas (lo cual es genial porque cuando alguien cambia el nombre de un método privado o lo cambia por lo que sea ya explotan los test)
Yo hago los tests y luego el código que pasa esos tests. El sonar no me ha echado una pr pa atrás por falta de coverage nunca.
En mi proyecto usamos arquitectura hexagonal por lo que a lo sumo tengo que mockear 2-3 objetos como mucho.
El coverage empieza a bajar cuando tienes código que solo funciona en producción, por que el SDK no es una interfaz sino métodos estáticos o clases de mierda.
Pero vamos que los tests unitarios están bastante bien en general, son fáciles de hacer y te aseguran que tú mierda hace la mierda en condiciones.
Diseño de mierda... 