Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Behavior Driven Development

45b75f9f866d240362c0d7fa125025ba?s=47 Peter Brown
January 30, 2012

Behavior Driven Development

An Introduction to Automated Testing for Web Developers

45b75f9f866d240362c0d7fa125025ba?s=128

Peter Brown

January 30, 2012
Tweet

Transcript

  1. Behavior Driven Development An introduction to automated testing for web

    developers
  2. Overview • Testing: Why? and What? • Test Driven Development

    • Behavior Driven Development ◦ Acceptance & Unit Tests ◦ Cucumber ◦ RSpec • Continuous Testing • General Tips
  3. What is a test? An assertion about an application, system

    or object based on defined requirements
  4. What is testing? Building a collection of automated assertions (tests)

    to describe the software system.
  5. Why do we test? • Confidence • Less bugs in

    production • Automate tedious, error-prone steps • Maintainability • Scalability
  6. What should you test? All code you want to have

    confidence in “Every test you write is an expense... Every test you don’t write is a risk” - Kent Beck
  7. What should you NOT test? • Code that is already

    tested ◦ In a framework such as Rails ◦ At a different level (integration testing controllers) • Exploratory code (spikes) • Textual content that will likely change • Poor requirements • External Web Services (FakeWeb) http://rubyrogues.com/what-not-to-test/
  8. Writing tests first to drive design Red, Green, Refactor: 1.

    Write a failing test (Red) 2. Write code to make test pass (Green) 3. Refactor code What is Test Driven Development?
  9. "Changing the internal design of existing software without affecting external

    behavior" What is Refactoring?
  10. Refactoring Example: Event has two attendees, "Pete" and "Bob" ASSERT

    event.all_emails INCLUDES pete@email.com, bob@email.com
  11. def all_emails emails = Array.new event.users.each do |user| emails <<

    user.email end return email end def all_emails event.users.map(&:email) end Refactoring Example:
  12. Why practice TDD? • Shorter feedback cycles • Discover unknowns

    up front • Better design through repetative red, green, refactor cycles • You can't write failing tests with passing code • Existing code can be harder to test
  13. • Focus on behavior rather than testing • Think (behave)

    as the end user • Collaboration betweeen developers and stakeholders • Requirements => Acceptance + Unit Tests • BDD is a mindset as much as a technique Behavior Driven Development 101
  14. Describe What it does vs What it is Specifying behavior

    leads to better design: • Simpler interfaces • Encapsulation • Loose coupling • High Cohesion Focus on Behavior
  15. OOP Terminology Interface - Public methods and properties (API) Encapsulation

    - Hiding object internals (data) Loose Coupling - No or little dependence on other classes High Cohesion - Classes designed around related functions
  16. Stakeholder Collaboration Requirements + Communication = :) Encourages outside-in development

  17. Acceptance Testing Integration tests + stakeholder collaboration Building the right

    system vs building the system right. • Requirements • Documentation • Tests
  18. Acceptance Testing Continued Example: Signing up as a new user

    User Story: As someone without a user account I want to create a new account So that I can sign into the application Acceptance Test: User signs up for account, receives email, and can log into account.
  19. Acceptance + Unit Tests Top down / outside in development

  20. Unit Testing Designing small units of behavior for individual classes.

    • Isolate classes while testing • Simplify interfaces • Use mock objects (test doubles)
  21. BDD In Use - Tools of the Trade Cucumber -

    Cross platform, acceptance testing Rspec - Ruby BDD platform, ideal for unit tests Jasmine - JS BDD
  22. Write automated tests for simple or complex systems in plain

    english (Gherkin) Expands upon Agile user stories Ideal for acceptance testing & stakeholder collaboration
  23. Anatomy of a Cucumber Feature Title + Narrative Background Steps

    Scenario Steps
  24. Cucumber Step Definitions

  25. Cucumber Tips • Use implicit (declarative) steps vs explicit (imperative)

    steps • Avoid sharing state between steps • Changing tests while refactoring may indicate design problems (especially if requirements have not changed) • Refactor! • Think as the end user
  26. RSpec - Ruby BDD Framework • Concise (readable) tests •

    Ideal for Unit testing
  27. Rspec Examples

  28. RSpec Tips • Avoid date/time dependencies • Avoid testing internal

    data/state • Lots of mocks = bad. • Be consistent! • Refactor!
  29. Continuous Testing • Rapid (instant) feedback loops • Validate decisions

    as soon as they are made • Bugs have shorter lifespan • Fail early • Tools: ◦ Guard, Autotest, Watchr ◦ Spork
  30. • Requires practice & discipline • Look for code smells

    ◦ Hard to test code ◦ Refactoring code and tests together • Always start with a failing test • Blame design over tests General Testing Tips
  31. Qualities of Successful Tests • Independence (Isolation) • Repeatable •

    Clarity • Conciseness
  32. Testing Resources • StackExchange: ◦ http://programmers.stackexchange.com/questions/99735/tdd-is-it-just-about-unit-tests ◦ http://programmers.stackexchange.com/questions/tagged/tdd ◦ http://programmers.stackexchange.com/questions/tagged/bdd

    • Books: ◦ http://pragprog.com/categories/design (Everything) • Wikipedia: ◦ http://en.wikipedia.org/wiki/Behavior_Driven_Development ◦ http://en.wikipedia.org/wiki/Test_Driven_Development • Podcasts: ◦ ◦ http://rubyrogues.com/001-rr-testing-practices-and-tools/
  33. Thanks! Peter Brown @beerlington github.com/beerlington Alan Peabody @alanpeabody github.com/alanpeabody