kookaburra 2.0.0 → 3.0.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 0096d882dd0e4a30ea2ff6f38744a307ca77b596
-  data.tar.gz: 97dd32061c90235865ed398517c59c356d0b3b38
+  metadata.gz: 40ba91318bee567ced157fa2bd8d51367a88e584
+  data.tar.gz: 6a4c31b072f15bf12fb4802910172a385daab48b
 SHA512:
-  metadata.gz: 2022e2a53bef18d607ada46e5043d2f17c79f4699f4ee02b5d06c4b12c9d219727fee3bb2cee84e55383a35697d2918552a295b49e165d13bc0505a311c59097
-  data.tar.gz: 86883520f7835ebcd750f01448d39727ffa48c9f8c8d564b5b8ca42bd12e17468d6f7ee11aeb958a398f1facf939a09bb108f2c3e7bc6e9e68f67c246664d047
+  metadata.gz: 857eaede49769932c27334a67814fe48a150195085068d33391b5a59b123885bdaa428f4340b85eb40886371dd802dd893410d4ce04f958f829183db747379e8
+  data.tar.gz: a8a53de66691968681c4a8765f2fef89c668ec132fd23ae17e95daf825392a36ae588f692379ca2512e40f9e82a282f0a67a914f34522b87ad7666ebcf894b7c

data/.rspec

@@ -1 +1,2 @@
 --color
+-t ~slow

data/.travis.yml

@@ -3,7 +3,5 @@ before_install:
   - "sh -e /etc/init.d/xvfb start"
 rvm:
   - "2.1.2"
-  - "2.0.0"
-  - "1.9.3"
 env:
-  - "DISPLAY=:99.0"
+  - "DISPLAY=:99.0 CODECLIMATE_REPO_TOKEN=476ff0f469278c42a67f2682736e2522cda104a104e01ba6dbe532e9934de3b1"

data/README.markdown

@@ -1,17 +1,19 @@
 # Kookaburra #
 
