talk: Upping Your (Programming) Game

(this page is http://bit.ly/jta-upping)

I'm giving this talk tonight, at LA Django, hosted by our friends at Wiredrive HQ. Thanks for Marcel and Wiredrive for supporting the Los Angeles tech scene!

Slides are in gdrive: Upping Your (Programming) Game.

There will be cats Lil Bubzilla.

pic credit: Marcel

Speeding up UI Browser tests with Robot Framework

My current AWS demo project is a Cat Voting Booth.  It uses SocketIO/WebSockets, so in addition to server-side unit tests I've built a number of browser-level tests, using Robot Framework.

One feature people don't realize is that Robot can actually be quite speedy. Opening and closing a browser window is very slow, on the order of 1-2 seconds. Depending on the application, this can be done once, saving 1-2 seconds for *every* test!  For my Very Important Cat Voting Booth, this is the case.

Here's the magic bit:

*** Settings ***
Resource          resource.robot
Test Setup        Reset Votes
Suite Setup       Open Browser To Voting Page
Suite Teardown    Close All Browsers

*** Test Cases ***
Valid Page
    Votes Not Available

Register Up Vote
    Vote Up
    Element Text Should Be    vote-count-up    1
    Element Text Should Be    vote-count-down    0

Normally, Robot will open/close a browser on each test.  The above stanza says "Test Setup: Reset Votes", that is, it'll reset my database and *not* open a browser.  The suite-level setup is "Suite Setup: Open Browser", which means Robot will open a browser once and not per test.  Similarly the suite-level teardown closes all the (Robot-created) browsers.

I can run four (admittedly modest) browser-level tests, in a full real browser, in four seconds! This includes going back and forth to my Flask-SocketIO server, interacting with Redis, and other things.  I'm quite happy with this result.

As a heavy Test Driven Development (TDD) guy, with the above speed I can do full browser-level tests as TDD!  I don't have to wait until I absolutely *have* to run UI tests, they can be fast enough for running many times an hour, to give me very fast development feedback.

Full source code here: https://github.com/johntellsall/aws-realtime-metrics

pragmatic Test Driven Development

As a dev, I write mostly unit tests and care about test coverage increasing over time.  My view has shifted recently.

Although web UI tests can be fragile, they present a lot of bang for the buck, coverage-wise.  It turns out they also have a lot of unique business value; that is, if we're testing what our users see, then when we change something we can immediately know that business value is being affected.

- I recommend view-level tests. Django directly supports and advocates this style. They're fast and easy to create like Unit tests, but have direct user-level (thus business-level) value.

- for UI tests, set an ID on everything that you are testing. (Never ever use XPath.)  This makes UI tests more durable and reliable. 

- Kent Beck has been the main proponent of TDD from the very beginning, as part of Extreme Programming. “I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence”

- I really enjoy Brian Okken's entirely pragmatic view on testing:
My reaction to “Is TDD Dead?”  His podcast is in my Top 3: Python Testing

talk: Better Browser Tests with Selenium

Nicer Browser Tests with Selenium presentation

slides as Google doc

me presenting at the Python Meetup on 7/23:

Youtube videos of Python3 and Nicer Browser Tests

Thanks to Esther for putting everything together, Hulu for sponsoring, Philip for helping, and Carl Mullins for the video!

automating web tests with Ghost

Developing reliable software for the web is a challenging proposition. A site's code organization is complex, with libraries interacting with each other in an exponentially expanding number of possibilities.  It's quite easy to make a minor change in one part of the site that breaks another part.

Manual testing isn't an option. If you have a rarely-used but critical part of the site's workflow, like "email me my forgotten password", it would affect users if the functionality breaks. With manual testing you might never know your users are getting a poor experience.

One technique for making reliable web software is using automated tests.  In addition to the lower-level unit tests of code, it's valuable to have a scriptable "browser" that is able to click through your site and check various features.

Install and verify Ghost

Here's how to install and use Ghost, a Python library that emulates a Webkit browser. The browser is comparable to Apple Safari or Google Chrome.  Instructions are for Ubuntu.

sudo apt-get install python-pyside
sudo pip install Ghost.py

Verify that things were installed correctly:

python -c 'from ghost import Ghost'

Example headless web scripting

Here's a sample program.  It loads the Duck Duck Go search page, then types in a search query. It then clicks the submit button, waits for the search results to load, and prints out the HTML of the first result. Finally it captures a snapshot of the page!

#!/usr/bin/python
from ghost import Ghost

ghost = Ghost()
ghost.open('http://duckduckgo.com/') 

ghost.wait_for_selector('input[name=q]')
ghost.fill("#search_form_homepage", {'q': 'beer'})
ghost.fire_on("#search_form_homepage",
              "submit",
              expect_loading=True) 

ghost.wait_for_selector('#r1-0')
result, _resources = ghost.evaluate(
    "document.getElementById('r1-0').innerHTML;")
print result

ghost.capture_to('beer.png')

Here's the above in a Gist for your use: Ghost example with Duck Duck Go

Resources:

• Steven Fruchter's Ghost tutorial
• Ghost.py home page