The document discusses using Behavior Driven Development (BDD) and Test Driven Development (TDD) for software development. It provides background on several speakers for an upcoming event on BDD including their experience and qualifications. Finally, it outlines the agenda for the event which will cover XP, BDD, and a panel discussion on practices for the approaches.
Building In Quality: The Beauty Of Behavior Driven Development (BDD)Synerzip
Behavior Driven Development (BDD) began as a means of helping developers practice Test Driven Development (TDD).
In this it was successful, but it quickly proved its value in many other ways. In this presentation, Larry Apke quotes heavily from the work of Uncle Bob Martin to make the case for TDD and then explains how developers can use BDD to take advantage of this excellent software development practice.
Larry also talks about his “Ten Reasons BDD Changes Everything” along with some easy ways to begin implementation of BDD in your software development organization immediately and what the corresponding future steps would be to take full advantage of this technique.
Contents:
Behavior Driven Development (BDD)
Features of BDD
BDD Tools
BDD Framework
Examples of Cucumber/SpecFlow/BDD test
Gherkin – BDD Language
The Problem
Example of Gherkin
The Conclusion
SpecFlow Feature File
Keywords for the Feature File creation
A common perception of behavior-driven development (BDD) focuses on test automation with Cucumber-style “Given..When..Then” scenarios. But this is just the tip of the iceberg: in fact BDD ranges from requirements discovery and description through to driving technical design and implementation; helping testers focus their testing efforts more effectively; and even providing reliable, useful, and accurate technical documentation.
This session discusses what BDD is about, its benefits, and how it affects development teams and processes. You will see how JVM teams can effectively implement BDD with tools such as JBehave, Cucumber, Thucydides, and Spock. Come learn how much more there is to BDD than just “Given..When..Then.”
Behavior Driven Development Pros and ConsIosif Itkin
The Cons of Behavior Driven Development (BDD)
Ivan Bobrov, ClubQA Co-Founder, Kostroma
The Pros of Behavior Driven Development (BDD): Business User Scenarios
Natalia Zaitseva, Exchange Functional Test Automation Lead Innovative Trading Systems
EXTENT Conference.
October 29-30, 2011
Test Automation for Trading Systems
Renaissance Hotel Moscow
Behaviour-driven development (BDD) started as an improved variation on test-driven development, but has evolved to become a formidable tool that helps teams communicate more effectively about requirements, using conversation and concrete examples to discover what features really matter to the business. BDD helps teams focus not only on building features that work, but on ensuring that the features they deliver are the ones the client actually needs.
Learn what BDD is, and what it is not
Understand that the core of BDD is around conversation and requirements discovery, not around tools.
Understand the difference and similarities between BDD at the requirements level, and BDD at the coding level.
Learn what BDD tools exist for different platforms, and when to use them
Behaviour-Driven Development (BDD) is a game changer for the whole team! More than just a testing technique, BDD is both a collaboration and a verification tool, and a vital step on the road to Continuous Delivery. In this session, you will learn what BDD is about, its benefits, and how it affects development teams and processes. But you will also see BDD techniques applied to a real project using tools like JBehave, Cucumber, Selenium 2, Thucydides and more!
- Learn how BDD helps teams focus on discovering and delivering the features that really matter! - Learn what it takes to write more relevant and more maintainable automated acceptance tests - Discover how a well-designed set of automated acceptance criteria can also be a powerful documentation and reporting tool. - See where BDD fits into a Continuous Delivery pipeline.
- And learn how product owners use BDD and Thucydides to drive, coordinate and document releases.
Learn how much more there is to BDD than just “Given..When..Then”!
Building In Quality: The Beauty Of Behavior Driven Development (BDD)Synerzip
Behavior Driven Development (BDD) began as a means of helping developers practice Test Driven Development (TDD).
In this it was successful, but it quickly proved its value in many other ways. In this presentation, Larry Apke quotes heavily from the work of Uncle Bob Martin to make the case for TDD and then explains how developers can use BDD to take advantage of this excellent software development practice.
Larry also talks about his “Ten Reasons BDD Changes Everything” along with some easy ways to begin implementation of BDD in your software development organization immediately and what the corresponding future steps would be to take full advantage of this technique.
Contents:
Behavior Driven Development (BDD)
Features of BDD
BDD Tools
BDD Framework
Examples of Cucumber/SpecFlow/BDD test
Gherkin – BDD Language
The Problem
Example of Gherkin
The Conclusion
SpecFlow Feature File
Keywords for the Feature File creation
A common perception of behavior-driven development (BDD) focuses on test automation with Cucumber-style “Given..When..Then” scenarios. But this is just the tip of the iceberg: in fact BDD ranges from requirements discovery and description through to driving technical design and implementation; helping testers focus their testing efforts more effectively; and even providing reliable, useful, and accurate technical documentation.
This session discusses what BDD is about, its benefits, and how it affects development teams and processes. You will see how JVM teams can effectively implement BDD with tools such as JBehave, Cucumber, Thucydides, and Spock. Come learn how much more there is to BDD than just “Given..When..Then.”
Behavior Driven Development Pros and ConsIosif Itkin
The Cons of Behavior Driven Development (BDD)
Ivan Bobrov, ClubQA Co-Founder, Kostroma
The Pros of Behavior Driven Development (BDD): Business User Scenarios
Natalia Zaitseva, Exchange Functional Test Automation Lead Innovative Trading Systems
EXTENT Conference.
October 29-30, 2011
Test Automation for Trading Systems
Renaissance Hotel Moscow
Behaviour-driven development (BDD) started as an improved variation on test-driven development, but has evolved to become a formidable tool that helps teams communicate more effectively about requirements, using conversation and concrete examples to discover what features really matter to the business. BDD helps teams focus not only on building features that work, but on ensuring that the features they deliver are the ones the client actually needs.
Learn what BDD is, and what it is not
Understand that the core of BDD is around conversation and requirements discovery, not around tools.
Understand the difference and similarities between BDD at the requirements level, and BDD at the coding level.
Learn what BDD tools exist for different platforms, and when to use them
Behaviour-Driven Development (BDD) is a game changer for the whole team! More than just a testing technique, BDD is both a collaboration and a verification tool, and a vital step on the road to Continuous Delivery. In this session, you will learn what BDD is about, its benefits, and how it affects development teams and processes. But you will also see BDD techniques applied to a real project using tools like JBehave, Cucumber, Selenium 2, Thucydides and more!
- Learn how BDD helps teams focus on discovering and delivering the features that really matter! - Learn what it takes to write more relevant and more maintainable automated acceptance tests - Discover how a well-designed set of automated acceptance criteria can also be a powerful documentation and reporting tool. - See where BDD fits into a Continuous Delivery pipeline.
- And learn how product owners use BDD and Thucydides to drive, coordinate and document releases.
Learn how much more there is to BDD than just “Given..When..Then”!
Think BDD is just for web sites? Think again! In this talk, we rethink traditional software testing strategies in the context of micro-services and Behaviour-Driven Development. We will see how traditional testing approaches are both inadequate and poorly targeted for micro-services development. We will learn how to use BDD techniques to discover, describe and document micro-service requirements, and tools like Cucumber and Serenity to turn these requirements into automated acceptance tests and living documentation. We will see how Consumer-Driven Contract tools help ensure that micro-services play well together, and how you can implement the details with the help of unit-testing tools like Spock and REST-Assured.
Slides from the London Agile Testing Meetup of November 25 2014:
John Ferguson Smart is a specialist in BDD, automated testing and software life cycle development optimization. John is a well-known speaker at many international conferences and events and an accomplished author (John's new book BDD in Action was published last month).
John presents a talk discussing how to write solid, reliable and maintainable automated web tests using the best-of-breed open source technologies like Selenium WebDriver, Serenity, JBehave and Cucumber.
Do you already know what big ball of mud means?
And code smell?, Is your nose prepared to detect them?
Can you affirm that you are commited with the mantainability?
Do you have architectural sensibility to avoid these kind of situations? Or you are comfortable with the inertia of the day-to-day task of patching the holes. (it doesn't matter if it works..)
While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed.
This talk is intended to identify and summarize the causes that lead to misusing our time on complex maintenance, and give tips and best practices to avoid the big ball of mud and to achieve the best quality products.
Developers Nepal Meetup #4 was organized on February 4 2017 at Fusemachines Nepal.
The event was organized by the team of Developers Nepal and supported by Toptal.
Behaviour Driven Development is an increasingly popular Agile development practice that turns testing on its head. It turns automated acceptance testing from a verification activity, done once the development work is done, to a specification activity, with tester involvement starting from the word go.
In this talk, we will look at how Behaviour Driven Development radically changes the traditional tester role in Agile projects, and empowers them to contribute much more to the successful outcomes of the project. We will see how collaboratively written acceptance criteria help reduce assumptions and errors in the early phases of the project, and help ensure that the features being built are both well understood and valuable to the business. We will look at ways to write more effective, easier to maintain automated acceptance tests. And we will see how automated and manual acceptance test reporting can be combined to provide valuable progress and release preparation reporting.
Refactoring legacy code driven by tests - ITALuca Minudel
Are you working on code poorly designed or on legacy code that’s hard to test? And you cannot refactor it because there are no tests?
During this Coding Dojo you’ll be assigned a coding challenge in Java, C#, Ruby, JavaScript or Python. You will face the challenge of improving the design and refactoring existing code in order to make it testable and to write unit tests.
We will discuss SOLID principles, the relation between design and TDD, and how this applies to your solution.
Reading list:
Growing Object-Oriented Software, Guided by Tests; Steve Freeman, Nat Pryce
Test Driven Development: By Example; Kent Beck
Working Effectively with Legacy; Michael Feathers
Agile Software Development, Principles, Patterns, and Practices; Robert C. Martin (C++, Java)
Agile Principles, Patterns, and Practices in C#; Robert C. Martin (C#)
The Technical Debt Trap - Michael "Doc" NortonLeanDog
Technical Debt has become a catch-all phrase for any code that needs to be re-worked. Much like Refactoring has become a catch-all phrase for any activity that involves changing code.
These fundamental misunderstandings and comfortable yet mis-applied metaphors have resulted in a plethora of poor decisions.
What is technical debt?
What is not technical debt?
Why should we care?
What is the cost of misunderstanding?
What do we do about it?
Technical debt is often characterized as design or code tradeoffs. In this talk I discuss how shortcuts in requirements analysis might lead to technical debt as well.
Pair Programming, TDD and other impractical thingsMarcello Duarte
"Why should we write our tests first? Isn't that going to slow my development?" "What? Assigning a single task to 2 developers? How is that efficient? What a waste of resources!" "Look, in the perfect world your advises are great, but I have a project to finish here." In this talk Marcello explores efficiency in contrast to effectiveness. He looks into how practices, traditionally accepted as efficient, sometimes turn out to be less effective than a few "impractical" things he has come across.
Agile Testing: A pragmatic overview and new entry in Intelliware’s Agile Methodology Series.
What you’ll learn in this presentation:
Intelliware’s Chief Technologist, BC Holmes, provides a pragmatic overview of Agile testing. Complete with many examples, this presentation is ideal for those looking for a practical take on software testing in an Agile environment.
The presentation covers:
- Why do we use Agile testing?
- What Agile testing isn’t
- What Agile testing is: unit testing and test-driven development (TDD)
- High-level properties of good tests
- Testing in different languages
- Test suites and code coverage
- Using mock objects to help isolate units
- Beyond unit testing
Tdd vs bdd vs atdd — developers’ methodologies to navigate complex developmen...Katy Slemon
Know key differences between major development methodologies TDD vs BDD vs ATDD in this post that focus on the task of the developers and their creations
Domain-Driven Design provee las recomendaciones que Behaviour-Driven Development necesita para hacer de las conversaciones una actividad productiva que permite a Scrum progresar de forma efectiva sobre la visión del software.
Think BDD is just for web sites? Think again! In this talk, we rethink traditional software testing strategies in the context of micro-services and Behaviour-Driven Development. We will see how traditional testing approaches are both inadequate and poorly targeted for micro-services development. We will learn how to use BDD techniques to discover, describe and document micro-service requirements, and tools like Cucumber and Serenity to turn these requirements into automated acceptance tests and living documentation. We will see how Consumer-Driven Contract tools help ensure that micro-services play well together, and how you can implement the details with the help of unit-testing tools like Spock and REST-Assured.
Slides from the London Agile Testing Meetup of November 25 2014:
John Ferguson Smart is a specialist in BDD, automated testing and software life cycle development optimization. John is a well-known speaker at many international conferences and events and an accomplished author (John's new book BDD in Action was published last month).
John presents a talk discussing how to write solid, reliable and maintainable automated web tests using the best-of-breed open source technologies like Selenium WebDriver, Serenity, JBehave and Cucumber.
Do you already know what big ball of mud means?
And code smell?, Is your nose prepared to detect them?
Can you affirm that you are commited with the mantainability?
Do you have architectural sensibility to avoid these kind of situations? Or you are comfortable with the inertia of the day-to-day task of patching the holes. (it doesn't matter if it works..)
While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed.
This talk is intended to identify and summarize the causes that lead to misusing our time on complex maintenance, and give tips and best practices to avoid the big ball of mud and to achieve the best quality products.
Developers Nepal Meetup #4 was organized on February 4 2017 at Fusemachines Nepal.
The event was organized by the team of Developers Nepal and supported by Toptal.
Behaviour Driven Development is an increasingly popular Agile development practice that turns testing on its head. It turns automated acceptance testing from a verification activity, done once the development work is done, to a specification activity, with tester involvement starting from the word go.
In this talk, we will look at how Behaviour Driven Development radically changes the traditional tester role in Agile projects, and empowers them to contribute much more to the successful outcomes of the project. We will see how collaboratively written acceptance criteria help reduce assumptions and errors in the early phases of the project, and help ensure that the features being built are both well understood and valuable to the business. We will look at ways to write more effective, easier to maintain automated acceptance tests. And we will see how automated and manual acceptance test reporting can be combined to provide valuable progress and release preparation reporting.
Refactoring legacy code driven by tests - ITALuca Minudel
Are you working on code poorly designed or on legacy code that’s hard to test? And you cannot refactor it because there are no tests?
During this Coding Dojo you’ll be assigned a coding challenge in Java, C#, Ruby, JavaScript or Python. You will face the challenge of improving the design and refactoring existing code in order to make it testable and to write unit tests.
We will discuss SOLID principles, the relation between design and TDD, and how this applies to your solution.
Reading list:
Growing Object-Oriented Software, Guided by Tests; Steve Freeman, Nat Pryce
Test Driven Development: By Example; Kent Beck
Working Effectively with Legacy; Michael Feathers
Agile Software Development, Principles, Patterns, and Practices; Robert C. Martin (C++, Java)
Agile Principles, Patterns, and Practices in C#; Robert C. Martin (C#)
The Technical Debt Trap - Michael "Doc" NortonLeanDog
Technical Debt has become a catch-all phrase for any code that needs to be re-worked. Much like Refactoring has become a catch-all phrase for any activity that involves changing code.
These fundamental misunderstandings and comfortable yet mis-applied metaphors have resulted in a plethora of poor decisions.
What is technical debt?
What is not technical debt?
Why should we care?
What is the cost of misunderstanding?
What do we do about it?
Technical debt is often characterized as design or code tradeoffs. In this talk I discuss how shortcuts in requirements analysis might lead to technical debt as well.
Pair Programming, TDD and other impractical thingsMarcello Duarte
"Why should we write our tests first? Isn't that going to slow my development?" "What? Assigning a single task to 2 developers? How is that efficient? What a waste of resources!" "Look, in the perfect world your advises are great, but I have a project to finish here." In this talk Marcello explores efficiency in contrast to effectiveness. He looks into how practices, traditionally accepted as efficient, sometimes turn out to be less effective than a few "impractical" things he has come across.
Agile Testing: A pragmatic overview and new entry in Intelliware’s Agile Methodology Series.
What you’ll learn in this presentation:
Intelliware’s Chief Technologist, BC Holmes, provides a pragmatic overview of Agile testing. Complete with many examples, this presentation is ideal for those looking for a practical take on software testing in an Agile environment.
The presentation covers:
- Why do we use Agile testing?
- What Agile testing isn’t
- What Agile testing is: unit testing and test-driven development (TDD)
- High-level properties of good tests
- Testing in different languages
- Test suites and code coverage
- Using mock objects to help isolate units
- Beyond unit testing
Tdd vs bdd vs atdd — developers’ methodologies to navigate complex developmen...Katy Slemon
Know key differences between major development methodologies TDD vs BDD vs ATDD in this post that focus on the task of the developers and their creations
Domain-Driven Design provee las recomendaciones que Behaviour-Driven Development necesita para hacer de las conversaciones una actividad productiva que permite a Scrum progresar de forma efectiva sobre la visión del software.
Prashant technical practices-tdd for xebia eventXebia India
Theme: Agile Technical Practices
Epic: TDD implementation
Stories:
Context of TDD
What is TDD
Response of Developers to TDD implementation
Practices complimenting TDD
Success with TDD
In this session we will explore the semantics and theory behind Behavior Driven Development and how it can unify a team with its ubiquitous language. We will then go in a tour of TestBox for applying BDD/TDD into our CFML applications. Our tour will end with setting up a Jenkins Continous Integration Server and building scripts for automated testing and reporting.
An overview of Behavioral Driven Development (BDD). This deck covers the basics with an overview as well as some information on why to use Behavioral Driven Development.
Behaviour Driven Development: Oltre i limiti del possibileIosif Itkin
The QA Financial Forum: Milan 2019
23 January at the Excelsior Hotel Gallia.
Anna-Maria Lukina, Exactpro Business Development Director
The QA Financial Forum: Milan is one of the leading fintech conferences in Italy. The event focuses on the latest achievements in software risk management and automation of software testing. The predominant theme of the Milan event will be Quality Assurance for the entire Software Development Life Cycle (SDLC).
The topics under discussion will feature:
- Technologies for Automation & AI
- DevOps & CI/CD
- Value Stream Management
- Test Data Management
- Regulatory Compliance
- App Security & DevSecOps
- Testing and quality assurance of Blockchain platforms
The official language of the event is Italian.
Quality Jam: BDD, TDD and ATDD for the EnterpriseQASymphony
During Quality Jam 2016 I had the privilege of presenting with one of QASymphony's earliest customers, Better Cloud, on how methodologies like BDD, TDD and ATDD scale for the enterprises. Adam Satterfield is the VP of Quality Assurance at Bettercloud and has been in QA for many years; he has taught me a lot about Behavior Driven Development, Test Driven Development, Acceptance Test Driven Development. In the session we share a new way of testing-- what Adam and I believe to be the next generation of testing development.
We know that there are several ways to do testing and we are just showing one new way to do it - If this session doesn't inspire action, hopefully it will at least give you and your team something to think about.
WordCamp Nashville: Clean Code for WordPressmtoppa
Slides from my talk at WordCamp Nashville, including notes. Covers why clean code is important, and provides 10 tips to make your code cleaner, for WordPress and beyond
What is the best Agile Adoption or Agile Transformation organization and team structure and the talent needed to successfully implement Agile across the company? Is there a best approach?
First session within the Gateway to Agile Series presented to the community at Twitter HQ on Jan 19. More information on Gateway to Agile at: https://www.meetup.com/Gateway-to-Agile-Bay-Area/about/
Curated an great dialogue with the AITP San Diego organization in May 2015 on the importance of DevOps to all organizations taking the Digital Enterprise journey.
Have you ever wondered how search works while visiting an e-commerce site, internal website, or searching through other types of online resources? Look no further than this informative session on the ways that taxonomies help end-users navigate the internet! Hear from taxonomists and other information professionals who have first-hand experience creating and working with taxonomies that aid in navigation, search, and discovery across a range of disciplines.
This presentation by Morris Kleiner (University of Minnesota), was made during the discussion “Competition and Regulation in Professions and Occupations” held at the Working Party No. 2 on Competition and Regulation on 10 June 2024. More papers and presentations on the topic can be found out at oe.cd/crps.
This presentation was uploaded with the author’s consent.
0x01 - Newton's Third Law: Static vs. Dynamic AbusersOWASP Beja
f you offer a service on the web, odds are that someone will abuse it. Be it an API, a SaaS, a PaaS, or even a static website, someone somewhere will try to figure out a way to use it to their own needs. In this talk we'll compare measures that are effective against static attackers and how to battle a dynamic attacker who adapts to your counter-measures.
About the Speaker
===============
Diogo Sousa, Engineering Manager @ Canonical
An opinionated individual with an interest in cryptography and its intersection with secure software development.
This presentation, created by Syed Faiz ul Hassan, explores the profound influence of media on public perception and behavior. It delves into the evolution of media from oral traditions to modern digital and social media platforms. Key topics include the role of media in information propagation, socialization, crisis awareness, globalization, and education. The presentation also examines media influence through agenda setting, propaganda, and manipulative techniques used by advertisers and marketers. Furthermore, it highlights the impact of surveillance enabled by media technologies on personal behavior and preferences. Through this comprehensive overview, the presentation aims to shed light on how media shapes collective consciousness and public opinion.
Acorn Recovery: Restore IT infra within minutesIP ServerOne
Introducing Acorn Recovery as a Service, a simple, fast, and secure managed disaster recovery (DRaaS) by IP ServerOne. A DR solution that helps restore your IT infra within minutes.
Sharpen existing tools or get a new toolbox? Contemporary cluster initiatives...Orkestra
UIIN Conference, Madrid, 27-29 May 2024
James Wilson, Orkestra and Deusto Business School
Emily Wise, Lund University
Madeline Smith, The Glasgow School of Art
3. ROB, LARRY, PANEL
Rob Trivetti, MATRIX, Sr Agile Coach, Empower Agile. He has experience
managing complex, high priority, cross-functional and time-sensitive
programs for Agile transformations, social media, eCommerce, SAAS and
telecom companies. Agile leader at AT&T, Intuit, LinkedIn, Walmart, to name
a few. Rob is a West Point graduate and served as the US Army Captain in
the Signal Corps.
Larry Apke is the Agile Program Manager at Oracle. Larry has fulfilled roles:
Agile Leader, Program Manager, Senior Business Analyst, Business
Analyst, and Technical Writer at many organizations. Proven Leader in Agile
Development – Certified Scrum Master (CSM) - Certified Scrum Practitioner
(CSP) - Certified SAFe Agilist (SA). The author of Understanding The Agile
Manifesto: A Brief & Bold Guide to Agile. A recognized leader in the Agile
community and expert speaker, giving presentations to many different
groups such as the Scrum Users Group, Java Users Group, Desert Code
Camp and others. Founder of the Agile Coffee Group in San Antonio.
10. Why Do TDD?
• Maintainability
• Flexibility
• Extensibility
• High Rate of Test Code Coverage
• Streamlined Codebase
• Cleaner Interfaces
• Easier Refactoring of Code
• Tests Provide Some Code Documentation
• Bottom Line - Higher Quality
11. TDD Quotes from “Uncle Bob”
“It is a myth that we can get systems “right the first time.” Instead, we should implement
only today’s stories, then refactor and expand the system to implement new stories
tomorrow. This is the essence of iterative and incremental agility. Test-driven development,
refactoring, and the clean code they produce make this work at the code level.”
Robert “Uncle Bob” Martin is a software development professional
since 1970, co-author of the original Agile Manifesto, author of
numerous books on code quality including Clean code: a handbook
of agile software craftsmanship and The clean coder: a code of
conduct for professional programmers.
12. TDD Quotes from “Uncle Bob”
“The Three Laws of TDD:
1) You may not write production code until you have written a failing unit test.
2) You may not write more of a unit test than is sufficient to fail, and not compiling
is failing.
3) You may not write more production code than is sufficient to pass the currently
failing test.”
13. “Indeed, the ratio of time spent reading versus writing is well over 10 to
1. We are constantly reading old code as part of the effort to write new
code. ...[Therefore,] making it easy to read makes it easier to write.”
“So if you want to go fast, if you want to get done quickly, if you want
your code to be easy to write, make it easy to read.”
TDD Quotes from “Uncle Bob”
14. “A system that is comprehensively tested and passes all of its tests all of the time is a
testable system. That’s an obvious statement, but an important one. Systems that aren’t
testable aren’t verifiable. Arguably, a system that cannot be verified should never be
deployed.”
“If the discipline of requirements specification has taught us anything, it is that well-
specified requirements are as formal as code and can act as executable tests of that code!”
TDD Quotes from “Uncle Bob”
15. “Perhaps you thought that “getting it working” was the first order of business for a
professional developer. I hope by now, however, that this book has disabused you of that
idea. The functionality that you create today has a good chance of changing in the next
release, but the readability of your code will have a profound effect on all the changes that
will ever be made.”
“Programmers who satisfy themselves with merely working code are behaving
unprofessionally. “
“Writing clean code is what you must do in order to call yourself a professional. There is no
reasonable excuse for doing anything less than your best.”
TDD Quotes from “Uncle Bob”
16. In addition to Test Driven Development and writing testable, readable code, there are a
number of other things that go into making one a professional programmer.
• Your code must be secure
• Your code must be performant
• Your code must be deployable
• Your code must integrate (preferably using Continuous Integration)
In other words, code quality must be injected into the code by the professional
programmer. Quality cannot be inspected into the code ex post facto (after the fact)
The Professional Programmer
17. Why Doesn’t Everyone Do TDD?
• Most developers have not learned TDD
• There is a learning curve associated with learning TDD
• TDD is extremely disciplined
• There is a perception that development is slower
• It is difficult to introduce with legacy code
• Developers often need to mock objects and learn mocking
“I kept coming across the same confusion and misunderstandings. Programmers wanted to
know where to start, what to test and what not to test, how much to test in one go, what to
call their tests, and how to understand why a test fails.” - Dan North - Introduction to BDD
18. Along Comes BDD
• Behavior Driven Development
• Originally invented by Dan North to address the issues that developers where having
with TDD
• “My response is behaviour-driven development (BDD). It has evolved out of established
agile practices and is designed to make them more accessible and effective for teams
new to agile software delivery. Over time, BDD has grown to encompass the wider
picture of agile analysis and automated acceptance testing.”
• Created a “ubiquitous language for the analysis process itself!”
• Over time they found that the conversations between business and development where
richer
19. Why Do BDD?
• TDD build it right, BDD builds the right thing
• While there is no silver bullet to software development, BDD (when coupled with
continuous integration) comes as close as anything I have found
• My blog - “10 Reasons Why BDD Changes Everything” was published on 3/6/2012 and
still is the most visited page on my website
20. 10 Reasons Why BDD Changes
Everything
• Communication between business and development is extremely focused as a result of
common language.
• Business needs tie directly to the code that is written.
• Developers know what test cases they should write to accommodate TDD.
• All the underlying benefits of TDD become more easily realized.
• Code is easier to maintain.
• Code is self documenting.
• Stories are easier to “groom” – breakdown, task and plan.
• Teams can be more agile.
• Developers can be trained / on-boarded easier.
• There is more visibility into team progress and status.
21. Step One
Write our story acceptance criteria using BDD scenarios
Step Two
Leverage these BDD scenarios to write our automated tests first in true TDD fashion
Step Three
Leverage a BDD Tool like Cucumber to map human-readable BDD scenarios to the
automated tests
Adopting BDD in Three Simple Steps
22. Step One is accomplished by the three amigos - Product Owner, Developer(s) and Quality
Assurance Person(s).
Step One is accomplished during Story Refinement which is where we go into detail for the
stories that we believe we will take during the next iteration.
This is the first step in transitioning to BDD and the one that brings the most benefit. It was
a pleasant surprise to Dan North and crew, something that they did not plan. Better
communication equals better quality.
Step One - Write Stories With BDD
Acceptance Criteria
23. Step One - Write Stories With BDD
Acceptance Criteria
The Story
Customer withdraws cash
As a customer,
I want to withdraw cash from an ATM,
so that I don’t have to wait in line at the bank.
24. The Story
Customer withdraws cash
As a customer,
I want to withdraw cash from an ATM,
so that I don’t have to wait in line at the bank.
Scenario 1 - Account is In Credit
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned
Step One - Write Stories With BDD
Acceptance Criteria
25. The Story
Customer withdraws cash
As a customer,
I want to withdraw cash from an ATM,
so that I don’t have to wait in line at the bank.
Scenario 2 - Account is overdrawn past the overdraft limit
Given the account is overdrawn
And the card is valid
When the customer requests cash
Then ensure a rejection message is displayed
And ensure cash is not dispensed
And ensure the card is returned
Step One - Write Stories With BDD
Acceptance Criteria
26. In step two we leverage BDD to write our tests and begin the process of TDD. BDD
scenarios can be written directly into tests using comments.
Step Two - Put Your BDD A.C. into
Tests
27. public class AccountIsInCredit extends TestCase {
@Setup
//Scenario 1 - Account is In Credit
// Given the account is in credit
// And the card is valid
// And the dispenser contains cash
Write code here to mock out account and add credit, mock out card and set as valid, etc.
//When the customer requests cash
Call CustomerRequestsCash class (or merthod) and pass values return computed values
@Test
//Then ensure the account is debited
// And ensure cash is dispensed
// And ensure the card is returned
Assert.AssertEquals(ExpectedAccountBalance, Account.Balance);
Assert.AssertEquals(CashDispensed, True);
Assert.AssertEquals(CardReturned, True);
}
Step Two - Put Your BDD A.C. into
Tests
28. • BDD Tool will take human-readable scenarios and use regular expressions to map the
human readable scenarios to Unit Tests.
• BDD Tools will create a unit test and shell automatically (referred to as a step definition
file) that helps in the creation of test.
• When the BDD Tool runs the tests, the output shows which tests passed and failed
against the human-readable scenarios.
• There are BDD Tools for all major languages
Step Three - Use BDD Tool
29. Scenario: Cutting vegetables
Given a cucumber that is 30 cm long
When I cut it in halves
Then I have two cucumbers
And both are 15 cm long
Given(/^a cucumber that is (d+) cm long$/) do |arg1|
pending # express the regexp above with the code you wish you had
end
When(/^I cut it in halves$/) do
pending # express the regexp above with the code you wish you had
end
Then(/^I have two cucumbers$/) do
pending # express the regexp above with the code you wish you had
end
Then(/^both are (d+) cm long$/) do |arg1|
pending # express the regexp above with the code you wish you had
end
Step Three - Use BDD Tool
30. Given /^a cucumber that is (d+) cm long$/ do |length|
@cucumber = {:color => 'green', :length => length.to_i}
end
When /^I (?:cut|chop) (?:it|the cucumber) in (?:halves|half|two)$/ do
@choppedCucumbers = [
{:color => @cucumber[:color], :length => @cucumber[:length] / 2},
{:color => @cucumber[:color], :length => @cucumber[:length] / 2}
]
end
Then /^I have two cucumbers$/ do
@choppedCucumbers.length.should == 2
end
Then /^both are (d+) cm long$/ do |length|
@choppedCucumbers.each do |cuke|
cuke[:length].should == length.to_i
end
end
Step Three - Use BDD Tool
31. #encoding: utf-8
Feature: Showcase the simplest possible cucumber scenario
In order to verify that cucumber is installed and configured correctly
As an aspiring BDD fanatic
I should be able to run this scenario and see that the steps pass (green like a cuke)
Scenario: Cutting vegetables # features/first.feature:8
Given a cucumber that is 30 cm long # features/step_definitions/first_steps.rb:3
When I cut it in halves # features/step_definitions/first_steps.rb:7
Then I have two cucumbers # features/step_definitions/first_steps.rb:14
And both are 15 cm long # features/step_definitions/first_steps.rb:18
1 scenario (1 passed)
4 steps (4 passed)
0m0.005s
Step Three - Use BDD Tool
33. Bonus Step - Use Tool Like Serenity to
Visualize Test Suite
34. BDD Gone Wrong
In the Cucumber Book, the authors describe four things that can go wrong with Cucumber
scenarios:
• Flickering Scenarios - Tests are failing randomly
• Brittle Scenarios – Tests keep breaking unintentionally
• Slow Features – Tests are taking too long to run
• Bored Stakeholders – Stakeholders do not read our features
The Cucumber Book outlines potential problems and solutions.
BDD and TDD is a commitment. Tests are code and must be treated as such. They will
need to be maintained the same as the rest of the code.
35. Helpful Links
• Dan North - Introduction to BDD
• The Cucumber Book: Behaviour-Driven Development for Testers and Developers
• BDD in Action: Behavior-driven development for the whole software lifecycle
• Specification by Example: How Successful Teams Deliver the Right Software
• Cucumber Tool
• Serenity Tool
• Clean Code: A Handbook of Agile Software Craftsmanship