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

1. Experiences introducing BDD and BDD
elements
To unit testing and a legacy codebase
XP 2010, June 3rd 2010

2. Background
 A local, familyman, 2 children
 Developer, Consultant
 BEKK Consulting

 10+ years
 Seen many types of projects
 @ah74
 hammervold.com/anders

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. 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. Example: BDD using Cucumber features
http://www.engineyard.com/blog/2009/cucumber-introduction/

6. Example: ”BDDTest”
Adapted from and inpired by code and examples from: Torbjørn Marø and Jonas follesø

7. Example: ”BDDTest” adapted

8. Example: Glue
Tore Vestues, http://glue.codeplex.com

9. Experiment: Regions
 Experimental,
 IDE-specific

10. Effects: The skeptic
 ”I know how to write tests”

11. Effects: The skeptic
 ”Wow this test became so much simpler!”
 ”This was almost fun”

12. How
 ~20 minute interviews
– Developers
– Testers
– Customers
 5 different projects
– May 2010

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. 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. 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. 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. Some success-criteria
 Access to a mentor
 Commitment from the team
 Willingness to learn
 Including the customer