Behavior Driven Development

An Introduction to Automated Testing for Web Developers

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