0
Apuntes de la #XPWeek 2011                      Cursos básico y avanzado                  Complemento al libro de TDD:    ...
Hagas o no hagas TDD/BDDLo más importante:● Que no haya código duplicado● Que los nombres sean adecuados  ●   No dejar lit...
El algoritmo TDDRojo: usa toda tu experiencia y conocimiento paraexpresar el comportamiento que te gustaria quetu código t...
Malinterpretaciones del algoritmoAlgunos compañeros pensaron que para obtenerverde rápido podían escribir en el test, una ...
Aclarandonos con el diseñoLo primero es saber qué quieres diseñar/probar.Si no está totalmente claro el comportamiento aes...
De lo fácil a lo difícilTDD no está bien hecho sin la TODO-List. Y laTODO-List está bien gestionada cuando loscasos más se...
Dos enfoquesOutside-in (tambien top-down): Empezamos adiseñar clases a las que de antemano lescreamos dependencias. Estas ...
Unit Vs IntegrationMaximiza el número de tests unitarios y minimizael de integración. Los tests unitarios siguen lasreglas...
Mantenimiento de los testsEl código de los tests es igual de importante que el deproducción por eso su mantenimiento es cl...
Test DoublesNunca doblamos clases que no son nuestras.Usamos stubs para doblar métodos de consulta.Usamos espias y mocks p...
No te olvides de la arquitecturaLas características horizontales deben serestudiadas y diseñadas al comienzo del proyecto:...
MVC no es orientado a objetosEl patrón MVC no es orientado a objetos.              Noimporta que en Grails un Controller s...
Controller: responsabilidadesEl controller gestiona entrada y salida. Su misiónes conectar con negocio/dominio sin que ést...
Controller = N, Negocio = N - 1Los objetos de dominio/negocio no deben sabernada del controller.El controller debe hacer e...
XP son mas cósasPair Programming (PP):● 2 Teclados y 2 ratones en un mismo ordenador con unagran pantalla.● El navegador n...
XP son valores● Pragmatismo● Sentido común● Mejora contínua● Autosuperación● Reconocer los errores propios● Trabajo en equ...
Artesanía del software● Lo principal es maximizar el valor para el cliente.● Trabaja con plena atención en lo que se hace....
Upcoming SlideShare
Loading in...5
×

Apuntes #XPweek

864

Published on

