<ul>
<li>Flows move through a Site’s Pages</li>
<li>Flows help <span class="caps">DRY</span> up test code</li>
<li>Flows can take a hash to pass in values</li>
</ul>
<p>If you had the following code in a whole lot of places in your tests:<pre><code>Google.new do |google|
google.home_page do |home_page|
home_page.search_field.set "ruby ruby ruby"
home_page.search_button.click
end
end</code></pre></p>
<p>Then it would make sense to pull this out into a method, but methods could have multiple intentions. In this case the abstract intention is to move through the Google site. Taza provides the convention of flows. To pull out the above code into a flow perform the following steps(assuming you’ve created a google [[Sites]] already):</p>
<ol>
<li><code>$ ./script/generate flow search google</code></li>
<li>open ./lib/sites/google/flows/search.rb</li>
<li>Do something like <pre><code>module Google
class Google < ::Taza::Site
def search_flow(params={})
home_page.search_field.set params[:query]
home_page.search_button.click
end
end
end</code></pre></li>
<li>Rip out the duplicated code and replace it with the flow call<pre><code>Google.new do |google|
google.search_flow :query => "ruby ruby ruby"
end
</code></pre></li>
</ol>
<h3>Notes</h3>
<p>Flows tend to work best not to hide code or <span class="caps">DRY</span> it up, but rather to express steps of a test which are not important to the actual tests assertion point. For example, if you want to test the Google Search Results page then it is important to know that a search must be performed but not necessarily how it is performed. Sometimes it is best to keep test code moist instead of completely <span class="caps">DRY</span>.</p>
2009-11-26T22:37:25-08:00
85583
flows
59892
Flows
2009-02-26T12:31:30-08:00
58060