Test.Language

• Acceptance tests are executable design specifications. They are also the most imperative-style code in BOP.

• The XP literature understates the profound value of acceptance tests. They hit on all of the core values.

  • Communication
    We really have to understand the customer's business problem in order to capture the specification in code. Writing down the exact steps of a workflow forces a level of precision that is missed in traditional software specifications.

  • Feedback
    We can re-run these specifications to ensure that the application remains up-to-spec.

  • Courage
    The more complete our acceptance tests, the greater our courage to refactor the code.

  • Simplicity
    Traditional specifications immediately deviate from the implementation as development exposes misunderstandings, contradictions, and omissions in the original spec. Acceptance tests, by contrast, must be maintained with the code under test.

• Excerpt from search.btest used in the PetShop demo application:

  test_setup('PetShop');
  home_page();
  search_for('corgi');
  verify_text('Female Puppy Corgi');

  • The call to test_setup() with the argument 'PetShop' is the only line required to set up a test for the PetShop demo application.

  • The home_page() call is also found at the beginning of most tests. This takes the test to the home page for the given application.

  • The remaining lines of code specify the workflow that being tested.

• Subroutines to execute common actions are provided in Bivio::Test::Language::HTTP and include follow_link, verify_text and submit_form among many others.

• Application-specific testing subroutines are declared in their own package. For example, PetShop-specific subroutines are found in PetShop::Test::PetShop. One such example used in this test is the search_for subroutine:

sub search_for {
    my($self, $words) = @_;
    $self->submit_form(search => {
        anon => $words,
    });
    return;
}