Functional Testing

Functional Testing lets you describe the way a page should behave on a specific site. Each time a new page is generated by running $ ./script/generate page home google then a failing spec for that page is automatically generated. There should be no need to manually intervene to create specs in the ./spec/functional/ folder.

How to write Functional Tests

Everyone seems to disagree on what the word Functional means in the realm of testing, but at least in the realm of Taza functional testing means specifying the behavior for a site. The easiest way to capture this is to describe how each page ought to behave. Instead of focusing on how the entire site might operate think about how a particular page should function. Consider its exit points and actionable items. For instance on a e-commerce site’s shopping cart page you may want to specify that the shipping method drop-down should change the displayed shipping charges. That might look something like

Rake Tasks

Taza provides rake tasks for each part of functional testing. Once you’ve generated a site and a page and perform a $ rake -T you will be given a number of rake tasks whose namespaces reflect the spec folder structure. Given that at least one site and one page are generated the output of $ rake -T would look something like

rake spec:functional                   # Run all functional specs
rake spec:functional:google            # Run all functional specs for google
rake spec:functional:google:home_page  # Run specs
rake spec:integration                  # Run all integration specs
rake spec_tags                         # Run specs
rake test_tags                         # Run tests for test_tags

Isn’t this just view testing?

This may come across as view-based testing, which to some is at least unnecessary and at worst heresy. Unfortunately not every application has the structure and hooks for the lower-level testing that generally makes automated view testing unnecessary.