Cuando hacer commit con TDD
94 views
Skip to first unread message
Aprendiendo TDD
May 29, 2014, 7:56:54 AM5/29/14
to tdde...@googlegroups.com
Hola a todos,
Hemos publicado este post, en el que intentamos explicar cuando integrar el commit en el ciclo TDD.
Esperamos que os sea útil.
César Pistiner
May 29, 2014, 8:27:45 AM5/29/14
to tdde...@googlegroups.com
Hola!!
Definitivamente para mí de todas las opciones es: cuando hemos terminado de refactorizar.
Aunque en la vida real lo que sucede es que avanzo con más de un test y termino haciendo commit de varios test que cubren una determinada funcionalidad.
Lo que nunca haría es commit con un test rojo ya que la idea de integración continua se va al piso! ja
Saludos,
César
--
Has recibido este mensaje porque estás suscrito al grupo "TDDev" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a tddev-sp+u...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a tdde...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/tddev-sp.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
Pablo Braulio
May 29, 2014, 9:38:07 AM5/29/14
to Lista tdd
Entiendo que cuando dices "hacer commit" te refieres a ha subir al repositorio tu código. Que en el caso de git es push. Commit es local.
En ese caso he votado cuando el test está en verde. La refactorización es un paso importante que no debe afectar al funcionamiento de lo programado.
Enviado con MailTrack
Saludos cordiales.
Pablo.
Si lo reenvías, ten la precaución de borrar los datos de procedencia que
encabezarían tu reenvío – empezando por mi dirección de correo
electrónico - . Coloca siempre las direcciones de tus contactos en el
campo <CCO> para que viajen discretas, no en el campo <Para> ni en
el<CC>. De esa forma nadie que lo reciba tendrá constancia de las señas
de los demás destinatarios a los que también se remite. Todo ello a fin
de evitar que nadie se aproveche de todas las direcciones que se van
acumulando al pasar de buzón a buzón para el lanzamiento de correo
basura y otras indeseadas lindezas. Aparte claro está de garantizar la
privacidad.
Pablo.
Si lo reenvías, ten la precaución de borrar los datos de procedencia que
encabezarían tu reenvío – empezando por mi dirección de correo
electrónico - . Coloca siempre las direcciones de tus contactos en el
campo <CCO> para que viajen discretas, no en el campo <Para> ni en
el<CC>. De esa forma nadie que lo reciba tendrá constancia de las señas
de los demás destinatarios a los que también se remite. Todo ello a fin
de evitar que nadie se aproveche de todas las direcciones que se van
acumulando al pasar de buzón a buzón para el lanzamiento de correo
basura y otras indeseadas lindezas. Aparte claro está de garantizar la
privacidad.
Antonio Martinez
May 29, 2014, 10:21:32 AM5/29/14
to tdde...@googlegroups.com
En mi caso he puesto en todas las fases, de hecho voy haciendo commits dentro de la misma fase (la fase de refactorización puede ser larga). Además cuando partes de un test de comportamiento puede que el proceso no sea corto.
En el caso de los push (subir el código al repo remoto) yo subo siempre que termino una feature o al final del dia en mi rama, uso uso Git Flow, por lo que tengo un repo de Release, otro de Development y una rama con cada feature en la que trabajo. Tengo CI en las ramas de Development y de Release y CD en la de Release.
No es problema que una rama no compile, mientras la versión Develop sí y la Release se pueda publicar.
Para mi los commits son pasos en el desarrollo, a veces en una dirección y a veces en otra. pero me gusta hacerlos a menudo, me permite mezclar dos ramas de features con un compañero de forma sencilla y también mantener muchos estados del código. Además los merges son menos problemático cuando tienes muchos commits.
Saludos!
Pablo Braulio
May 29, 2014, 10:23:55 AM5/29/14
to Lista tdd
Entendiendo el commit como el "guardado local de los cambios", estoy de acuerdo con lo que dices.
Enviado con MailTrack
Saludos cordiales.
Pablo.
Si lo reenvías, ten la precaución de borrar los datos de procedencia que
encabezarían tu reenvío – empezando por mi dirección de correo
electrónico - . Coloca siempre las direcciones de tus contactos en el
campo <CCO> para que viajen discretas, no en el campo <Para> ni en
el<CC>. De esa forma nadie que lo reciba tendrá constancia de las señas
de los demás destinatarios a los que también se remite. Todo ello a fin
de evitar que nadie se aproveche de todas las direcciones que se van
acumulando al pasar de buzón a buzón para el lanzamiento de correo
basura y otras indeseadas lindezas. Aparte claro está de garantizar la
privacidad.
Pablo.
Si lo reenvías, ten la precaución de borrar los datos de procedencia que
encabezarían tu reenvío – empezando por mi dirección de correo
electrónico - . Coloca siempre las direcciones de tus contactos en el
campo <CCO> para que viajen discretas, no en el campo <Para> ni en
el<CC>. De esa forma nadie que lo reciba tendrá constancia de las señas
de los demás destinatarios a los que también se remite. Todo ello a fin
de evitar que nadie se aproveche de todas las direcciones que se van
acumulando al pasar de buzón a buzón para el lanzamiento de correo
basura y otras indeseadas lindezas. Aparte claro está de garantizar la
privacidad.
--
Carlos Ble
May 29, 2014, 4:09:06 PM5/29/14
to tdde...@googlegroups.com
Hola!
Yo mas o menos por el estilo, hago commit en rojo, verde y refactor. Y en el refactor muchos commits. Uso mercurial, con lo cual mis commits no rompen el build de todos. Mi regla es que el "diff" del commit debe poderse entender de un vistazo rapido sin necesidad de leer el comentario del commit.
Para los comentarios no me complico. Ejemplo de 3 commits:
red: nombre_del_test_copiado_y_pegado
green
refactor: extract method
refactor: extract method
La productividad brutal, ya nunca hago Ctrl+Z infinito buscando donde demonios funcionaba bien hace un rato.
De cara a resolver conflictos con los demas, mercurial al ser micro-commits los resuelve siempre solito.
De cara a hacer de mentor en un equipo, me permite ver al final del dia el proceso de TDD que ha seguido cada persona. Me ayuda a ver como progresa con TDD y los pasos pequenos.
Hace tiempo publique un articulo sobre esto en AgileRecord:
http://www.agilerecord.com/agilerecord_09.pdf
http://www.agilerecord.com/agilerecord_09.pdf
Saludos :-)
--
Has recibido este mensaje porque estás suscrito al grupo "TDDev" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a tddev-sp+u...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a tdde...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/tddev-sp.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
--
Carlos Ble
www.CarlosBle.com - @carlosble
Check out my latest app for team productivity: www.liveTeamApp.com
Author of the first book on TDD in Spanish: www.dirigidoPorTests.com/el-libro
Francisco Calles
May 29, 2014, 6:14:38 PM5/29/14
to tdde...@googlegroups.com
Hola a todos,
Gracias por todas las aportaciones, me gusta mucho el debate voy a copiarlo en el post para que todos lo puedan leer.
Con "hacer commit" me refiero en local dentro del ciclo de desarrollo.
Antonio: Me parece buenísima tu aportación y creo que es muy buena la diferenciación que haces entre commit en local y push en la rama.
Carlos: Grande como siempre, tu aportación, es un punto de vista muy bueno.
Yo hago commit local en cada test Rojo, a veces, dejo el test escrito aunque sea solo el nombre y hago commit local, si por algún motivo tengo que volver atrás siempre puedo o borrar el test o terminar el ciclo.
También es cierto que después de una refactorización "fuerte o compremetida" también hago commit, pero esto es mas por "precaución" :)
Vicenç Garcia
May 29, 2014, 6:19:31 PM5/29/14
to tdde...@googlegroups.com
Hola buenas,
yo ultimamente estoy intentando aplicar la táctica de Carlos. Hago commits en cada rojo, verde y refactor. Y hago push en cuanto tengo la tarea acabada. Por ahora no tengo queja.
Antonio Martinez
May 30, 2014, 3:12:43 AM5/30/14
to tdde...@googlegroups.com
Otra cosa que se me ha pasado decir (y que lo he recordado al leer el artículo de Carlos) es que estoy continuamente actualizando mi rama con código de la rama principal de desarrollo. En mi caso uso sourcetree y me avisa cuando estoy desincronizado de la rama principal, en cuanto actualizo, propago los cambios a mi rama de feature. Nosotros somos 3 desarrolladores y solemos trabajar en los mismos ficheros porque nos repartimos features end-to-end que van desde la interfaz hasta la BD, así que es fácil que cambiemos mapeos, extendamos clases o modifiquemos la UI, es importante que estos cambios se vean reflejado en el resto de ramas para poder realizar features consistentes.
Yo siempre hago push al final de la mañana y al final de día de mi rama para tener el código disponible en otras máquinas, ya que tengo distinta máquina en el trabajo y en casa.
Yo lo que si hago por ahora es hacer comentarios más largos, suelo explicar un poco que clases he tocado y porqué, un poco como los comentarios de código.
El jueves, 29 de mayo de 2014 13:56:54 UTC+2, Francisco Joaquín Calles Fernández escribió:
Jesús Jiménez Ballano
May 30, 2014, 4:51:20 AM5/30/14
to tdde...@googlegroups.com
Hacer commit en cada mini paso de rojo, verde y refactor no os saca del flow de TDD? No lo he probado nunca, pero salir del editor en cada uno de esos pasos creo que puede hacer que pierda el foco fácilmente.
Hacéis el push con todos esos commits? Normalmente un exceso de información es desinformación y si quiero buscar un cambio que se hizo el mes pasado, no es lo mismo buscarlo entre 100 commits que entre 3000. Cómo manejáis esto?
Lo probaré en alguna cosa personal que haga para ver como de util me resulta.
--
Antonio Martinez
May 30, 2014, 5:11:06 AM5/30/14
to tdde...@googlegroups.com
En mi caso no tengo que salir del editor para hacer un commit, shortcut + texto del commit + enter, si pulso otro enter hace push. No pierdo mucho el foco, más o menos lo mismo que cuando abro "//" para poner un comentario en el código.
En el caso de los commits, pues sí, tengo muchos commits, pero nunca busco por fecha. Busco por feature o por archivo, así se reducen los commits a buscar. Si estoy buscando cuando cambié una clase o un test voy a ese archivo, si quiero ver los cambios relacionados con una feature normalmente tengo el Merge como commit y ahí puedo ver todos los archivos cambiados. También puedes buscar por persona o por texto dentro del commit. Esa es un poco la razón de que mis textos del commits son algo más explicativos por si tengo que buscar por ellos.
En la actualidad estoy probando a usar acrónimos dentro del texto para algunos estados dentro del commit como para localizar algunos estados más específicos.
Por ahora la búsqueda no está siendo un problema, sin embargo sí que lo era anteriormente hacer Merges con commits muy largos, mitad del día resolviendo conflictos.
También mi caso quizás es particular porque sólo yo hago TDD dentro del equipo.
El jueves, 29 de mayo de 2014 13:56:54 UTC+2, Francisco Joaquín Calles Fernández escribió:
César Pistiner
May 30, 2014, 8:14:48 AM5/30/14
to tdde...@googlegroups.com
Buen día a todos,
Perdón por la ignorancia... ¿a qué se refieren cuando hablan de commit local?
Saludos,
César
--
Carlos Díez-Gil Romero
May 30, 2014, 8:17:44 AM5/30/14
to tdde...@googlegroups.com
Buenas,
Cuando trabajas con GIT, los commits van a tu local. No suben hasta que no haces push.
Saludos,
c.
César Pistiner
May 30, 2014, 8:21:22 AM5/30/14
to tdde...@googlegroups.com
Ah! sisi
Ahora sí me cierran varias cosas de las que hablaban, trabajé con GIT a modo de conocerlo.
Gracias por la aclaración Carlos.
Saludos,
César
Martín Salías
Jun 5, 2014, 9:44:05 PM6/5/14
to tdde...@googlegroups.com
Hola, Pablo.
Como está escrito el post, no entra en el detalle de GIT, SVN u otros. Creo que se refiere al commit al repo, o sea al resto del equipo.
Personalmente en GIT hago los commits como si fuese para otra persona. El push para mi es sólo el momento de decir: comparto mis commits. Y prefiero hacerlos cuando llego al verde (antes Y después del refactoring).
Explico:
- nunca haría commit en rojo, porque como bien dijo César (y debemos estar todos de acuerdo, creo), no voy a dejar algo roto, ni romper el build.
- cuando llego al verde probé mi hipótesis, así que COMMIT (y explico lo nuevo que resolví)
- cuando refactorizo, si meto mucho la pata y me arrepiento, REVERT
- cuando refactoricé y quedó todo bien y en verde, COMMIT (y explico rápidamente el refactoring - porque lo quiero en el history)
Si es GIT lo hago lo mismo, porque para mi el repo es un medio de comunicación (el history es el canal, pero el código el contenido). Casualmente eso es una de las grandes ventajas de GIT para mi. Ese ciclo muy corto en SVN se me hacía lentísimo, además de que dependés de que la red ande fenómeno (cuando estás en una LAN no se nota tanto, pero por internet es durísimo).
¡Saludos!
Martín Salías
Jun 5, 2014, 9:47:01 PM6/5/14
to tdde...@googlegroups.com
En mi caso voy del editor a la terminal todo el tiempo, para montones de cosas. Suelo tener tabs separados de la terminal para los tests unitarios, el repo, los tests de aceptación, el servidor, etc.
Saludos,
Reply all
Reply to author
Forward
0 new messages