Your SlideShare is downloading. ×
  • Like
Efficient Rails Test-Driven Development - Week 6
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Efficient Rails Test-Driven Development - Week 6

  • 1,616 views
Published

Learn how to apply the test-first approach to all of your Rails projects. In this six class series, experienced Rails engineer and consultant, Wolfram Arnold applies his real-world perspective to …

Learn how to apply the test-first approach to all of your Rails projects. In this six class series, experienced Rails engineer and consultant, Wolfram Arnold applies his real-world perspective to teaching you effective patterns for testing.

In this sixth of six classes, Wolf discusses:
- Integration frameworks (Cucumber, Webrat, Capybara, and Selenium)
- Integration testing with Selenium (advantages and problems)
- Page Objects
- Locators (Selenium, CSS and XPath locators
- RSpec Custom Matchers
- Testing for Access Control

** You can get the slides and source code from this presentation at: http://marakana.com/f/215 **

Find more videos, tutorials, and code examples at http://marakana.com/techtv

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,616
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
55
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Efficient Rails Test-Driven Development — Week 6 Wolfram Arnold www.rubyfocus.biz In collaboration with:Sarah Allen, BlazingCloud.net marakana.com
  • 2. Integration FrameworksCucumber, Webrat, Capybara,... lightweight browser without JS fast easy to set up great for API testing useful for exploratory application testing
  • 3. Integration FrameworksSelenium drives a browser (Firefox, IE, Safari, Chrome...) slow many moving pieces many technology choices great if client/server testing is a must useful for exploratory application testing
  • 4. Selenium
  • 5. Console Experimentsirb> require support/boot> Page.start_new_browser_session> ...> Homepage.visit> Page.selenium_driver.try_something_here> ...> Page.close_current_browser_session
  • 6. Procedural Selenium Testpage.openpage.type “username”, “joe”page.type “password”, “secret password”page.click “submit”, :wait_for => :pagepage.text?(“My HomePage”).should be_truepage.click “link=New Messages”...
  • 7. Problems with this● Very low level – hard to see whats being checked – hard to reuse – prone to copy & paste● Next step – pull out common methods – but common file quickly gets cluttered – most tests only use a small fraction of common methods
  • 8. Page Objects
  • 9. Page ObjectsEach Page represented by an ObjectMethods are – things you can do – things you can see – apply to this page onlyEach method returns a page object – itself – another page object
  • 10. Advantages● Reuse is easy● Documentation● Maintainability – Changes to the UI or page require only one change of the test code, in only one place● Method Chaining – Development of new tests is easy and fast – Easy reuse of existing “library of things to do” on a page
  • 11. How to build Page Objects?Model the UI in Page Objects entire pages parts of a page
  • 12. Locators
  • 13. LocatorsSelenium Locators “link=Sign in” “username”CSS Locators “css=ul.global_nav_list li” “css=input[name=username]”XPath Locators “xpath=//ul[@class=global_nav_list]/li” “xpath=//input[@name=username]”
  • 14. Selenium Locators—Default“identifier” matches: identifier keywordid attribute is optional element(“identifier=navigation”) This is the default finds: <div id=”navigation”> locatorname attribute element(“identifier=username”) finds: <input name=”username”>Note: matches id first, if not found, looks for name attribute
  • 15. Other Selenium LoctorsExplicit “id” locator: matches id attribute element(“id=navigation”) finds: <div id=”navigation”>Explicit “name” locator: matches name attribute element(“name=username”) finds: <input name=”username”>
  • 16. More on name locatorThe “name” locator may be followed by filters: element(“name=usename value=Joe”) Supported filters: value=value pattern index=element index, starting at 0
  • 17. Link LocatorsThe “link” locator is used for links: element(“link=Sign in”) matches the text (pattern) of an a tag: <a href=”...”>Sign in</a>
  • 18. Select from Drop-Downselect(selectLocator, optionLocator)optionLocator matches on label by defaultExample:select(“name=language”,”French”)
  • 19. Text Verificationglob:pattern Similar to filename matching no command line: * matches any sequence of characters ? matches any single characterregexp:pattern match against a regular expressionregexpi:pattern match against a regular expression, case-insensitiveexact:string exact match
  • 20. String matching examples“Welcome John Smith” glob:Welcome* regexp:Welcome.* regexpi:welcome.* exact:Welcome John SmithIf nothing is specified, glob is the default.
  • 21. CSS Locatorscss=a selects <a> tagcss=a.some_class selects <a class=”some_class”>css=a#some_id selects <a id=”some_id”>css=a.some_class#some_id selects <a id=”some_id” class=”some_class”>
  • 22. CSS Locators: Attributescss=input[name=username] selects <input name=”username”>css=img[src*=”btn_img”] selects <img src=”http://example.com/btn_img?1234>*= partial match^= match beginning$= match end
  • 23. CSS Locators Chainedtag1 tag2 tag1+tag2 decendents siblings css=ul.navlist li a css=input+a <ul class=”navlist”> <input> <li> <a>Some link</a> <a></a> </li> <ul>
  • 24. Waiting Rules
  • 25. When to Wait?An Event Trigger Click Mouse over/out Form SubmitWaiting for: Page load AJAX load JavaScript action (e.g. hide/show)
  • 26. Waiting for Pageopen “/” will automatically wait for pageclicking on a link wait_for :page
  • 27. Wait for ElementUsed for: Ajax, JavaScriptclick “locator”, :wait_for => :element, :element => “locator”
  • 28. Wait for VisibilitySomething appearing or disappearing dynamicallyclick “locator”, :wait_for => :visible, :element => “locator”Note: The element must be present (see wait for element) or visibility check will fail with a “no element found error”
  • 29. RSpec Custom Matchers
  • 30. [1,2,3] == [2,3,1]([1,2,3] – [2,3,1]).should be_empty[1,2,3].should be_commutative_with([2,3,1])http://wiki.github.com/dchelimsky/rspec/custom- matchershttp://railscasts.com/episodes/157-rspec- matchers-macros
  • 31. Testing forAccess Control
  • 32. Access ControlController access Disallowed action should be blocked via before_filters Most important!View access Disallowed pages/actions should not be linked to Purely cosmetic
  • 33. Devisehttp://github.com/plataformatec/deviseLatest in Authorization PluginsComes with controllers and views password recovery feature, etc.Rack-based
  • 34. Test DrivenDevelopment
  • 35. Test-Driven DevelopmentBenefit #1: Better Design Testing as-you-go makes code better structured. Testing emphasizes decoupling. Fat model, skinny controller becomes easier.Benefit #2: Focus & Project Management If you dont know what to test for, how can you know what to code for? Knowing when youre done.
  • 36. Test-Driven DevelopmentBenefit #3: Documentation & Collaboration Tests are documentation thats always current. Tests illustrate how code is meant to be used.Benefit #4: Creation of Tests Testing happens in-situ, not after the fact When youre done coding, youve got a full test suite No tedious chores and guilt afterwards
  • 37. Inside-Out vs. Outside-InStart with what you understand can be model, view or controllerWhen you discover you need something else... make failing tests pending implement what youre missing resumeDiscover the application inside out.