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.

Introducing bdd elements to unit testing.pptx

1,206 views

Published on

My lightning talk on xp2010 desciribing experiences from 5 projects with introducing BDD or BDD elements to unit testing

Published in: Technology, Education
  • Be the first to comment

Introducing bdd elements to unit testing.pptx

  1. 1. Experiences introducing BDD and BDD elements To unit testing and a legacy codebase XP 2010, June 3rd 2010
  2. 2. Background  A local, familyman, 2 children  Developer, Consultant  BEKK Consulting   10+ years  Seen many types of projects  @ah74  hammervold.com/anders
  3. 3. Background: What I had seen a lot of  POUT  Some testclasses of several k+ lines  Often excellent testcode  Difficult to understand for others  Difficult to come back to after some time away  Focus on test techniques like Mocking  Refactoring later would mean rewriting complex code AND complex tests  in a hurry?  remove tests that are red
  4. 4. BDD and ”BDD elements”  BDD  Started seeing BDD inspired syntax and thinking  Ground up  Which effect did this have ?  Did it correspond with the goals of BDD?  What was happening in other projects right now ?  Examples
  5. 5. Example: BDD using Cucumber features http://www.engineyard.com/blog/2009/cucumber-introduction/
  6. 6. Example: ”BDDTest” Adapted from and inpired by code and examples from: Torbjørn Marø and Jonas follesø
  7. 7. Example: ”BDDTest” adapted
  8. 8. Example: Glue Tore Vestues, http://glue.codeplex.com
  9. 9. Experiment: Regions  Experimental,  IDE-specific
  10. 10. Effects: The skeptic  ”I know how to write tests”
  11. 11. Effects: The skeptic  ”Wow this test became so much simpler!”  ”This was almost fun”
  12. 12. How  ~20 minute interviews – Developers – Testers – Customers  5 different projects – May 2010
  13. 13. Objections?  Some arguments used were the same as against TDD  Fear of change  Technical problems, sometimes new technology  Unwillingness to learn something new  Not true BDD, outside in through ui
  14. 14. Developer perspective  Clear sense of purpose  Recipe to follow  Renewed focus on specification  Smaller, simpler tests  Easier to maintain  Most tests now got a similar structure  Greater number of tests but better organised  ”I give up, i’ll rather go write some BDD-tests, maybe that will cheer me up”
  15. 15. Customer perspective  ”The bug-rate dropped significantly”  ”I could see that they (the developers) had understood what I meant”  ”I never understood the code anyway” – Generally responded well to the syntax – Customers were generally more agile than developers perhaps expected – When given a chance – Clarifying requirements
  16. 16. Success  Many of the results can be attributed to TDD  BDD elements added to and amplified these  Skeptics became ”believers”  The customers showed greater involvement  Testers could write features in the error report
  17. 17. Some success-criteria  Access to a mentor  Commitment from the team  Willingness to learn  Including the customer

×