Siempre salgo con regusto agridulce de las ponencias de testing, tal vez porque es el tema que más me entusiasma y nunca consigo conectar con lo que transmiten los ponentes.
Jordi y Eloi, voy a ser un poco duro con vosotros pero espero que lo toméis como algo constructivo.
En primer lugar creo que una charla presentada por dos ponentes debe ser, al menos, 1.5x mejor que las demás. Al menos desde el punto de vista documental, pues tenéis la oportunidad de dedicar más horas a buscar información. En ese sentido creo que vuestra charla hizo aguas, y es que en mi opinión tuvisteis varios errores de concepto.
En primer lugar, la respuesta a la pregunta del título de vuestra charla se me escapó. No conseguí sacar de la charla vuestra opinión sobre cuánto, qué y cómo mockear.
Tampoco vi ninguna definición de qué es BDD y qué es TDD. Dado que los planteáis como cosas separadas, me quedé con ganas de saber qué entendéis vosotros por TDD y BDD. Como más tarde relacionabais TDD con tests rápidos y poco confiables, y BDD con lentos y confiables, pensé que confundíais TDD con tests unitarios y BDD con tests de aceptación. O peor aún, TDD -> PHPUnit y BDD -> Behat. Pero BDD y lo que se ha llamado TDD clásicamente es más una cuestión de perspectiva. Me sorprendió muchísimo que en vuestra charla no se hablara de desarrollo outside-in vs inside-out, o tests de interacción vs tests sobre estado.
En el escenario se os vió inseguros, dubitativos, incluso tratando de poneros de acuerdo entre vosotros antes de responder a las preguntas de los asistentes, lo que me hizo pensar que en realidad no habíais profundizado lo suficiente en el testing como para exponeros en una ponencia de un evento de este nivel.
Estoy seguro de que en la próxima ocasión lo haréis muchísimo mejor.
Tengo una opinión distinta acerca de cosas que se expusieron en la charla, pero me pareció una buena charla. Las slides estaban cuidadas y se analizaron pros y contras de cada enfoque de testing.
Me chocó un poco la slide sobre Quick Check. Parecía metida con calzador, y si no es algo que la gente conociese de ante mano, no creo que se enterasen de cómo funciona (aunque sea a grandes rasgos).
Me faltaron ejemplos prácticos, y realmente el título de la charla no quedó respondido. Se limitaron a exponer lo que ellos usan en sus sistemas, pero con pocas o nulas justificaciones y 0 ejemplos prácticos. No obstante, los contenidos fueron correctos y estuvieron bien expuestos.
Creo que el principal problema de la charla fue que no respondió a la pregunta de "to mock or not to mock", aunque en general me gustó y todos los conceptos que se mostraron me parecieron interesantes y útiles. Como crítica constructiva, en mi opinión el hecho de que haya dos ponentes en una charla debe aportar algo "extra", aunque entiendo que también sea una forma de ayudar a introducir a nuevos ponentes, en este caso Eloi, que para los que hemos hablado alguna vez con él sabemos que tiene mucho que contar :)
Antes de nada, gracias a todos por vuestros comentarios!!
@máximo nuestro foco era centrarnos en la unidad a testear ya que creemos que mucha gente no piensa en la unidad a testear y, por defecto, usa la clase como tal acoplando demasiado los tests al código. Siento que te haya parecido introductoria pero tienes un repo en Github con ejemplos de código usando las 4 librerías (https://github.com/Akamon/to-mock-or-not-to-mock/)
@carles contigo prefiero ir por puntos ;)
- siento que la charla no te haya gustado en absoluto, la próxima vez no dudes en preguntar al final de la presentación o acercarte después en privado para solventar las dudas que no hayamos sabido transmitir.
- El tema del uso de los dobles, creo que más claros no pudimos ser, en nuestra opinión, evítalos siempre que puedas y usa los servicios reales a no ser que sean lentos y/o no deterministas y para separar sistemas (bounded contexts en DDD).
- En ningún momento entramos ni en TDD ni en BDD (sólo teníamos 30 minutos), simplemente fue un apunte/consejo al final de la sesión ya que creemos que hay una corriente de sólo testear con con test unitarios por el hype que tiene TDD.
- Respecto a inside-in vs inside-out o tests de interacción vs tests sobre estado es exáctamente lo que explicamos con las escuelas de Chicago vs London o Classical vs Mockist, como son temas creo que algo avanzados, todavía no hay si quiera nomenclatura estándar (puedes informarte más en la slide de referencias sobre la unidad a testear).
- Soy muy consciente de que en el escenario se me vio inseguro, es la primera vez que hago una ponencia (encima con nada más que 150 developers) por lo que quiero agradecer más si cabe a DeSymfony esta oportunidad y si no me dan muchos más palos, quizás, me atrevo a dar una segunda (en ese caso te haría llegar las slides, como hemos hecho con otros 5 developers esta vez, para que nos des tu opinión antes de hacerla en público)
- En las preguntas nos mirábamos porque no nos habíamos preparado como responder, si una cada uno, todas uno de nosotros o como. Y todavía me rio cuando me viene a la cabeza que en una me escondí detrás de Jordi porque no entendí la pregunta.
- Por último, quiero dejar claro que no será por tiempo dedicado, le hemos dedicado muchas horas, probablemente demasiadas, aunque me sabe mal que te haya parecido lo contrario.
@fiunchinho me encantaría tener la oportunidad de saber más sobre tu posición sobre los tests, a ver si tenemos la oportunidad algún día. Con QuickCheck solo quisimos transmitir el mensaje de que no todo es PHP y no es necesario crear a mano cada casuística, que hay alternativas chulas y para poder profundizar hemos añadido varios enlaces en una de las slides de referencias (los vídeos son muy buenos, los recomiendo).
@alberto estoy de acuerdo que nos faltaron ejemplos prácticos, pero el tiempo no nos daba de sí. Si hay un próxima habrá más código :)
@raul totalmente de acuerdo con que ha sido una manera más fácil para introducirme en este mundo (por mi manera de ser, no lo hubieses hecho nunca solo). Siento que no te haya aportado un plus para ser dos ponentes pero no puedo estar de acuerdo contigo en que no explicamos cuando mockear o no, en lo que si que estoy de acuerdo es que no lo supe transmitir a todos los asistentes.
@pablo si me explicas un poco más que te esperabas, me ayudará si me atrevo con un próxima.
Si conocéis a alguien más que asistiera a la charla, por favor, pedirle cinco minutos para darnos feedback a todos los ponentes ;)
Comments
Comments are closed.
Bien, pero demasiado introductoria.
Me hubiese gustado ver más chicha sobre la comparación de librerías.
Siempre salgo con regusto agridulce de las ponencias de testing, tal vez porque es el tema que más me entusiasma y nunca consigo conectar con lo que transmiten los ponentes.
Jordi y Eloi, voy a ser un poco duro con vosotros pero espero que lo toméis como algo constructivo.
En primer lugar creo que una charla presentada por dos ponentes debe ser, al menos, 1.5x mejor que las demás. Al menos desde el punto de vista documental, pues tenéis la oportunidad de dedicar más horas a buscar información. En ese sentido creo que vuestra charla hizo aguas, y es que en mi opinión tuvisteis varios errores de concepto.
En primer lugar, la respuesta a la pregunta del título de vuestra charla se me escapó. No conseguí sacar de la charla vuestra opinión sobre cuánto, qué y cómo mockear.
Tampoco vi ninguna definición de qué es BDD y qué es TDD. Dado que los planteáis como cosas separadas, me quedé con ganas de saber qué entendéis vosotros por TDD y BDD. Como más tarde relacionabais TDD con tests rápidos y poco confiables, y BDD con lentos y confiables, pensé que confundíais TDD con tests unitarios y BDD con tests de aceptación. O peor aún, TDD -> PHPUnit y BDD -> Behat. Pero BDD y lo que se ha llamado TDD clásicamente es más una cuestión de perspectiva. Me sorprendió muchísimo que en vuestra charla no se hablara de desarrollo outside-in vs inside-out, o tests de interacción vs tests sobre estado.
En el escenario se os vió inseguros, dubitativos, incluso tratando de poneros de acuerdo entre vosotros antes de responder a las preguntas de los asistentes, lo que me hizo pensar que en realidad no habíais profundizado lo suficiente en el testing como para exponeros en una ponencia de un evento de este nivel.
Estoy seguro de que en la próxima ocasión lo haréis muchísimo mejor.
Salud.
Tengo una opinión distinta acerca de cosas que se expusieron en la charla, pero me pareció una buena charla. Las slides estaban cuidadas y se analizaron pros y contras de cada enfoque de testing.
Me chocó un poco la slide sobre Quick Check. Parecía metida con calzador, y si no es algo que la gente conociese de ante mano, no creo que se enterasen de cómo funciona (aunque sea a grandes rasgos).
Me faltaron ejemplos prácticos, y realmente el título de la charla no quedó respondido. Se limitaron a exponer lo que ellos usan en sus sistemas, pero con pocas o nulas justificaciones y 0 ejemplos prácticos. No obstante, los contenidos fueron correctos y estuvieron bien expuestos.
Creo que el principal problema de la charla fue que no respondió a la pregunta de "to mock or not to mock", aunque en general me gustó y todos los conceptos que se mostraron me parecieron interesantes y útiles. Como crítica constructiva, en mi opinión el hecho de que haya dos ponentes en una charla debe aportar algo "extra", aunque entiendo que también sea una forma de ayudar a introducir a nuevos ponentes, en este caso Eloi, que para los que hemos hablado alguna vez con él sabemos que tiene mucho que contar :)
Lo que no me gustó es que con el título de la charla, esperaba otra cosa.
Antes de nada, gracias a todos por vuestros comentarios!!
@máximo nuestro foco era centrarnos en la unidad a testear ya que creemos que mucha gente no piensa en la unidad a testear y, por defecto, usa la clase como tal acoplando demasiado los tests al código. Siento que te haya parecido introductoria pero tienes un repo en Github con ejemplos de código usando las 4 librerías (https://github.com/Akamon/to-mock-or-not-to-mock/)
@carles contigo prefiero ir por puntos ;)
- siento que la charla no te haya gustado en absoluto, la próxima vez no dudes en preguntar al final de la presentación o acercarte después en privado para solventar las dudas que no hayamos sabido transmitir.
- El tema del uso de los dobles, creo que más claros no pudimos ser, en nuestra opinión, evítalos siempre que puedas y usa los servicios reales a no ser que sean lentos y/o no deterministas y para separar sistemas (bounded contexts en DDD).
- En ningún momento entramos ni en TDD ni en BDD (sólo teníamos 30 minutos), simplemente fue un apunte/consejo al final de la sesión ya que creemos que hay una corriente de sólo testear con con test unitarios por el hype que tiene TDD.
- Respecto a inside-in vs inside-out o tests de interacción vs tests sobre estado es exáctamente lo que explicamos con las escuelas de Chicago vs London o Classical vs Mockist, como son temas creo que algo avanzados, todavía no hay si quiera nomenclatura estándar (puedes informarte más en la slide de referencias sobre la unidad a testear).
- Soy muy consciente de que en el escenario se me vio inseguro, es la primera vez que hago una ponencia (encima con nada más que 150 developers) por lo que quiero agradecer más si cabe a DeSymfony esta oportunidad y si no me dan muchos más palos, quizás, me atrevo a dar una segunda (en ese caso te haría llegar las slides, como hemos hecho con otros 5 developers esta vez, para que nos des tu opinión antes de hacerla en público)
- En las preguntas nos mirábamos porque no nos habíamos preparado como responder, si una cada uno, todas uno de nosotros o como. Y todavía me rio cuando me viene a la cabeza que en una me escondí detrás de Jordi porque no entendí la pregunta.
- Por último, quiero dejar claro que no será por tiempo dedicado, le hemos dedicado muchas horas, probablemente demasiadas, aunque me sabe mal que te haya parecido lo contrario.
@fiunchinho me encantaría tener la oportunidad de saber más sobre tu posición sobre los tests, a ver si tenemos la oportunidad algún día. Con QuickCheck solo quisimos transmitir el mensaje de que no todo es PHP y no es necesario crear a mano cada casuística, que hay alternativas chulas y para poder profundizar hemos añadido varios enlaces en una de las slides de referencias (los vídeos son muy buenos, los recomiendo).
@alberto estoy de acuerdo que nos faltaron ejemplos prácticos, pero el tiempo no nos daba de sí. Si hay un próxima habrá más código :)
@raul totalmente de acuerdo con que ha sido una manera más fácil para introducirme en este mundo (por mi manera de ser, no lo hubieses hecho nunca solo). Siento que no te haya aportado un plus para ser dos ponentes pero no puedo estar de acuerdo contigo en que no explicamos cuando mockear o no, en lo que si que estoy de acuerdo es que no lo supe transmitir a todos los asistentes.
@pablo si me explicas un poco más que te esperabas, me ayudará si me atrevo con un próxima.
Si conocéis a alguien más que asistiera a la charla, por favor, pedirle cinco minutos para darnos feedback a todos los ponentes ;)
Gracias!!