Apuntes de la formacion impartida en XPWeek 2011

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
864
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
14
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Transcript of "Apuntes #XPweek"

  1. 1. Apuntes de la #XPWeek 2011 Cursos básico y avanzado Complemento al libro de TDD: www.dirigidoPorTests.com/el-libroParticipantes: @carlosble, @eamodeorubio, @AlfredoCasado, @alberto_vilches, @jsayar, @R_Climent,@istepaniuk, @vicentgodella, @josmasflores, @david_vi11a, @magmax9, @ArturoHerrero, @skirmish84, @antoniojrossi, @earroyoron, @farroyocastro, @losalamero, @bitness_es Aviso: Usaremos indistintamente los términos TDD y BDD.
  2. 2. Hagas o no hagas TDD/BDDLo más importante:● Que no haya código duplicado● Que los nombres sean adecuados ● No dejar literales en el código: reemplazar números mágicos y cadenas por constantes con semántica. ● Con palabras del dominio de negocio ● Sin información técnica ● No vale “utils”, “tools”, “Helper”, “Impl”, “I”, “Abstract”, etcLo segundo más importante:● S.O.L.I.Dhttp://www.carlosble.com/2011/07/ultra-simplifying-solid/http://eamodeorubio.wordpress.com/2011/03/07/diseno-software-agil-4-solid-1-%c2%bftus-clases-son-bomberotorero/Están resumidos en español en el libro de TDD: www.dirigidoPorTests.com/el-libro.
  3. 3. El algoritmo TDDRojo: usa toda tu experiencia y conocimiento paraexpresar el comportamiento que te gustaria quetu código tuviese, con la mejor API posible.Verde: No pienses, actúa rápidoRefactor: No vale añadir funcionalidad. Aplica lasreglas del código limpio vistas en la diapositivaanterior
  4. 4. Malinterpretaciones del algoritmoAlgunos compañeros pensaron que para obtenerverde rápido podían escribir en el test, una APItemporal de su código de producción, que luegopodrían cambiar.Error: El código del test no se puede cambiar unavez está en verde. El refactor de los tests noadmite cambios en la API publica del SUT (códigode producción).
  5. 5. Aclarandonos con el diseñoLo primero es saber qué quieres diseñar/probar.Si no está totalmente claro el comportamiento aespecificar, no puedes lanzarte a tirar código.El SUT (objeto a prueba) nunca puede ser undoble, sino, ¡no estamos ejecutando nuestrocódigo!¿Quién es el SUT? ¿Quíenes son loscolaboradores? ¿Qué responsabilidades tienecada elemento?
  6. 6. De lo fácil a lo difícilTDD no está bien hecho sin la TODO-List. Y laTODO-List está bien gestionada cuando loscasos más sencillos se atacan primero.Tanto con TDD como haciendo sólo refactoring,hay que ir de lo más evidente a lo más ofuscado.¡Lo más fácil primero, siempre y cuando ayude atriangular!
  7. 7. Dos enfoquesOutside-in (tambien top-down): Empezamos adiseñar clases a las que de antemano lescreamos dependencias. Estas aparecen en el testen forma de doble (stub, spy o mock).Inside-out (también bottom-up): Empezamos adiseñar clases pequeñas sin dependenciasaparentes.En ambos casos, pueden emerger nuevosartefactos a base de refactoring.Algunos asocian BDD con el primer enfoque y TDD con el segundo.
  8. 8. Unit Vs IntegrationMaximiza el número de tests unitarios y minimizael de integración. Los tests unitarios siguen lasreglas F.I.R.S.TLos test de integración dependen de plataforma yno hay reglas universales para escribirlos. Son undolor y hay que escribir el mínimo suficiente.
  9. 9. Mantenimiento de los testsEl código de los tests es igual de importante que el deproducción por eso su mantenimiento es clave. Aplicamos la no-duplicidad y sobre todo los nombres adecuados.Setup/Teardown adecuados y comunes para todos los tests desu clase.AssertEqual y assertTrue son poco informativos ypoco legibles. Hamcrest nos da más expresividad. Propuesta deformato para Junit:@Test public voidnombre_separado_por_underscores() throws Exception {     …      assertThat(result, containsString(“esperado”));}http://weblogs.javahispano.org/artesanodeprimera/entry/escribiendo_mejores_test_ii
  10. 10. Test DoublesNunca doblamos clases que no son nuestras.Usamos stubs para doblar métodos de consulta.Usamos espias y mocks para doblar acciones.Un espía y un mock pueden simular una consulta igualque un stub.El mock es un policía estricto. Un espía es un stub queademás recuerda todo lo ocurrido y nos lo puede decir.http://weblogs.javahispano.org/artesanodeprimera/entry/escribiendo_mejores_test_iii_mocking
  11. 11. No te olvides de la arquitecturaLas características horizontales deben serestudiadas y diseñadas al comienzo del proyecto:http://www.carlosble.com/2011/01/tddbdd-architecture-and-frameworks/Las características verticales (requisitos denegocio), emergen en nuestro BDD. A vecesaplicamos patrones de diseño expresando lostests de la manera adecuada, sin que sea YAGNI(innecesario).
  12. 12. MVC no es orientado a objetosEl patrón MVC no es orientado a objetos. Noimporta que en Grails un Controller sea una clase con métodosy en Django sea un módulo con métodos. Ciertamente atacar a loscontrollers con pruebas es mucho mas sencillo con Grails . El MVC es unpatrón arquitectónico.Cuanto más nos acoplamos a un frameworkMVC, menos margen tenemos para modelarcomportamiento con objetos.Acoplate al framework para hacer CRUD peroevitalo para permitir que TDD te ayude a modelarel negocio de manera emergente.
  13. 13. Controller: responsabilidadesEl controller gestiona entrada y salida. Su misiónes conectar con negocio/dominio sin que éstetenga que conocer elementos como HttpRequest.Podemos diseñar la casuistica del controlleraplicando TDD, con espías y stubs para losobjetos de negocio.El paso de parámetros de controller a negocio sedebe hacer con DTOs (Data Transfer Objects, objetos tipo structinicialmente) cuando son más de dos parámetros
  14. 14. Controller = N, Negocio = N - 1Los objetos de dominio/negocio no deben sabernada del controller.El controller debe hacer el menor número posiblede llamadas al dominio.Ej/Test: El usuario logueado puede enviar un mensaje al usuario registrado connickname paco.Implementación: El controller necesita obtener el usuario logueado de la sesión.Puede por tanto pedir el usuario al servio de sesion, porque necesitamosquitarnos la capa HTTP antes de pasar a dominio (no pasamos un Request adominio) pero NO obtendrá el usuario con nickname paco, simplemente pasaráel nickname al dominio. Dominio sabrá qué debe hacer con el nickname.
  15. 15. XP son mas cósasPair Programming (PP):● 2 Teclados y 2 ratones en un mismo ordenador con unagran pantalla.● El navegador no interrumpe, apunta y aporta.● Navegador y piloto se intercambian frecuentemente.● Empatía, respeto, y no más de 5 horas al día.Integración contínua (CI):No tiene por qué ser automática pero es aconsejable. Laidea es unir del código de todos todo el tiempo y llevarloa UAT (user acceptance testing).El código es de todos: Code reviews + PP
  16. 16. XP son valores● Pragmatismo● Sentido común● Mejora contínua● Autosuperación● Reconocer los errores propios● Trabajo en equipo● No basta con hacerlo funcionar, hay que hacerlobien.
  17. 17. Artesanía del software● Lo principal es maximizar el valor para el cliente.● Trabaja con plena atención en lo que se hace.● El artesano no se hace en dos días.● Es responsabilidad del que aprende elaprovechar la ayuda del que enseña. http://www.etnassoft.com/biblioteca/apprenticeship-patterns/● Aprende de los demás y comparte lo que sabe
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×