Will you?

Tests are awesome

• But I will do them on new projects

That 'next project' doesn't get tests either...

Lets start with an existing Drupal site

Why should we test existing sites?

WHY *SHOULDN'T WE?

• It will get replaced eventually
  • It won't
• I don't have time
  • Its going to take you more timeto debug this stuff later
• We don't have the budget
  • Its going to cost more later
• I'm lazy
  • You'll feel even lazier retreading old stuff

I don't know where to start...

And that's ok

Start small

Start with a new feature request / bug fix

We'll start with Behat

About Behat

• A tool written in PHP for doing BDD testing
  • Lets you write out scenarios to perform on a site
• Think of it like automatically clicking, filling in forms, etc
  • And you can check your site to see if its outputting
    the right information (on screen and in DB)
• Gherkin
  • Underlying test code is php, but tests look like English

What about PHPUnit? And other testing?

• Stop with the bikeshedding on the tool and start somewhere!
• As you write more tests, you'll find other (maybe even more suitable tools)
• Behat is a nice entrypoint since its testing much like I might from a browser

Example File

Feature: Test to make sure the search works correctly

@api
Scenario: Test the search form from the home page
  Given I am on the home page
  When I fill in  the following:
    | search_key | gallery |
  And I click "Search"
  Then I should see "This photo in my gallery"

Another Example File

Feature: Test to make sure the login works correctly

@api
Scenario: Test logging into the site
  Given I am on the home page
  And I click 'Login'
  When I fill in  the following:
    | username | ashok  |
    | password | drupal |
  And I click "Login"
  Then I should see "Congratulations! You are now logged in"

behat.yml

• The main configuration file
• Lets behat know about your codebase (which we want for Drupal goodies)
• Can configure to use a real browser (like Chrome) or a simulated browser
  • Simulated browser is faster but does not 'know' js. Chrome is a real browser so you can do cool things.
  • Or use a combination!

Anatomy of your tests

• composer install
• ./vendor/bin/behat --init
• Test Directory

  • behat.yml*

  • features

    • bootstrap

      • FeatureContext.php

    • test.feature*

• * need to create

behat.yml

• The main configuration file
• Define your 'contexts'
  • Lets your tests know where to find the string that maps to a function

    • 'Given I go to the homepage' => function givenIGoToTheHomepage()

  • Define where to find your drupal codebase
  • The URL to hit  for the given tests
  • How to access chrome, etc
• Use the one in the repo as a starting point

FeatureContext.php

• The main PHP file where you will write out the PHP of your tests.
• Where you will define new steps
  • asserts
  • debugging steps

test.feature

• You will have many of these files
• These contain your tests
• Just like the examples on the previous slides

• Big note: behat is working against a real site
  • It does not clean up
  • Steps you need to take care of eventually
  • Only do this locally or in dev
• Will see if I can provide links to get rid of nodes, users etc.

Three main concepts

• Scenarios
• Background + Scenarios
• Scenario Outlines
• (And tags)

Structuring things

• Have multiple .feature files
• Add tags to them
• Create them for new feature requests
  • Bug fixes
  • Learn to run the tests locally
  • Eventually in some test environment
    • ProboCI, Acquia, Platform, etc

Demo

• Rescue project I was requested to help on
  • Started on Drupal 8.2
  • Needs to be upgraded to Drupal 8.5 (8.6)
  • Upgraded from PHP5.6 to PHP7.*
  • Multiple feature requests
• Main work site
  • Drupal 7
  • Over 10k tests
  • Integrated with CI
• Lets dive in

Will you?

Tests are awesome

And I use them in my project!