Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Desarrollo Dirigido por Comportamientos - BDD: ¿Cuál es el valor agregado de hacerlo?

1,007 views

Published on

El BDD se presenta como una opción para poder desarrollar de forma más efectiva al permitirnos especificar los requerimientos de nuestros clientes de forma precisa y que su verificación una vez implementados sea de forma automatizada. Mejora nuestras prácticas al forzarnos a pensar en el código que desearíamos tener para satisfacer los requerimientos de nuestros clientes, esto germina en que tengamos aplicaciones mejor organizadas con APIs más claras y que implementemos a las interfaces/contratos de responsabilidad y colaboraciones entre los diversos objetos del sistema. Pero el contar con herramientas no es suficiente, el desarrollar una técnica efectiva es fundamental para que se tengan los beneficios del BDD.
En alguna época los médicos no se lavaban las manos antes de una cirugía por que lo consideraban una perdida de tiempo, ahora esto es impensable. Llegará el día en que se hará impensable el desarrollar un sistema sin BDD, hagamos que muy pronto sea ese día.

Published in: Technology
  • Be the first to comment

Desarrollo Dirigido por Comportamientos - BDD: ¿Cuál es el valor agregado de hacerlo?

  1. 1. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  2. 2. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  3. 3. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  4. 4. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  5. 5. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  6. 6. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  7. 7. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  8. 8. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  9. 9. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  10. 10. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  11. 11. So6ware  by  Numbers:  Low-­‐Risk,  High-­‐Return  Development.  By  Mark  Denne,  Jane  Cleland-­‐Huang.  Pren%ce  Hall  PTR.  October  10,  2003         Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  12. 12. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  13. 13. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  14. 14. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  15. 15. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  16. 16. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  17. 17. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  18. 18. Cliente  que  %ene  una  meta  con  un  valor   Interfaz  de  Usuario  WUI/GUI   vistas   controladores   modelos   Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  19. 19. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  20. 20. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  21. 21. RSpec   Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  22. 22. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  23. 23. RSpec   “Los   vistas   componentes  e   controladores   interacciones   modelos   que  desearía   tener”   “La  caracterís*ca   que  desearía  tener”   Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  24. 24. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  25. 25. RSpec   “Los   componentes  e   interacciones   que  desearía   tener”   “La  caracterís*ca   que  desearía  tener”   Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  26. 26. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  27. 27. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  28. 28. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  29. 29. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  30. 30. Feature:  [Título  de  la  caracterís%ca  ]      In  order  to  [Valor  de  Negocios]      As  a  [Role]      I  want  [la  acción  que  da  el  valor]   No  se  ejecuta   Su  valor  es  documental   El  valor  de  negocios  se    hace  explicito   Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  31. 31. Scenario:  [Título  del  escenario  de  uso]      Given  [Contexto  -­‐  Precondición]      When  I  [do]  [Acción]      Then  I  should  [see]  [Resultado]   Ejecutable  mediante  los  steps   Valor  de  diseño   El  resultado  esperado  es  explicito   Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  32. 32. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  33. 33. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  34. 34. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  35. 35. RSpec   Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  36. 36. RSpec   describe  [Class]  do      context  [Contexto]  do          it  [ejemplo  de  especificación]              <code>          end      end   end   Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  37. 37. RSpec   Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  38. 38. RSpec   Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  39. 39. RSpec   Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  40. 40. RSpec   “Los  componentes  e   interacciones  que   desearía  tener”   “La  caracterís*ca  que   desearía  tener”   Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  41. 41. RSpec   “Los  componentes  e   interacciones  que   desearía  tener”   “La  caracterís*ca  que   desearía  tener”   Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  42. 42. RSpec   “Los  componentes  e   interacciones  que   desearía  tener”   “La  caracterís*ca  que   desearía  tener”   Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  43. 43. RSpec   “Los  componentes  e   “Soporta  todas  las   simulaciones  de   interacciones  que   navegador”   desearía  tener”   API  y  DSL  similar  a  Webrat   Puede  cambiar  los  simuladores   Navegación,  Clic  de  ligas  y  botones   Interacción  con  formas   Consultas  y  busquedas   Alcances  y  scripWng   Soporta  XPath   “La  caracterís*ca  que   desearía  tener”   Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  44. 44. RSpec   “Los  componentes  e   “Soporta  todas  las   simulaciones  de   interacciones  que   navegador”   desearía  tener”   “La  caracterís*ca  que   desearía  tener”   Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  45. 45. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  46. 46. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  47. 47. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  48. 48. SRP:  Single  Responsibility  Principle   Connascence   OCP:  Open  Closed  Principle   Cuando  dos  cosas  nacen  y  crecen   LSP:  Liskov  SubsWtuWon  Principle   Juntas.   ISP:  Interface  SegregaWon  Principle   DIP:  Dependency  Inversion  Principle   Cuando  hay  connascence  entre  A  y  B   Todo  cambio  en  A  requiere  un  cambio   en  B  para  preservar  lo  correcto  y     viceversa   Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  49. 49. SRP:  Single  Responsibility  Principle   Principio  de  una  Sola  Responsabilidad   No  debería  nunca  haber  más  de  una  razón  para   que  una  clase  cambie     OCP:  Open  Closed  Principle   Principio  de  abierto  cerrado   So6ware  de  enWdades  (clases,  módulos,  funciones,   etc.)  Deben  estar  abiertos  a  la  extensión  pero   cerrado  por  modificación       Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  50. 50. LSP:  Liskov  Subs9tu9on  Principle   Principio  de  subs%tución  de  Liskov   Funciones  que  usen  ...  referencias  a  una  clase  base   deben  ser  capaz  de  uWlizar  objetos  de  clases   derivadas  de  la  base  sin  saberlo   ISN:  Interface  Segrega9on  Principle   Principio  de  segregación  de  interfaces   los  clientes  no  se  vean  obligados  a  depender  de   interfaces  que  no  uWlizan   Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  51. 51. DIP:  Dependency  Inversion  Principle   Principio  de  inversión  de  dependencia   A.  Módulos  de  alto  nivel  no  deben  depender  de   módulos  de  bajo.  Ambos  deben  depender  de   abstracciones     B.  Abstracciones  no  deberen  depender  de  detalles.   Detalles  debeben  de  depender  abstracciones   Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  52. 52. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  53. 53. “Simulador  de   “Soporta  todas  las   RSpec   “Los  componentes  e   navegador  muy   simulaciones  de   interacciones  que   rápido”   navegador”   desearía  tener”   Gracias  a  todas  las  personas  que   han  contribuido  para  que  podamos   contar  con  estas  magnificas   herramientas  y  métodos   “La  caracterís*ca  que   desearía  tener”   Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  
  54. 54. Manuel  Vidaurre    manuel.vidaurre@agiltec.com.mx    @mvidaurre  

×