Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Drupal 7 Continuous Integration and Testing

omissis
April 13, 2013

Drupal 7 Continuous Integration and Testing

Achieving Continuous Integration with Drupal 7 and testing with PHPUnit and Behat

omissis

April 13, 2013
Tweet

More Decks by omissis

Other Decks in Programming

Transcript

  1. Drupal 7 Continuous
    Integration and Testing
    Smashing Phing and Behat for fun & profit

    View Slide

  2. Heya! \|°▿▿▿▿°|/
    • Claudio Beatrice
    • @omissis
    • 7+ years experience in PHP
    • Founder of the Drupal Italia
    Association
    • Worked in Italy, France and
    Germany

    View Slide

  3. So: D7, CI and Testing
    Yeah! Nowadays it’s
    possible to leverage the
    power of a tool or two to
    get a seamless continuous
    integration process not
    much different to the one
    we’re used to when
    developing with lower-level
    frameworks.

    View Slide

  4. Continuous Integration
    Continuous integration (CI) is the practice, in
    software engineering, of merging all developer
    workspaces with a shared mainline several times a
    day.
    - Wikipedia

    View Slide

  5. Testing History tldr
    BDD
    Combining TDD with Domain-Driven Design
    Unit testing
    Testing code automatically
    TDD
    Writing tests first

    View Slide

  6. Agile Testing Matrix
    by Briack Marick
    Acceptance
    Testing
    Usability
    Testing
    Unit Testing
    Performance
    Testing
    Technology-facing
    Business-facing
    Critique product
    Support
    programming

    View Slide

  7. What is that about?
    Basically, a collection of softwares sporting the ugliest
    set of icons in the known universe!

    View Slide

  8. Jenkins
    Jenkins is a Java application that monitors executions of
    repeated jobs, such as building a software project or jobs
    run by cron.

    View Slide

  9. Jenkins
    In a nutshell, Jenkins provides an easy-to-use so-called
    continuous integration system, making it easier for
    developers to integrate changes to the project, and
    making it easier for users to obtain a fresh build. The
    automated, continuous build increases the productivity.

    View Slide

  10. Phing
    A cross-platform build tool for PHP based on Apache Ant
    It offers a standard, declarative way(XML) of writing
    scripts to handle operations such as packaging,
    deploying and testing web application.
    It features a rich set of tasks for dealing with file system
    operations, SQL executions, code analysis and linting,
    documentation generation and much, much more.

    View Slide

  11. Phing

    View Slide

  12. Drush
    Drush is a command line shell and scripting interface for
    Drupal, a veritable Swiss Army knife designed to make life
    easier for those of us who spend some of our working
    hours hacking away at the command prompt.

    View Slide

  13. PHPUnit
    It’s the de-facto standard unit testing framework for PHP and
    part of the larger xUnit family.
    Its primary goal is to take the smallest piece of testable
    software in the application, isolate it from the rest of the code,
    and determine whether it behaves exactly as you expect.

    View Slide

  14. PHPUnit
    It provides a very useful set of tools for testing code units
    such as:
    • Assertions
    • Fixtures
    • Database testing
    • Mock Objects
    • Code coverage analysis
    • Several kind of logging formats

    View Slide

  15. Behat
    Behat is a tool for writing human-readable tests in the
    form of a story, using a language called Gherkin, that
    describe the behavior of your application.
    By writing stories, it is possible to define acceptance
    criteria that can be actually executed for testing the
    behavior of a web application.

    View Slide

  16. Ambiguity and miscommunication between developers,
    business owners and testers can be greatly reduced.
    Behat
    One vocabulary to rule them all

    View Slide

  17. Behat
    Feature: front page
    In order to access the website
    As an anonymous user
    I need to be able to see the login form
    Every feature comes with a name, followed by three lines
    describing the benefit, the role and the feature itself.
    This section is required but not important to Behat in
    terms of execution, it’s just there for reading purposes.

    View Slide

  18. Behat
    Scenario: Login page shows the correct buttons
    Given I am on “/”
    Then I should not see the link “register”
    And I should see the link “login”
    And I should see the link “forgot password”
    Every scenario describes how a feature acts under
    different conditions and it’s composed by three parts: the
    context, the event and the outcome
    This is the part that will be transformed into a test.

    View Slide

  19. Behat
    /**
    * @Then /^I should not see the link "(?P[^"]*)"$/
    */
    public function iShouldNotSeeTheLink($link) {
    $element = $this->getSession()->getPage();
    $result = $element->findLink($link);
    if ($result) {
    throw new \Exception(sprintf(
    "The link '%s' was present on the page %s and was not
    supposed to be",
    $link,
    $this->getSession()->getCurrentUrl()
    ));
    }
    }

    View Slide

  20. A few more little pieces...
    • Git, for versioning code
    • Drush Phing Task, for integrating Drush commands into
    Phing targets
    • Drupal Behat extension, needed to leverage the power
    of Drush into our Behat features
    • Migrate Module, for importing fixtures and migrating
    data whenever needed
    • Features Module, for exporting configuration into code

    View Slide

  21. ...and files!
    • .gitignore, for not tracking a good bunch of files we
    don’t need
    • drush make, for keeping track of the modules, themes
    and libraries to ues
    • build.xml, for describing all the actions Phing will have
    to take to build the website
    • build.ENV.properties, for storing environments variables
    used during the build process
    • behat.yml.dist, for storing Behat’s configurations

    View Slide

  22. Save the environment(s)!
    • local, the developer’s machine, where everyday work is
    done.
    • dev, a server where the CI actually happens. It gets
    rebuilt from scratch and throughly tested every
    time(ideally after every push on the repository)
    • stage, a server used to deploy “stable” dev snapshots
    at a given point in time, usually for letting the client
    tests on a more stable environment

    View Slide

  23. Save the environment(s)!
    • debug, a copy of the production environment (as
    faithful as possible), used for easily reproducing bugs
    happening on production and also to test deploys.
    • prod, the environment that hosts the final product,
    tuned and optimized for best performances.

    View Slide

  24. Let’s sum up a second
    Jenkins takes those logs and publishes the results
    Jenkins clones the repository and invokes Phing
    Phing performs the build of the website, upload the files
    and the database and finally launches the tests
    PHPUnit and Behat run the tests
    and log the results in JUnit format

    View Slide

  25. Time for some action!
    Go grab the code at
    http://github.com/agavee/drupal7-base

    View Slide

  26. You deserve some moar
    • http://www.slideshare.net/everzet/bdd-in-symfony2/
    • http://www.slideshare.net/headrevision/web-
    acceptance-testing-with-behat/
    • http://www.exampler.com/old-blog/2003/08/21/
    • http://www.phpunit.de/manual/current/en/index.html
    • http://dannorth.net/whats-in-a-story/

    View Slide

  27. Thank you!
    http://silent-voice.org/
    http://agavee.com/
    @omissis

    View Slide