-Kookaburra is a framework for implementing the [Window Driver] [Window Driver] pattern in
-order to keep acceptance tests maintainable.
+Kookaburra is a framework for implementing the [Window Driver] [Window Driver]
+pattern in order to keep acceptance tests maintainable.
+
+[![Code Climate](https://codeclimate.com/github/jwilger/kookaburra/badges/gpa.svg)](https://codeclimate.com/github/jwilger/kookaburra)
+[![Test Coverage](https://codeclimate.com/github/jwilger/kookaburra/badges/coverage.svg)](https://codeclimate.com/github/jwilger/kookaburra)
 
 ## Requirements ##
 
-Requires Ruby 1.9.3 or greater. Tested with both MRI and JRuby (note 
-that you must run JRuby in 1.9 compatability mode.)
+Requires Ruby 2.1.0 or greater.
 
 ## Installation ##
 
-Kookaburra is available as a Rubygem and [published on Rubygems.org] [Kookaburra Gem],
-so installation is trivial:
+Kookaburra is available as a Rubygem and
+[published on Rubygems.org] [Kookaburra Gem], so installation is trivial:
 
     gem install kookaburra
 
@@ -24,51 +26,53 @@ following:
 
 ## Setup ##
 
-Kookaburra abstracts some common patterns for implementing the Window Driver
-testing pattern for web applications. You will need to tell Kookaburra which
-classes contain the specific Domain Driver implementations for your application
-as well as which driver to use for running the tests (currently only tested with
-[Capybara] [Capybara]).
-
-Kookaburra is designed to run tests agains a remote web server (although that
-server could be running on the same machine, it doesn't need to be), and it is
-the responsibility of the test implementation to ensure that the server is
-running. 
-
-The fact that Kookaburra runs against a remote server means that *it is not
-limited to testing only Ruby web applications*. As long as your application
-exposes a web-service API for use by the APIDriver and an HTML user interface
-for use by the UIDriver, you can use Kookaburra to test it. Also, as long as
-you're careful with both your application and test designs, you're not limited
-to running your tests only in an isolated testing environment; you could run
-the same test suite you use for development against your staging or production
-systems.
+Kookaburra abstracts some common patterns for implementing the Window
+Driver testing pattern for web applications. You will need to tell
+Kookaburra which classes contain the specific Domain Driver
+implementations for your application as well as which driver to use for
+running the tests (currently only tested with [Capybara] [Capybara]).
+
+Kookaburra is designed to run tests against one or more remote web
+servers (although the server(s) could be running on the same machine, it
+doesn't need to be), and it is the responsibility of the test
+implementation to ensure that the server is running. 
+
+The fact that Kookaburra runs against a remote server means that *it is
+not limited to testing only Ruby web applications*. As long as your
+application exposes a web-service API for use by the APIDriver and an
+HTML user interface for use by the UIDriver, you can use Kookaburra to
+test it. Also, as long as you're careful with both your application and
+test designs, you're not limited to running your tests only in an
+isolated testing environment; you could run the same test suite you use
+for development against your staging or production systems.
 
 ### Testing an Application Running Locally ###
 
-The fact that Kookaburra is designed to support running tests against a remote
-server does not, of course, mean that the application cannot be running locally.
-It is possible to have your test suite manage the process of starting and
-stopping your server for you. Examples of how to do so with a Rack application
-are presented below, but you should be able to take the same basic approach with
-other types of application servers.
-
-Although Capybara is capable of starting a Rack application server on 
-its own, the default setup only starts the server up on-demand when you 
-call a method that requires the browser to interact with the web 
-application. Because the APIClient layer does not use Capybara, it is 
-necessary to manage the server process on your own. Otherwise the server 
-would not be guaranteed to be running when you call the APIClient 
-methods (particularly as these often appear in "Given" statements that 
+The fact that Kookaburra is designed to support running tests against a
+remote server does not, of course, mean that the application cannot be
+running locally.  It is possible to have your test suite manage the
+process of starting and stopping your server(s) for you. Examples of how
+to do so with a Rack application are presented below, but you should be
+able to take the same basic approach with other types of application
+servers.
+
+Although Capybara is capable of starting a Rack application server on
+its own, the default setup only starts the server up on-demand when you
+call a method that requires the browser to interact with the web
+application. Because the APIClient layer does not use Capybara, it is
+necessary to manage the server process on your own. Otherwise the server
+would not be guaranteed to be running when you call the APIClient
+methods (particularly as these often appear in "Given" statements that
 are run before you start interacting with the web browser.)
 
-Keep in mind that, even if your server is capable of being started up in another
-thread within the same Ruby process that is executing your test suite, you will
-want to avoid doing so unless you are using a Ruby interpreter that supports
-native threads. Otherwise, when the APIClient makes an HTTP call to your
-application's API, it will block while waiting for a response, thus preventing
-your application from being able to respond to that request and resulting in a
-timeout error in your tests.
+**Keep in mind that, even if your server is capable of being started up in
+another thread within the same Ruby process that is executing your test
+suite, you will want to avoid doing so unless you are using a Ruby
+interpreter that supports native threads. Otherwise, when the APIClient
+makes an HTTP call to your application's API, it will block while
+waiting for a response, thus preventing your application from being able
+to respond to that request and resulting in a timeout error in your
+tests.**
 
 ### RSpec ###
 
@@ -106,13 +110,46 @@ add the following to `spec/support/kookaburra_setup.rb`:
       c.include(Kookaburra::TestHelpers, :type => :request)
     end
 
+#### Testing Multiple Applications
+
+Sometimes you need to test a business process that spans multiple
+"applications" in your platform. Kookaburra can be configured to operate
+against multiple remote applications by defining them in the
+configuration block as follows:
+
+    Kookaburra.configure do |c|
+      c.application(:app_one) do |a|
+        a.api_driver_class = AppOne::APIDriver
+        a.ui_driver_class = AppOne::UIDriver
+        a.app_host = 'http://app_one.example.com:1234'
+      end
+
+      c.application(:app_two) do |a|
+        a.api_driver_class = AppTwo::APIDriver
+        a.ui_driver_class = AppTwo::UIDriver
+        a.app_host = 'http://app_two.example.com:1234'
+      end
+
+      c.browser = Capybara::Session.new(:selenium)
+      c.server_error_detection { |browser|
+        browser.has_css?('head title', :text => 'Internal Server Error')
+      }
+    end
+
+This changes the way you use the `#api` and `#ui` test helpers
+(explained below) so that you must qualify each one with the name of the
+application, i.e. `#app_one.api`, and `#app_two.ui`. Configuration
+parameters set on the base configuration (e.g. `c.browser = #...`) are
+shared between all named applications that do not specifically override
+them.
+
 #### Managing startup and shutdown of a Rack application server ####
 
-While developing, it can be helpful to run your integration specs against a
-locally-running server that is managed by your test suite. The setup is similar
-to that in the previous section, but it adds before and after hooks to launch
-and shut down a Rack application server. Just add the following to
-`spec/support/kookaburra_setup.rb`:
+While developing, it can be helpful to run your integration specs
+against a locally-running server that is managed by your test suite. The
+setup is similar to that in the previous section, but it adds before and
+after hooks to launch and shut down a Rack application server. Just add
+the following to `spec/support/kookaburra_setup.rb`:
 
     require 'kookaburra/test_helpers'
     require 'kookaburra/rack_app_server'
@@ -157,14 +194,15 @@ and shut down a Rack application server. Just add the following to
 
 ### Cucumber ###
 
-The following examples depict how you might configure [Cucumber] [Cucumber] to
-run tests against an already running application server (e.g. a remote staging
-site) and a Rack application server that is managed by the test suite.
+The following examples depict how you might configure [Cucumber]
+[Cucumber] to run tests against an already running application server
+(e.g. a remote staging site) and a Rack application server that is
+managed by the test suite.
 
 #### Testing an already running server ####
 
-If you are running your tests against an already running server, you can simply
-add the following to `features/support/kookaburra_setup.rb`:
+If you are running your tests against an already running server, you can
+simply add the following to `features/support/kookaburra_setup.rb`:
 
     require 'kookaburra/test_helpers'
 
@@ -187,13 +225,46 @@ add the following to `features/support/kookaburra_setup.rb`:
 
     World(Kookaburra::TestHelpers)
 
+#### Testing Multiple Applications
+
+Sometimes you need to test a business process that spans multiple
+"applications" in your platform. Kookaburra can be configured to operate
+against multiple remote applications by defining them in the
+configuration block as follows:
+
+    Kookaburra.configure do |c|
+      c.application(:app_one) do |a|
+        a.api_driver_class = AppOne::APIDriver
+        a.ui_driver_class = AppOne::UIDriver
+        a.app_host = 'http://app_one.example.com:1234'
+      end
+
+      c.application(:app_two) do |a|
+        a.api_driver_class = AppTwo::APIDriver
+        a.ui_driver_class = AppTwo::UIDriver
+        a.app_host = 'http://app_two.example.com:1234'
+      end
+
+      c.browser = Capybara::Session.new(:selenium)
+      c.server_error_detection { |browser|
+        browser.has_css?('head title', :text => 'Internal Server Error')
+      }
+    end
+
+This changes the way you use the `#api` and `#ui` test helpers
+(explained below) so that you must qualify each one with the name of the
+application, i.e. `#app_one.api`, and `#app_two.ui`. Configuration
+parameters set on the base configuration (e.g. `c.browser = #...`) are
+shared between all named applications that do not specifically override
+them.
+
 #### Managing startup and shutdown of a Rack application server ####
 
-While developing, it can be helpful to run your acceptance tests against a
-locally-running server that is managed by your test suite. The setup is similar
-to that in the previous section, but it adds before and after hooks to launch
-and shut down a Rack application server. Just add the following to
-`features/support/kookaburra_setup.rb`:
+While developing, it can be helpful to run your acceptance tests against
+a locally-running server that is managed by your test suite. The setup
+is similar to that in the previous section, but it adds before and after
+hooks to launch and shut down a Rack application server. Just add the
+following to `features/support/kookaburra_setup.rb`:
 
     require 'kookaburra/test_helpers'
     require 'kookaburra/rack_app_server'
@@ -234,10 +305,10 @@ and shut down a Rack application server. Just add the following to
 
 ## Defining Your Testing DSL ##
 
-Kookaburra extracts some common patterns that make it easier to use the Window
-Driver pattern along with various Ruby testing frameworks, but you still need to
-define your own testing DSL. An acceptance testing stack using Kookaburra has
-the following layers:
+Kookaburra extracts some common patterns that make it easier to use the
+Window Driver pattern along with various Ruby testing frameworks, but
+you still need to define your own testing DSL. An acceptance testing
+stack using Kookaburra has the following layers:
 
 1. The **Business Specification Language** (Cucumber scenarios or other
    spcification documents)
@@ -249,12 +320,12 @@ the following layers:
 
 ### The Business Specification Language ###
 
-The business specification language consists of the highest-level descriptions
-of a feature that are suitable for sharing with the non/less-technical
-stakeholders on a project.
+The business specification language consists of the highest-level
+descriptions of a feature that are suitable for sharing with the
+non/less-technical stakeholders on a project.
 
-Gherkin is the external DSL used by Cucumber for this purpose, and you might
-have the following scenario defined for an e-commerce application:
+Gherkin is the external DSL used by Cucumber for this purpose, and you
+might have the following scenario defined for an e-commerce application:
 
     # purchase_items_in_cart.feature
 
@@ -274,40 +345,38 @@ have the following scenario defined for an e-commerce application:
         And I see that my default payment options will be used
         And I see that my default shipping options will be used
 
-Note that the scenario is focused on business concepts versus interface details,
-i.e. you "choose to check out" rather than "click on the checkout button". If
-for some reason your e-commerce system was going to be a terminal application
-rather than a web application, you would not need to change this scenario at
-all, because the actual business concepts described would not change (and
-although Kookaburra's focus is on testing web applications, it could likely be
-adapted to other environments.)
+Note that the scenario is focused on business concepts versus interface
+details, i.e. you "choose to check out" rather than "click on the
+checkout button". If for some reason your e-commerce system was going to
+be a terminal application rather than a web application, you would not
+need to change this scenario at all, because the actual business
+concepts described would not change (and although Kookaburra's focus is
+on testing web applications, it could likely be adapted to other
+environments.)
 
 ### The Test Implementation ###
 
 The Test Implementation layer exists as the line in between the Business
-Specification Language and the Domain Driver, and it includes Cucumber step
-definitions, RSpec example blocks, Test::Unit tests, etc. At this layer, your
-code orchestrates calls into the Domain Driver to mimic user interactions under
-various conditions and make assertions about the results.
-
-**Test assertions always belong within the test implementation layer.** Some
-testing frameworks such as RSpec add methods like `#should` to `Object`, which
-has the effect of poisoning the entire Ruby namespace with these methods---if
-you are using RSpec, you can call `#should` anywhere in your code and it will
-work when RSpec is loaded. Do not be tempted to call a testing library's Object
-decorators anywhere outside of your test implementation (such as within
-`UIDriver` or `UIComponent` subclasses.) Doing so will tightly couple your
-Domain Driver and/or Window Driver implementation to a specific testing library.
-
-`Kookaburra::UIDriver::UIComponent` provides an `#assert` method for use inside
-your own UIComponents. This method exists to verify preconditions and provide
-more informative error messages; it is not intended to be used for test
-verifications.
-
-`Kookaburra::TestHelpers` provides a convenient way to make assertions about the
-mental model.  If you are using Test::Unit, see
-`Kookaburra::TestHelpers#assert_mental_model_of`; for RSpec, see
-`Kookaburra::TestHelpers#match_mental_model_of`.
+Specification Language and the Domain Driver, and it includes Cucumber
+step definitions, RSpec example blocks, Test::Unit tests, etc. At this
+layer, your code orchestrates calls into the Domain Driver to mimic user
+interactions under various conditions and make assertions about the
+results.
+
+**Test assertions always belong within the test implementation layer.**
+Some testing frameworks such as RSpec add methods like `#should` to
+`Object`, which has the effect of poisoning the entire Ruby namespace
+with these methods---if you are using RSpec, you can call `#should`
+anywhere in your code and it will work when RSpec is loaded. Do not be
+tempted to call a testing library's Object decorators anywhere outside
+of your test implementation (such as within `UIDriver` or `UIComponent`
+subclasses.) Doing so will tightly couple your Domain Driver and/or
+Window Driver implementation to a specific testing library.
+
+`Kookaburra::UIDriver::UIComponent` provides an `#assert` method for use
+inside your own UIComponents. This method exists to verify preconditions
+and provide more informative error messages; it is not intended to be
+used for test verifications.
 
 Given the Cucumber scenario above, here is how the test implementation layer
 might look:
@@ -343,24 +412,26 @@ might look:
     end
 
     Then "I see that my default payment options will be used" do
-      ui.order_summary.payment_options.should match_mental_model_of(:default_payment_options)
-      # Or if you prefer Test::Unit style assertions...
-      # assert_mental_model_matches(:default_payment_options, ui.order_summary.payment_options)
+      expect(ui.order_summary.payment_options).to \
+        eq get_data(:payment_optons)[:default]
     end
 
     Then "I see that my default shipping options will be used" do
-      ui.order_summary.shipping_options.should match_mental_model_of(:default_shipping_options)
+      expect(ui.order_summary.shipping_options).to \
+        eq get_data(:shipping_options)[:default]
     end
 
 The step definitions contain neither explicitly shared state (instance
-variables) nor any logic branches; they are simply wrappers around calls into
-the Domain Driver layer. There are a couple of advantages to this approach.
+variables) nor any logic branches; they are simply wrappers around calls
+into the Domain Driver layer. There are a couple of advantages to this
+approach.
 
-First, because step definitions are so simple, it isn't necessary to force *Very
-Specific Wording* on the business analyst/product owner who is writing the
-specs. For instance, if she writes "I see a summary of my order" in another
-scenario, it's not a big deal to have the following in your step definitions (as
-long as the author of the spec confirms that they really mean the same thing):
+First, because step definitions are so simple, it isn't necessary to
+force *Very Specific Wording* on the business analyst/product owner who
+is writing the specs. For instance, if she writes "I see a summary of my
+order" in another scenario, it's not a big deal to have the following in
+your step definitions (as long as the author of the spec confirms that
+they really mean the same thing):
 
     Then "I see my order summary" do
       ui.order_summary.should be_visible
@@ -370,18 +441,18 @@ long as the author of the spec confirms that they really mean the same thing):
       ui.order_summary.should be_visible
     end
 
-The step definitions are nothing more than a natural language reference to an
-action in the Domain Driver; there is no overwhelming maintenance cost to the
-slight duplication, and it opens up the capacity for more readable Gherkin
-specs. The fewer false road blocks you put between your product owner and a
-written specification, the easier it becomes to ensure her participation in this
-process.
+The step definitions are nothing more than a natural language reference
+to an action in the Domain Driver; there is no overwhelming maintenance
+cost to the slight duplication, and it opens up the capacity for more
+readable Gherkin specs. The fewer false road blocks you put between your
+product owner and a written specification, the easier it becomes to
+ensure her participation in this process.
 
-The second advantage is that by pushing all of the complexity down into the
-Domain Driver, it's now trivial to reuse the exact same code in
-developer-centric integration tests. This ensures you have parity between the
-way the automated acceptance tests run and any additional testing that the
-development team needs to add in.
+The second advantage is that by pushing all of the complexity down into
+the Domain Driver, it's now trivial to reuse the exact same code in
+developer-centric integration tests. This ensures you have parity
+between the way the automated acceptance tests run and any additional
+testing that the development team needs to add in.
 
 Using RSpec, the test implementation would be as follows:
 
@@ -390,52 +461,58 @@ Using RSpec, the test implementation would be as follows:
     describe "Purchase Items in Cart" do
       example "Using Existing Billing and Shipping Information" do
         api.existing_account(:my_account)
-        api.default_payment_options_specified_for(:my_account)
-        api.default_shipping_options_specified_for(:my_account)
-        api.an_item_in_my_shopping_cart(:my_account)
+        api.default_payment_options_specified
+        api.default_shipping_options_specified
+        api.an_item_in_my_shopping_cart
 
-        ui.sign_in(:my_account)
+        ui.sign_in
         ui.choose_to_check_out
 
-        ui.order_summary.should be_visible
-        ui.order_summary.payment_options.should == k.get_data(:default_payment_options)[:my_account]
-        ui.order_summary.shipping_options.should == k.get_data(:default_shipping_options)[:my_account]
+        expect(ui.order_summary).to be_visible
+        expect(ui.order_summary.payment_options).to \
+          eq get_data(:payment_optons)[:default]
+
+        expect(ui.order_summary.shipping_options).to \
+          eq get_data(:shipping_options)[:default]
       end
     end
 
 ### The Domain Driver ###
 
-The Domain Driver layer is where you build up an internal DSL that describes the
-business concepts of your application at a fairly high level. It consists of two
-top-level drivers: the `APIDriver` (available via `#api`) used to set up
-state for your tests and the UIDriver (available via `#ui`) for describing the
-tasks that a user can accomplish with the application.
+The Domain Driver layer is where you build up an internal DSL that
+describes the business concepts of your application at a fairly high
+level. It consists of two top-level drivers: the `APIDriver` (available
+via `#api`) used to set up state for your tests and the UIDriver
+(available via `#ui`) for describing the tasks that a user can
+accomplish with the application.
 
 #### Mental Model ####
 
-`Kookaburra::MentalModel` is the component via which the `APIDriver` and the
-`UIDriver` share information, and it is intended to represent your application
-user's mental picture of the data they are working with. For instance, if you
-create a user account via the `APIDriver`, you would store the login
-credentials for that account in the `MentalModel` instance, so the `UIDriver`
-knows what to use when you tell it to `#sign_in`. This is what allows the
-Cucumber step definitions to remain free from explicitly shared state.
-
-Kookaburra automatically configures your `APIDriver` and your `UIDriver` to
-share a `MentalModel` instance, which is available to both of them via their
-`#mental_model` method.
-
-The `MentalModel` instance will return a `MentalModel::Collection` for any method
-called on the object. The `MentalModel::Collection` object behaves like a `Hash`
-for the most part; however, it will raise a `Kookaburra::UnknownKeyError` if you
-try to access a key that has not yet been assigned a value.
-
-Deletions (via `#delete` or `#delete_if`) will actually remove the key/value
-pair from the collection, but add it to a sub-collection (available at
-`MentalModel::Collection#deleted`). This reflects the fact that the user's
-mental model of the dataset would also include any intentional exceptions -
-the user will, for example, want to verify that an item they deleted does
-not appear to be available in the system.
+`Kookaburra::MentalModel` is the component via which the `APIDriver` and
+the `UIDriver` share information, and it is intended to represent your
+application user's mental picture of the data they are working with. For
+instance, if you create a user account via the `APIDriver`, you would
+store the login credentials for that account in the `MentalModel`
+instance, so the `UIDriver` knows what to use when you tell it to
+`#sign_in`. This is what allows the Cucumber step definitions to remain
+free from explicitly shared state.
+
+Kookaburra automatically configures your `APIDriver` and your `UIDriver`
+to share a `MentalModel` instance, which is available to both of them
+via their `#mental_model` method.
+
+The `MentalModel` instance will return a `MentalModel::Collection` for
+any method called on the object. The `MentalModel::Collection` object
+behaves like a `Hash` for the most part; however, it will raise a
+`Kookaburra::UnknownKeyError` if you try to access a key that has not
+yet been assigned a value.
+
+Deletions (via `#delete` or `#delete_if`) will actually remove the
+key/value pair from the collection, but add it to a sub-collection
+(available at `MentalModel::Collection#deleted`). This reflects the fact
+that the user's mental model of the dataset would also include any
+intentional exceptions - the user will, for example, want to verify that
+an item they deleted does not appear to be available in the system.
 
 Here's an example of MentalModel behavior:
 
@@ -461,11 +538,11 @@ Here's an example of MentalModel behavior:
 
 #### API Driver ####
 
-The `Kookaburra::APIDriver` is used to create a particular "preexisting" state
-within your application's data and ensure you have a handle to that data (when
-needed) prior to interacting with the UI. You will create a subclass of
-`Kookaburra::APIDriver` in which you will create part of the Domain Driver DSL
-for your application:
+The `Kookaburra::APIDriver` is used to create a particular "preexisting"
+state within your application's data and ensure you have a handle to
+that data (when needed) prior to interacting with the UI. You will
+create a subclass of `Kookaburra::APIDriver` in which you will create
+part of the Domain Driver DSL for your application:
 
     # lib/my_app/kookaburra/api_driver.rb
 
@@ -521,9 +598,9 @@ paths.
 #### UI Driver ####
 
 `Kookaburra::UIDriver` provides the necessary tools for driving your
-application's user interface with the Window Driver pattern. You will subclass
-`Kookaburra::UIDriver` for your application and implement your testing DSL
-within your subclass:
+application's user interface with the Window Driver pattern. You will
+subclass `Kookaburra::UIDriver` for your application and implement your
+testing DSL within your subclass:
 
     # lib/my_app/kookaburra/ui_driver.rb
 
@@ -541,15 +618,16 @@ within your subclass:
 
 ### The Window Driver Layer ###
 
-While your `APIDriver` and `UIDriver` provide a DSL that represents actions
-your users can perform in your application, the [Window Driver] [Window Driver]
-layer describes the individual user interface components that the user interacts
-with to perform these tasks. By describing each interface component using an OOP
-approach, it is much easier to maintain your acceptance/integration tests,
-because the implementation details of each component are captured in a single
-place. For example, if/when the implementation of your application's sign in
-screen changes, you can fix every single test that needs to log a user into the
-system just by updating the `SignInScreen` class.
+While your `APIDriver` and `UIDriver` provide a DSL that represents
+actions your users can perform in your application, the
+[Window Driver] [Window Driver] layer describes the individual user
+interface components that the user interacts with to perform these
+tasks. By describing each interface component using an OOP approach, it
+is much easier to maintain your acceptance/integration tests, because
+the implementation details of each component are captured in a single
+place. For example, if/when the implementation of your application's
+sign in screen changes, you can fix every single test that needs to log
+a user into the system just by updating the `SignInScreen` class.
 
 You describe the various user interface components by sub-classing
 `Kookaburra::UIDriver::UIComponent`:
@@ -603,11 +681,12 @@ whatever is passed to `Kookaburra.new` as the `:browser` option.
 Presently, we have only used Capybara as the application driver for
 Kookaburra.
 
-It's possible that something other than Capybara could be passed in, as long as
-that something presented the same API. In reality, using something other than
-Capybara is likely to require some changes to Kookaburra itself. If you have a
-particular interest in making this work, please feel free to fork the project
-and send us a [GitHub pull request] [Pull Request] with your changes.
+It's possible that something other than Capybara could be passed in, as
+long as that something presented the same API. In reality, using
+something other than Capybara is likely to require some changes to
+Kookaburra itself. If you have a particular interest in making this
+work, please feel free to fork the project and send us a [GitHub pull
+request] [Pull Request] with your changes.
 
 ## Contributing to kookaburra ##
  
@@ -627,8 +706,7 @@ and send us a [GitHub pull request] [Pull Request] with your changes.
 
 ## Copyright ##
 
-Copyright © 2011 John Wilger. See LICENSE.txt for
-further details.
+Copyright © 2011 John Wilger. See LICENSE.txt for further details.
 
 [Window Driver]: http://martinfowler.com/eaaDev/WindowDriver.html "Window Driver - Martin Fowler"
 [Kookaburra Gem]: https://rubygems.org/gems/kookaburra "kookaburra | RubyGems.org | your community gem host"