Talk comments

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!!

Lo que no me gustó es que con el título de la charla, esperaba otra cosa.

Me gustó mucho. Como siempre pasa con las buenas charlas, lástima que no hubiera mas tiempo.

Nada que agregar que no se haya dicho ya. Me quito el sombrero.