Herramientas para test en unity

Inicio Foros Desarrollador Desarrollo Herramientas para test en unity

Herramientas para test en unity

Jonay
Participante
#13310
  • Buenas yo estoy aprendiendo TDD(Test develoment develoment), es decir, uso test como base para programar y me pico la curiosidad sobre si existen herramientas para testear en unity.He visto que existe una intregracion de unity con las librerias de unit y me imagino que las librerias de c# para test doubles deberian funcionar aunque sea en el ide.

    ¿Conoceís otras herramientas para testear?

    P.S.:Si queréis poner herramientas de depuración no me parece mal.Pero para mi lo más interesante serian herramientas de testeo.

    0

Etiquetado: 

  • #13336

    Nosotros no hemos abrazado el TDD ni terminamos de verlo nada claro. Tal vez porque no hemos pasado por un buen taller donde lo expliquen decentemente, porque libros sí nos hemos empapado del tema y ni así. A mi tener que hacer un test para ver si 2+2 suma 4 (en el clásico ejemplo de la calculadora) me parece una pérdida de tiempo. Sospecho que el ejemplo es simplemente poco adecuado. Entiendo la idea base (testea la interfaz, no la implementación, ¿no?) pero no termino de verlo útil en lo que hacemos. Probablemente por ignorancia :'(

    Hace poco leí un artículo sobre el tema en relación al desarrollo de juegos, (Why video game coders don’t use TDD and why it matters), échale un vistazo y me dices 😀

    En cualquier caso Unity parece que tiene esto: https://unity3d.com/learn/tutorials/topics/production/unity-test-tools

    Diseño y desarrollo de juegos en PlayMedusa

    0
    #13533

    Gracias por el enlace, le he hechado un vistazo por encima a la herramienta y me parece potente. La pongo en mi lista de cosas que tengo que mirarme cuando vuelva a atacar a unity.

    Yo en parte, un un apasionado del TDD llevo unos 3 meses dedicandole tiempo a aprenderlo por lo conozco los conceptos y los he practicado pero me falta experiencia real. Lo quiero decir es que estoy predispuesto a hablar en favor de él, y que seguramente mi opinion no sea tan objectiva como debería. De todas maneras intentaré hablar intentando evitar opiniones personales.

    No me considero programador de videojuegos aunque algo sé algo de unity.Por eso eso sobre el TDD en videojuegos hablaré de manera muy general diré que es un métodologia agil que se usan más o menos en las mismas condiciones que scrumm y al igual que este cuanto más caotico es el proyecto en que trabajas más te aporta.Pero en lo videojuegos creo que también se toca cascada al fin del al cabo se hace un GDD al principio del desarrollo.Sin embargo, si usaís scrumm os recomendaria que pensaráis en la posibilidad de aprender TDD.


    Me lei el articulo
    me parecio bueno, en algunas cosas estoy de acuerdo con él pero no estoy de acuerdo con sus conclusiones.
    En su resumen sintetiza dos razones con las que no estoy de acuerdo.
    Su primera razón es comparar el TDD con herramientas de depuración que en parte lo es, pero sobretodo se trata de un metodologia que aporta más que solo unos test, te ayuda a diseñar.Por lo que está razón me parece un poco cogida con pinzas .Pero como te dije no soy desarrollador de videojuegos.
    La segunda es simplemente que si no sabes usarlo no lo uses, tiene razón pero esa norma se puede aplicar a cualquier cosa.
    Bien es cierto, que muchos de lo que usamos TDD culpamos al tiempo que se necesita para formarse el hecho otras metodologias agiles
    hayan tenido más existo que TDD.Te pongo un ejemplo, fui a un curso de TDD estaba rodeado de profesionales con años de experiencia y
    todos se equivocaron el mismo ejercicio de iqual manera, la razón tuvimos un error de concepto muy común a la hora de formular los test.
    El TDD no es dificil en sí, pero lleva tiempo aprender a dominarlo.

    Contestando a tu duda
    la interfaz en sí, casi nunca se testea.Porque el punto de la aplicación donde más cambios hay y los test serian costosos de mantener pues a cada cambio en la estructura de por ejemplo un menu saltarian errores.Los test se centra en gran parte en testear los requisitos de la aplicación obviando un poco de que como se pinten estos requisitos en la pantalla.Es decir, sobre todo sea hacen test en la logica de negocio o en la implementación.
    Lo que si se hace es hacer un test de integración para asegurar que las conexiones con la base de datos y con la vista funciona correctamente
    aunque sea más algo más caro de mantener.

    Ya desarrollaré esto más en profundidad más abajo pero en el ejemplo que pusiste una vez que tienes la maña de test de no tardas 5 minutos
    en hacer un test de ese tipo. Quizás sea un mal ejemplo pero ahora te lo comparo con refactorizar las primeras veces que lo haces se
    siente pesado pero cuando tienes la practica y sabes usar tu ide, refactorizar se siente gratis no es algo tan extremo pero si hay una mejora
    cuando coges destreza.

    Hay un grupo en tenerife donde a veces hacen eventos de TDD seguro que ellos pueden contestar a tus dudas mejor que yo.
    http://www.meetup.com/es-ES/Agile-Canarias/

    El TDD de manera general.(Disculpad por la biblia aqui me alargo hablando de algunos conceptos de TDD)

    Primero de todo los que hacemos TDD lo usamos como una herramienta de diseño de arquitectura.Ya entraré más adelante a hablar de como utilizar tdd para diseñar pero es un error muy común verlo como herramientas de testeo.Aunque solo sea para que lo veas un poco desde mi perpectiva me gustaria que en futuro cuando escuches algo de TDD te tomes unos minutos en pensar en el como una herramienta de diseño de arquitecturas y te olvides por un momento de los test.

    ¿Los test perdida de tiempo?
    Ya llegamos a lo importante.Si simplemente usas test, es probable que si fueran una perdida de tiempo.
    Pero TDD es más que un nombre chulo y unos test.Personalmente, todavia siento que tardo más con los test pero desde que he empezado a usar TDD cada vez es más común ver mi codigo terminado y estar orgulloso de él, tener la sensación de que no cambiaria nada de él.Para mi ver una mejora la calidad de mi codigo y de propina tener una bateria de test vale el coste de tiempo.

    Esta pregunta es bastante común y los argumentos objectivos con los que suelen responder son:
    La curva de velocidad con en los proyectos con TDD es invertida. Normalmente en un proyecto empiezas muy rapido y según van apareciendo errores se va ralentizando y dependiendo del tamaño del proyecto esta curva de velocidad puede seguir disminuyendo hasta que cada vez que quieras añadir una funcionalidad nueva al programa este se rompa.
    Con TDD en cambio se tarda más en las primeras fases de proyecto pero una vez tienen un estructura montada el número de test que tienes que hacer disminuye.
    Teniendo los test como referencia el tiempo que tardas en encontrar y resolver los problemas se reduce ampliamente y cuando añades una nueva funcionalidad puedes saber en cuention de un segundo o menos si la anteriores funcionalidades siguen funcionando.
    Por otro lado los test te ayudan a desarrollar soluciones más simples.Lo cual, contribuye a disminuir los tiempo de desarrollo.


    TDD como forma de diseño.

    Se basa en un ciclo de rojo, verde,refactor.

    Lo explicaré con el ejemplo que tu me pusiste de la calculadora.
    En TDD primero se hace un test en rojo.
    @Test
    public void sum_2_add_2(){
    Calculadora cal = new Calculadora();

    int result = cal.sum(2,2);

    assertEquals(4,result);
    }
    Ahora tenemos un test en rojo.Ahora nos picamos la funcionalidad minima para que el test funcione.
    public int sum(int n1,int n2){
    return 4;
    }
    Pasamos el test.Test en verde.
    Ahora toca refactorizar como no encontramos nada seguimos.
    Escribimos ahora un test que nos oblique a implementar la funcionalidad

    @Test
    public void sum_4_add_4(){
    Calculadora cal = new Calculadora();

    int result = cal.sum(4,4);

    assertEquals(8,result);
    }
    Tenemos el test en rojo.
    Vale ahora implementamos la funcionalidad minima que nos permita pasar ese test.Obviamente sin romper el anterior.
    public int sum(int n1,int n2){
    return n1 + n2;
    }
    Vale ya tenemos la funcionalidad implementada.
    Y como no es necesario no refactorizamos.

    El ejemplo es muy sencillo, pero las ventajas de trabajar con este metodo es que vas desarrollando la aplicación de la manera más sencilla posible añadiendole funcionalidades con cada test, enfocandote y a la hora de añadir una nueva funcionalidad continuas en el punto donde lo dejaste asegurandote en cuestion de un segundo o menos de que tus antiguas funcionalidades siguen trabajando.
    Según se adquiere experiencia con el TDD los test cada vez te ayudan más a encontrar defectos o mejoras en el diseño de la arquitectura.


    Mi conclusión

    El TDD no es la panacea lleva su tiempo aprenderlo, todos sabemos los que nos supone invertir el tiempo, además el desarrollo puede alargarse sobretodo en la primeras etapas de un proyecto.Pero en ningún caso me parece un perdida de tiempo sino una inversión. Mi consejo es que si tenéis curiosidad vayaís algún evento porque el TDD desde mi punto de vista es algo que se comprende mejor en persona, para que veaís con vuestro propios como se usa el TDD para diseñar,luego jugueís un poco con el TDD y cuando lo veáis más como una herramienta de diseño que como un modo de depurar entonces estaréis en condiciones de decidir si el TDD os resulta util o no.

    Espero que este post os ayude a conocer un poquito mejor el TDD.

    P.S.:El diseño en el TDD es tan importante que todas personas que he conocido que usan TDD me han dicho que el TDD sin usar la reglas de SOLID no produce buen codigo afirmando que sin ellas el TDD pierde parte de su sentido.La verdad es que esta linea la pongo para nombrar a SOLID pero honestamente si hablo de TDD y no nombro a SOLID me siento que estoy omitiendo algo crucial.

    P.S.:Disculpad por la cantidad de texto cuando sale un tema de algo que me gusta tiendo a irme por las ramas

    0
    #15596

    Hace poco tuve que hacer la primera fase de un proyecto de integración para terminar un ciclo que estoy haciendo la primera fase es de 2 semanas y despues puedo seguir en las practicas desarrollando pero ya te digo yo que eso no va a pasar.

    A que viene esto. Pues elegi hacer un proyecto en unity y como me gusta desarrollar en base a TDD vi la oportunidad perfecta para hacer un intento con las herramientas de test que trae unity.Por lo que parecio interensate completar un poco este hilo con mi experienca en esta 2 semanas.

    Lo primero que di cuenta despues de trabajar unas cuantas horas con la libreria de test de unity .Es que están sin terminar o su desarrollo está mal enfocado pero es muy incomodo testear utilizar las librerias tal cual como te bienen o siguiendo los tutoriales.

    Primero porque al estar capadas las herencias sobre componentes de unity como el rigidbody no puedes usar liberias de test dobles paa testear.No quiero entrar en detalles pero resumiendo se puede testear usando estados o comportamientos sino puedes usar dicha libreria no se puedes hacer ningun test por comportamiento lo cual es quitarme la mitad de mis herramientas tipicas de testeo por asi decirlo.

    Segundo los test de integración te obligan tal como está a crear un script o gameobject o ambas cosas para realizar un test.Además esto contribuye a que los test de integracion sean muy dificiles de leer.

    En mis dos semanas no llegue a implantar los test porque la curva de aprendizaje de los test en unity es más complicada que en los lenguajes típico de programación pero si me quede con una estrategia que puede funcionar bien a la hora de testear en unity.Yo no la llegue a integrar porque despues de solucionar el problema conlos test dobles por falta de tiempo no consegui que la que te traen NSubstitute trabajase como yo queria tampoco dire que sea mala quizás simplemente no llegue a aprender a usarla.

    La estrategia es la siguiente haber que les parece:
    1º Tuneé la forma en que utilizaban los test de integración para poder escribir los test script y si lo creia oportuno poder escribir más de un test por script (si la libreria de unity te diriga a hacer un test por script)

    2º Hice los test de integración para testear la logica que incluia directamente las librerias de unity.

    3º Programe creando un cierta capa de abstración entre las librerias de unity y mis propias clases.Por lo que llegue no llamar a las clases de unity si no a las mias.

    4º.La idea final era con test dobles falsear estás clases que utilizaban unity y partir de ahi testear los estado.Cosa que deberia funcionar pero por poco no llegue a implementarlo.

    En general, no recomiendo trabajar con test en unity si nunca has hecho tdd.Aunque siempre recomiendo usar tdd en mayor o menor dedida sobre todo si es un proyecto a medio o largo plazo.Por lo que si vas hacer un proyecto pequeño y no sabes de test ni te acerque a test en unity si el proyecto es mediano lo dejo a tu criterio pero te recomendaria antes ver tdd fuera de unity para coger la dinamica porque los test en unity como están hechos ponen desde mi punto de vista frenos al ciclo de desarrollo del tdd(rojo,verde,refactor)

    • Esta respuesta fue modificada hace 7 meses por  Jonay.
    0
Viendo 3 respuestas - 1 de 3 (de 3 total)

Debes estar registrado para responder a este debate.