An Introduction to BDD

Transcript

1. Part  I:  An  Introduc.on  To  BDD  
2. Art  Class  Part  I   I’d like a drawing of a bird, please. Must have 2 wings and a beak. Thx. Chris.
3. Show  Me  The  Bird  
4. Show  Me  The  Bird  
5. Show  Me  The  Bird  
6. Show  Me  The  Bird  
7. Show  Me  The  Bird  
8. Show  Me  The  Bird  
9. Show  Me  The  Bird  
10. Best  Case  Scenario  
11. Worst  Case  (Likely)  Scenario  
12. "The  hardest  single  part  of  building  a  so4ware   system  is  deciding  precisely  what  to  build."       -­‐  No  Silver  Bullet  [2005],  Fred  Brooks     What  About  SoBware?  
13. Tradi.onal  SoBware  Delivery   Planning   Analysis   Design   Code   Test   Deploy  
14. Art  Class  Part  II  
15. Planning   Analysis   Design   Code   Test   Deploy   Cost  of  Change   $ Time   Barry  Boehm:  “….the  average  cost  to  address  a  defect  rises  exponen.ally  the   longer  it  takes  you  to  find  it”  
16. Feedback  Cycles   •  How  long  does  it  take  to  validate  change?   –  Have  we  built  something  to  specifica.on?   –  Have  we  built  something  free  from  defects?   –  Have  we  built  something  which  is  relevant  to  our  users?       Agile  techniques  reduce  feedback  cycles  from   months  and  weeks  to  days,  hours  and  minutes      
17. "A  project  faces  serious  problems  when  its  language   is  fractured.  Domain  experts  use  their  jargon  while   technical  team  members  have  their  own  language   tuned  for  discussing  the  domain  in  terms  of  design...   Across  this  linguis?c  divide,  the  domain  experts   vaguely  describe  what  they  want.  Developers,   struggling  to  understand  a  domain  new  to  them,   vaguely  understand."       -­‐  Domain  Driven  Design  [2003],  Eric  Evans   A  Further  Complica.on:  Language  
18. Part  II:  Test  Driven  Development  
19. Add   Test   Watch   Test  Fail   Write   Code   Run   Tests   Refactor  
21. Before  Or  ABer?   Fewer   Defects   Fewer  Defects   Constant   Feedback   Simple  Design   High  Test   Coverage   Living   Documenta.on   Confidence  To   Refactor   ABer   Before  
22. Isn’t  It  a  LiWle  Counter  Intui.ve?   Yes,  to  begin  with     It’s  not  easy,  but  it’s  worth  it     S.ck  with  it,  reach  out  for  help  when  you  need  it  
23. Part  III:  Types  of  Test  
24. A  Simple  Applica.on  
25. Unit  Tests   v Cover  paths  through  a  single  object  (or  small  group  of  objects)   v No  external  dependencies   v By  defini.on  highly  localized     v Very  fast  
26. Unit  Test  Characteris.cs   •  It’s  not  a  unit  test  if….   – It  touches  a  db   – It  interacts  with  the  file  system   – It  reaches  out  across  the  network   – It  can’t  e  run  in  parallel  
27. Integra.on  Tests   v Typically  targeted  at  the  boundary  of  the  applica.on   v Some.mes  larger  groups  of  objects   v Somewhat  localized   v Wide  variance  in  .me  to  run  
28. Acceptance  Tests   v Cover  aggregate  code  paths  through  the  applica.on   v Typically  wriWen  from  the  point  of  view  of  the  user   v OBen  interact  with  the  applica.on  through  UI   v Usually  include  external  dependencies   v Weak  correla.on  failure  /  cause   v Generally  slow  to  run  
29. The  Need  For  Speed   •  Problem:  We  want  fast  feedback  so  we  can   validate  change  quickly,  but  UI  based   acceptance  tests  are  slow   •  Solu.on:  Minimize  logic  in  the  UI  and  expose   applica.on  logic  via  loosely  coupled  services.   Use  faster  running  Service  Level  Tests  to  get   the  fast  feedback  we  need  
30. The  Test  Pyramid   Service  Level  Tests  (SLTs)   Slow     running   Fast   running  
31. Part  IV:  A  Short  Recap  
32. Are  We  All  Talking  The  Same   Language?  
33. The  Three  Amigos   Product   Owner   QA   Dev   I  know  the  specifics   of  the  business   problem  we’re   trying  to  solve.   I  know  how  to  use   abstrac.ons  to   produce  working   soBware  that   models  our   domain.   I  know  how  to  ask   clarifying  ques.ons  to   establish  standard  terms   for  a  domain.  I  also  like   exploring  corner  cases.  
34. Introducing  Cucumber   Note:  BDD  itself  is  a  not  a  tool,  but  a   collabora.ve  approach  to  defining  soBware   requirements  which  facilitates  test  automa.on    
35. An  Example   •  Feature,  not  a  test   •  Specifica.on  by  example   •  WriWen  in  language  relevant  to  the  domain  
36. Executable  Specifica.on  
37. Executable  Specifica.on  
38. Cucumber  Anatomy   What  to  do   • Gherkin  features   • No  technical  detail   How  to  do  it   • Step  defini.ons   Execu.on   • System  under  development  (and  test)  
39. Step  Defini.ons  
40. Concentric  Circles   JUnit  
41. An.  PaWern:  Incidental  Detail   VS.   VS.  
42. An.  PaWern:  Impera.ve  Steps   VS.   Focus  on  What,  not  How  
43. An.  PaWern:  Feature  Per  Story   •  Not  all  stories  require  their  own  feature   •  Remember  the  test  pyramid   •  Focus  on  user  journeys   •  Be  ruthless  in  refactoring  your  features  and   step  defini.ons  
44. Part  V:  Enough  Talking