introducing bdd elements to unit testing.pptx
Post on 26-Jun-2015
1.008 Views
Preview:
DESCRIPTION
TRANSCRIPT
Experiences introducing BDD and BDD elements
To unit testing and a legacy codebase
XP 2010, June 3rd 2010
Background
A local, familyman, 2 children
Developer, Consultant
BEKK Consulting
10+ years
Seen many types of projects
@ah74
hammervold.com/anders
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
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
Example: BDD using Cucumber features
http://www.engineyard.com/blog/2009/cucumber-introduction/
Example: ”BDDTest”
Adapted from and inpired by code and examples from: Torbjørn Marø and Jonas follesø
Example: ”BDDTest” adapted
Experiment: Regions
Experimental,
IDE-specific
Effects: The skeptic
”I know how to write tests”
Effects: The skeptic
”Wow this test became so much simpler!”
”This was almost fun”
How
~20 minute interviews
– Developers
– Testers
– Customers
5 different projects
– May 2010
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
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”
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
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
Some success-criteria
Access to a mentor
Commitment from the team
Willingness to learn
Including the customer
top related