Muchas gracias por compartir tus conocimientos y experiencia, actualemente soy QA pero deseo aprender mas de programacion y en tu canal lo estoy logrando, nuevamente gracias.
En mi facultad tenemos que desarrollar toda la aplicación en base a TDD. Está bueno para asegurarse que todo funciona, pero enlentece mucho y a la hora de modificar y corregir es muy tedioso
O estás enfocando mal el TDD o directamente no te lo han enseñado bien. Hay dos modos de hacer TDD, de dentro hacia fuera y de fuera hacia dentro. Cuando estés implementando un caso de uso, una feature, te recomiendo empezar de fuera hacia dentro (un test que compruebe un escenario del caso de uso: usuario ha sido registrado, fichero ha sido generado correctamente, lo que sea), después ve generando más test a ese mismo nivel de escenario. Es posible que, durante esas implementaciones, encuentres alguna que sea compleja, tenga una parte difícil de depurar.... Ahí, usa TDD de dentro hacia fuera, empezando por lo pequeño. Por otro lado, no todos los test de hacen para quedarse, muchos son solo apoyo para el avance y deben eliminarse por el camino. Si lo haces bien, o lo que estás haciendo realmente no va con TDD, o no deberías tener los problemas que comentas. Por otro lado, muchas gente ve como tedioso que los test "se rompan" con los cambios, pero creo que en realidad es algo bueno, te hace darte cuenta de todo lo que se ve afectado por el cambio que estás introduciendo
@@recetasanabolicaseso mismo ! El TDD ayuda al mantenimiento del testing justamente, siempre vamos a tener que actualizar cosas y lo mejor es hacerlo de manera ordenada
hay escenarios en donde no hay forma de poder proba rla funcionalidad sino es con TDD, por ejemplo sistemas financieros! La unica manera de hacerlos es con TDD sino es inmanejable
Hasta ahora había desarrollado proyectos en solitario sin TDD y hace poco para un proyecto de la universidad decidí hacerlo, y dios mio, fue un cambio impresionante, me sentí como un bebé probando el dulce por primera vez. 😁
Excelente contenido, aunque es bien sabido que Uncle Bob menciona que un test tiene que ser independiente al otro. Pero como bien lo mencionas "Esta es una forma de hacer TDD no tan purista".
todo bien con los desarrolladores. pero en mi caso me aseguro de aplicar una buena práctica que tarda mas a algo así nomas. Pero es capas de sortear bugs por ser un codigo bien hecho. (principiante -> codigo ->funciona->listo) (señor analiz problema -> aplico la mejor solución -> perfecciono el codigo -> codigo funcional y sin errores)
Entiendo por que es bueno y funciona, pero lamento que cuando hace falta plata y el tiempo juega en contra es mejor seguir con la arquitectura y diseño que se planteó en un principio para sacar el proyecto adelante así que TDD es solo un añadido
Hola, con la mejor te lo comento, creo que estas confundiendo algunos conceptos con respecto a tdd. El Given When y Then es propio de BDD y no tanto de tdd (puesto que esta pensado para definir escenarios a mas alto nivel), en cambio en TDD (uses la escuela austriaca o la de londres) se utiliza la triple A (Arrange , Act y Assert) y la idea es probar casos de uso de las features, no hace falta probarlo todo (ademas que es contraproducente ya que generas pruebas muy frágiles) sino aquellos puntos de entrada a los componentes (las interfaces de los componentes), por otro lado TDD es *diseño* (primero diseño la interfaz de uso y luego hago una implementacion mínima para validarla y cuando pase el test refactorizo teniendo ya la certeza de que esa interfaz de uso que diseñe es coherente con el resto del sistema). Me alegra que todavía sigan haciendo vídeos sobre estas practicas ya que son muy muy poderosas para guiar a un buen diseño pero creo que también vale la pena aclarar de que por mas tdd que hagas, si no tenes los conceptos de diseño claros (principios como solid/grasp, patrones de diseño etc) va a ser difícil de que salga un buen código. Te mando un saludo y espero que no tomes a mal el comentario ya que no va de ninguna manera con malas intenciones. Seguí así groso! 🥰🤩💯
@@idcmardelplata nunca me no tomaría mal !! Y estoy de acuerdo :) Lo del given / then / when ya estaba explicando cómo me gusta ordenar mis tests (para mí la triple A es un poco menos "entendible" en proyectos con gente de lengua Española y se me hace explicar más fácil de esta otra manera) y en cuanto a la granuralidad por eso fui a hacer test bien pequeños y en conjunto. Tengo mucho más por estos lados en mi libro gratuito ! the-amazing-gentleman-programming-book.vercel.app/en/book/Chapter01_Clean-Agile#tdd Espero te guste
tdd es para los debiles :'v, y ya en la practica muchas veces no alcanza el tiempo para este tipo de pruebas cuando el programa te lo piden para antier xd
Muchas gracias por compartir tus conocimientos y experiencia, actualemente soy QA pero deseo aprender mas de programacion y en tu canal lo estoy logrando, nuevamente gracias.
Me gusto este video explicas muy bien las cosas que son complejas porque hay mucha gente que divaga cuando explica estas cosas 👍👍
Me encató la explicación, aunque el ide no tanto jajaja
Gracias por el contenido, ahora me queda mucho mas claro
A mi IDE no se lo toca, NVIM for ever !!! :P jaja
Gracias miles por el comentario !
Gran contenido, se agradece
Toma tu like y tu sub éxito compa
Sos groso Alan ❤
En mi facultad tenemos que desarrollar toda la aplicación en base a TDD. Está bueno para asegurarse que todo funciona, pero enlentece mucho y a la hora de modificar y corregir es muy tedioso
O estás enfocando mal el TDD o directamente no te lo han enseñado bien.
Hay dos modos de hacer TDD, de dentro hacia fuera y de fuera hacia dentro. Cuando estés implementando un caso de uso, una feature, te recomiendo empezar de fuera hacia dentro (un test que compruebe un escenario del caso de uso: usuario ha sido registrado, fichero ha sido generado correctamente, lo que sea), después ve generando más test a ese mismo nivel de escenario.
Es posible que, durante esas implementaciones, encuentres alguna que sea compleja, tenga una parte difícil de depurar.... Ahí, usa TDD de dentro hacia fuera, empezando por lo pequeño.
Por otro lado, no todos los test de hacen para quedarse, muchos son solo apoyo para el avance y deben eliminarse por el camino.
Si lo haces bien, o lo que estás haciendo realmente no va con TDD, o no deberías tener los problemas que comentas. Por otro lado, muchas gente ve como tedioso que los test "se rompan" con los cambios, pero creo que en realidad es algo bueno, te hace darte cuenta de todo lo que se ve afectado por el cambio que estás introduciendo
@@recetasanabolicaseso mismo ! El TDD ayuda al mantenimiento del testing justamente, siempre vamos a tener que actualizar cosas y lo mejor es hacerlo de manera ordenada
hay escenarios en donde no hay forma de poder proba rla funcionalidad sino es con TDD, por ejemplo sistemas financieros! La unica manera de hacerlos es con TDD sino es inmanejable
TDD, Trastorno Del Desarrollador?!
jijijij si
😂😂😂😂😂
Gran video!
Ya me suscribí gracias por los cursos
Hasta ahora había desarrollado proyectos en solitario sin TDD y hace poco para un proyecto de la universidad decidí hacerlo, y dios mio, fue un cambio impresionante, me sentí como un bebé probando el dulce por primera vez. 😁
Excelente contenido, aunque es bien sabido que Uncle Bob menciona que un test tiene que ser independiente al otro. Pero como bien lo mencionas "Esta es una forma de hacer TDD no tan purista".
Porfa ahora queremos el BDD, el DDD y todos los D, mejor explicado imposible
te amo vato saludos desde México wey
Lo de las subscripciones debe ser gente que lo ve en smart tvs, sin estar logueados y similares.
todo bien con los desarrolladores. pero en mi caso me aseguro de aplicar una buena práctica que tarda mas a algo así nomas. Pero es capas de sortear bugs por ser un codigo bien hecho. (principiante -> codigo ->funciona->listo) (señor analiz problema -> aplico la mejor solución -> perfecciono el codigo -> codigo funcional y sin errores)
Muy buen pensamiento 😃
@@GentlemanProgramming gracias :)
Que hermoso bigote ❤
Entiendo por que es bueno y funciona, pero lamento que cuando hace falta plata y el tiempo juega en contra es mejor seguir con la arquitectura y diseño que se planteó en un principio para sacar el proyecto adelante así que TDD es solo un añadido
que teclado utilizas ?
@@emmanuelgt Glove 80 ! Tengo una playlist con info :)
@@GentlemanProgramming Gracias, acabo de ver el review suyo, acabo de descubrir el el canal, excelentes videos, un abrazo.
Trastorno de development .... 😂😂😂😂
Jajajajajajaja alguien que lo notó :3
el que no se suscriba espero que le toque un team toxico jajaja
yo pagaria por un curso de testing de este crack
@@dakuni99 dentro de poco se viene dentro del curso de Angular donde enseño testing con Jest + Playwright + Testing Library
Muchas gracias por todo @@GentlemanProgramming
Primero en comentar!!!
Hola, con la mejor te lo comento, creo que estas confundiendo algunos conceptos con respecto a tdd. El Given When y Then es propio de BDD y no tanto de tdd (puesto que esta pensado para definir escenarios a mas alto nivel), en cambio en TDD (uses la escuela austriaca o la de londres) se utiliza la triple A (Arrange , Act y Assert) y la idea es probar casos de uso de las features, no hace falta probarlo todo (ademas que es contraproducente ya que generas pruebas muy frágiles) sino aquellos puntos de entrada a los componentes (las interfaces de los componentes), por otro lado TDD es *diseño* (primero diseño la interfaz de uso y luego hago una implementacion mínima para validarla y cuando pase el test refactorizo teniendo ya la certeza de que esa interfaz de uso que diseñe es coherente con el resto del sistema). Me alegra que todavía sigan haciendo vídeos sobre estas practicas ya que son muy muy poderosas para guiar a un buen diseño pero creo que también vale la pena aclarar de que por mas tdd que hagas, si no tenes los conceptos de diseño claros (principios como solid/grasp, patrones de diseño etc) va a ser difícil de que salga un buen código. Te mando un saludo y espero que no tomes a mal el comentario ya que no va de ninguna manera con malas intenciones. Seguí así groso! 🥰🤩💯
@@idcmardelplata nunca me no tomaría mal !! Y estoy de acuerdo :)
Lo del given / then / when ya estaba explicando cómo me gusta ordenar mis tests (para mí la triple A es un poco menos "entendible" en proyectos con gente de lengua Española y se me hace explicar más fácil de esta otra manera) y en cuanto a la granuralidad por eso fui a hacer test bien pequeños y en conjunto. Tengo mucho más por estos lados en mi libro gratuito !
the-amazing-gentleman-programming-book.vercel.app/en/book/Chapter01_Clean-Agile#tdd
Espero te guste
BDD over TDD.
que es bdd
Yo diría los dos, uno no reemplaza al otro
BDD (Behavior Driven Development) Se centra en el comportamiento del sistema desde la perspectiva del usuario.
@@GentlemanProgramming ah muchas gracias
Quienes vienen de LinkedIn?
tdd es para los debiles :'v, y ya en la practica muchas veces no alcanza el tiempo para este tipo de pruebas cuando el programa te lo piden para antier xd