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.

Being Test-Driven: It's not really about testing


Published on

Good news: Test-driven practices have jumped the chasm to general acceptance! The bad news, though, is that while TDD, and BDD are prominent buzzwords in the industry today, they are rife with misconceptions, with many people incorrectly assuming that being test-driven is all about testing. Gain a clearer understanding of Test-Driven Development (TDD), Behavior Driven-Development (BDD), and gain practical insights into how these practices can help teams develop better software.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Being Test-Driven: It's not really about testing

  1. 1. Being Test-Driven It’s not really about testing Raj Indugula George Lively Twitter: @lithespeed
  2. 2. 2 What is the point of test-driven development?
  3. 3. • Driving Common Understanding with Behavior Driven Development • Driving Better Design with Test- Driven Development • Tying it all together • Q&A Outline “The speed of development is the speed of getting an idea from one brain to another” – Alistair Cockburn 3
  4. 4. BDD IS BUILDING THE RIGHT THING Behavior-Driven Development (BDD)
  5. 5. Behavior Driven Development (BDD) 5 Collaboration and conversation to discover essential requirements and identify uncertainty Using rules & examples Expressed in a common language to build a shared understanding To deliver software that matters
  6. 6. Behavior Driven Development (BDD) 6 Collaboration and conversation to discover essential requirements and identify uncertainty Using rules & examples Expressed in a common language to build a shared understanding To deliver software that matters
  9. 9. 9 Different Viewpoints, Shared Understanding 9 Business, Developer, Tester Shared understanding All agree it is ready to be implemented THREE AMIGOS 9 Example Mapping, Matt Wynne Depositor can withdraw cash Limited by amount on deposit Subject to daily and transaction limits Scenario with sufficient funds Limited by daily limit of $500 What is the transaction limit? Cash is dispensed in $10 increments with $20 bills favored Scenario with insufficient funds Fully stocked scenario when withdrawal of $50 results in 2 $20 bills and 1 $10 bill When out of $20s, withdrawal of $50 results in 5 $10 bills Acceptance Scenarios Acceptance Criteria
  11. 11. 11 Feature: ATM withdrawals Our ATM allows depositors to withdraw their funds in cash Rules: Withdrawals are limited by amount on deposit Withdrawals are subject to daily and transaction withdrawal limits Cash is dispensed in $10 increments with $20 bills favored Scenario: Sufficient funds allows successful withdrawal Given a depositor has $2000 on deposit When the depositor requests $200 Then the ATM dispenses $200 And the depositor’s balance is reduced to $1800 … DocumentationHuman readable Structured and keyword-based Allows automation Gherkin
  12. 12. 12 AUTOMATE SPECIFICATIONS AS NEEDED Test Framewor k Integratio n Gherkin Scenarios Specification expressed in common language Step Definitions “Glue” code that ties specification to System under Test Cucumber, SpecFlow, etc.
  14. 14. Test-Driven Development (TDD) TDD IS BUILDING THE THING RIGHT
  15. 15. Reimagine our thinking… 15 How we typically write tests… 1. Think about implementation 2. Write code (fields & methods) 3. Write some test cases to verify behavior Instead, what if we… 1. Write a test to capture expected behavior? 2. Think about implementation to meet expectation? 3. Write code to make the failing test pass? Build functionality incrementally one test at a time…
  16. 16. Test-Driven Development (TDD) 16 Write a new test Test Fails Write Code Test Passes Clean up code, make sure tests pass start here Style of programming in which three activities are tightly interwoven: coding, testing (in the form of writing unit tests) and design (in the form of refactoring) Developer heartbeat Red – Green - Refactor
  17. 17. Business Benefits Requirements verification Regression catching Quicker release cycle Reduced Waste
  18. 18. Developer Benefits Better design choices Prevents gold- plating Confidence / Supports change Momentum
  19. 19. Extreme Programming (XP) - Kent Beck 19 Feedback & Simplicity
  20. 20. But there’s no free lunch… 20 Here are some ways that TDD can lead to WORSE design: • In search of speed, developers will lean too heavily on mocks, locking in place their production code and making refactoring more difficult • Developers will build elaborate dependency injection tools and structures, making their design highly complex and unmaintainable. REMEMBER: the emphasis should be on SIMPLE DESIGN, and not just for your application code but also for your test code. Source: Design.html
  21. 21. Source Adaptation: BDD in Action Business Goals Features Rules & Examples Executable specifications Low-level specifications Application Code User stories Only build features that align with business goals Features and stories clarified with rules and examples Guide development & testing. Can be read by whole team Features broken down into smaller user stories. Help plan how we deliver a feature Unit tests aimed mostly at developers Automatable with BDD tools like Cucumber, Specflow Unit testing tools like JUnit, NUnit 21 Principle Activities Summarized
  22. 22. Source Adaptation: Raj Indugula & George Dinwiddie Scenario: Invalid example Given I am a new user When I select "Abc1*$!-**" as a password Then I can access my account Scenario: Cash dispensed when machine has no $20 bills Given the ATM is out of $20 bills When a depositor withdraws $50 Then the ATM dispenses 5 $10 bills 22 From Test-last to Test-driven conversations Building the right thing Building the thing right
  23. 23. 23 Being test-driven isn’t really about testing. It’s about specification and design driven through tests