What is the Behat Framework and the Repository design pattern?

In this research journal entry I want to cover two separate topics: The Behat automated testing framework and the repository design pattern.

Behat

behat.png

(Pirrotta, 2015)

In the last few two weeks I have posted research journal entries about automated testing tools both open source and proprietary in preparation for my research and experimentation subproject I will perform for my PRJ701 project to identify a suitable automated testing tool for use in the Koha project. One automated testing tool which was not outlined in the articles I discussed in my research journal entries was Behat.

This article sums up the benefits of Behat nicely comparing it against another automated testing tool, Selenium: https://webservices.uchicago.edu/learningcenter/article/a_n_introduction_to_automated_testing_with_behat/

I first heard about Behat at Catalyst IT (my work in Wellington) because it was being used in the Mahara team (Mahara is an e-Learning platform where users can create a portfolio outlining their learning and achievements) for user interface testing.

A developer in the Mahara team named Rebecca kindly showed me the high level test plans for Behat and they looked like simple English which I first learnt about in SDV501; the test plans are actually written in a syntax called Gherkin and they are easy to write and understand even for people with limited programming experience.

Here’s an example of a high level Behat test plan (also known as Gherkin spec) written in Gherkin from the Behat website. It isn’t what is run when the Behat automated testing tool performs the test instead it can be likened to a use case of a requested function, in this case the terminal command ‘ls’:

Feature: ls
  In order to see the directory structure
  As a UNIX user
  I need to be able to list the current directory's contents

  Scenario: List 2 files in a directory
    Given I am in a directory "test"
    And I have a file named "foo"
    And I have a file named "bar"
    When I run "ls"
    Then I should get:
      """
      bar
      foo
      """

(“Quick Intro to Behat — Behat 2.5.3 documentation,” n.d.).

As you can see it is outlining:

  • The title which in this case is the ‘ls’ feature.
  • The story – This is outlining the reason for having the feature and it needs to be written in a very particular way: In order……As a…..I need to…. The functionality for the ‘I need to’ in this case listing the contents of the current directory is what this feature provides
  • Scenario – This is what the successful outcome of the feature should do, in this case it is listing 2 files in the directory
  • Steps – These are written in first person and they are steps written in a particular way:
  1. Given….. (this is the background actions taken to set up the scenario, which in this case is creating and navigating into a folder named ‘test’ in which you have previously created only two files named foo and bar)
  2. When…… (this is where the feature is being run, so in this case it is running the command ‘ls’)
  3. Then….. (this is the expected outcome of the test in order for it to be considered successful, in this case it is the displaying of foo bar)

Now something I found interesting in the aforementioned article is that it states the benefit of Behat is that it facilitates the Behavior-Driven Development methodology (which I first covered in the research journal entry named ‘What open source automated testing tools are available’ last week). This is because you can take the domain specific terminology of the clients problem domain and that will form the Ubiquitous Language (U.L.) of the project which makes the communication between the client and the developers easier and more consistent.

After writing up the Gherkin Specs in Gherkin which is flexible enough that it can contain UL, then the next thing to do is write step definitions which are what the automated testing actually runs, they contain calls to the functions in the systems code handing in parameters and testing the outputted value (see the below example, note it is not for the ls example above).

/**
     * @Given the recommendation phase is open
     */
    public function theRecommendationPhaseIsOpen()
    {
        $open = new DateTime("-1 week");
        $close = new DateTime("+2 months");
        $this->setPhase("RecommendationActual", $open, $close);

        expect($this->app->isOpen('RecommendationActual'))->toBe(true);
    }

    /**
     * @When I (try to) access the recommendation form
     */
    public function iAccessTheRecommendationForm()
    {
        $this->visitPath(sprintf('/recommender/index.php?key=%s', $this->accessKey));
    }

    /**
     * @Then I should see the recommendation form
     */
    public function iShouldSeeTheRecommendationForm()
    {
        $this->assertSession()->elementExists('css', "div.content h3:contains('Recommendation Form')");
        $this->assertSession()->elementExists('xpath', '//form[starts-with(@action, "recommendation.php")]');
    }

(McElwain, 2015)

Even the step definitions can contain the UL by making the function names reflect the UL terms for example in the step definition example above (an example from the previously mentioned article) the functions name is: iShouldSeeTheRecommendationForm() (McElwain, 2015).

Which is clearly reflecting the problem domain and is not an arbitrary function name like CheckForm().

I found a very interesting comment in this article was that it said by using UL in the step definitions rather than technical terms for U.I. elements it made the automated tests more stable because unlike with Selenium where you refer to elements by technical terms such as buttons which can move around as other developers make U.I. (User Interface) changes which can cause Selenium to fail because it cannot find the button in the specified location, with Behat you run the test on generic UL terms which makes the tests more stable and flexible when there are U.I. changes (McElwain, 2015).

I definitely believe this because it is what I heard from my team’s technical lead Chris who said that they had tried using Selenium in Koha before but it was very unstable partially because any U.I. changes can cause the tests to fail, so I will be interested to have a go experimenting with Behat on some of the Koha patches to see how it is more flexible by integrating UL terms into the tests.

 

Repository Design Pattern

The second topic I want to cover is Repository Design Patterns. In my research journal entry (‘Good software design: What is a design pattern’) I covered design patterns we needed to learn about for our SDV701 exam last term, since then I have learned about another design pattern called the Repository Design Pattern whilst doing my WEB701 project 2 assignment (the development of a laravel app and integrating in search functionality using ElasticSearch).

So let me start by defining what Laravel is, it is a PHP MVC framework. MVC stands for Model-View-Controller and it is a coding framework you follow to separate out the concerns of the U.I., system logic and data objects. Using Laravel to develop web apps you can reduce the coupling between the controller and the model by introducing a repository as you can see in the below diagram.

repository_pattern.png

(Pasic, 2015)

The repository means the controllers (shown as business logic in the above diagram) can get data from the model (shown as Data source in the diagram) via the repository which acts as the intermediary.

As this article (https://bosnadev.com/2015/03/07/using-repository-pattern-in-laravel-5/) outlines the benefits of the repository design pattern which in essence are:

By separating the controller and the model there is greater ability to test and maintain the model and controller, because you have lowered the coupling and having low coupling and high cohesion is always a important to achieve in programming (Pasic, 2015)

So in this weeks research journal entry I have covered what Behat is including its point of difference which is the Gherkin syntax which lets the users  integrate the UL of the problem domain into the Gherkin specs and step definitions, and what the repository design pattern which was unknown to me until a few days ago.

Bibliography:

Quick Intro to Behat — Behat 2.5.3 documentation. (n.d.). Retrieved June 5, 2017, from http://docs.behat.org/en/v2.5/quick_intro.html

McElwain, G. (2015, October 19). An Introduction to Automated Testing with Behat | Web Services. Retrieved June 5, 2017, from https://webservices.uchicago.edu/learningcenter/article/a_n_introduction_to_automated_testing_with_behat/

Pasic, M. (2015, March 7). Using Repository Pattern in Laravel 5 – Bosnadev – Code Factory. Retrieved June 2, 2017, from https://bosnadev.com/2015/03/07/using-repository-pattern-in-laravel-5/

Pirrotta, G. (2015, February 17). Behat-Gherkin/Mink: One Translator to Rule Them All – Giovanni Pirrotta. Retrieved June 5, 2017, from http://giovanni.pirrotta.it/blog/2015/02/17/behat-gherkin-mink-one-translator-to-rule-them-all/