Heya! \|°▿▿▿▿°|/ • Claudio Beatrice • @omissis • 7+ years experience in PHP • Founder of the Drupal Italia Association • Worked in Italy, France and Germany
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.
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
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.
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.
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.
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.
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
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.
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.
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.
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() )); } }
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
...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
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
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.
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
omissis
lukestringer90
akitotsukahara
ogiwarat
osatoh
kazue
hschwentner
pluu
jpt_corp_official
hirodragon112
polpielladev
workspace93
paigeccino
addyosmani
maggiecrowley
revolveconf
shpigford
dougneiner
aleyda
caitiem20
zakiwarfel
csswizardry
nonsquared
myddelton