Behavior Driven Development An introduction to automated testing for web developers

Overview ● Testing: Why? and What? ● Test Driven Development ● Behavior Driven Development ○ Acceptance & Unit Tests ○ Cucumber ○ RSpec ● Continuous Testing ● General Tips

What is a test? An assertion about an application, system or object based on defined requirements

What is testing? Building a collection of automated assertions (tests) to describe the software system.

Why do we test? ● Confidence ● Less bugs in production ● Automate tedious, error-prone steps ● Maintainability ● Scalability

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

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/

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?

"Changing the internal design of existing software without affecting external behavior" What is Refactoring?

Refactoring Example: Event has two attendees, "Pete" and "Bob" ASSERT event.all_emails INCLUDES [email protected], [email protected]

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:

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

● 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

Describe What it does vs What it is Specifying behavior leads to better design: ● Simpler interfaces ● Encapsulation ● Loose coupling ● High Cohesion Focus on Behavior

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

Stakeholder Collaboration Requirements + Communication = :) Encourages outside-in development

Acceptance Testing Integration tests + stakeholder collaboration Building the right system vs building the system right. ● Requirements ● Documentation ● Tests

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.

Acceptance + Unit Tests Top down / outside in development

Unit Testing Designing small units of behavior for individual classes. ● Isolate classes while testing ● Simplify interfaces ● Use mock objects (test doubles)

BDD In Use - Tools of the Trade Cucumber - Cross platform, acceptance testing Rspec - Ruby BDD platform, ideal for unit tests Jasmine - JS BDD

Write automated tests for simple or complex systems in plain english (Gherkin) Expands upon Agile user stories Ideal for acceptance testing & stakeholder collaboration

Anatomy of a Cucumber Feature Title + Narrative Background Steps Scenario Steps

Cucumber Step Definitions

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

RSpec - Ruby BDD Framework ● Concise (readable) tests ● Ideal for Unit testing

Rspec Examples

RSpec Tips ● Avoid date/time dependencies ● Avoid testing internal data/state ● Lots of mocks = bad. ● Be consistent! ● Refactor!

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

● 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

Qualities of Successful Tests ● Independence (Isolation) ● Repeatable ● Clarity ● Conciseness

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/

Thanks! Peter Brown @beerlington github.com/beerlington Alan Peabody @alanpeabody github.com/alanpeabody