Behat Driven Development2015/10/3㈱オハコ Ryo Tomidokoro

PHP Conference Tokyo 2015

About me

Ryo Tomidokoro (@hanhan1978)サーバーサイドエンジニア

自動テストにまつわる悲しい過去・・・• 何度も同じ箇所でデグレ。• でも、自動テストを追加する工数が取れないと言われる。• でも、自動テストのやり方がわからないと言われる。• Rspec とか Capybara は Ruby のツールだから分からないと言われる。• バグが起きた時の再発防止策で「頑張る」とか言われる。

Behat

• 私が欲していた全てがここに。• 辛かった過去が報われる時がきた。• この感動と、この感動の理由を共有せねばならない！• 注 ) BDD としては使ってない・・・

About this presentation1. TDD, BDD と自動テスト2. 自動テストの利点3. 自動テスト失敗の体験談4. Behat について5. Behat と現場の相性6. Behat Driven Development

1. TDD, BDD と自動テスト

TDD, BDD

• TDD とは？ BDD とは？ ( 触れるな危険 )• 短いスパンで、テスト＆実装を繰り返す。• TDD は単体、 BDD は受入という捉えられ方が多い• テスト駆動開発と自動テストは分けて考える

自動テスト• PHPUnit, PHPSpec, Behat• アプリケーションをテストするプログラム• CI ツールから実行することで、継続的にアプリケーションテストを実行する• 今日の話のメインターゲットはコッチ。

余談• TDD, BDD は生半可では回らない。• 関与するエンジニア全員が覚悟をもって取り組まないと、絶対に頓挫する。

2. 自動テストの利点

自動テストが効果を持つ場所• デグレがよく起こる箇所の事前検査• ビジネス的に重要な箇所の事前検査• テスト手順が煩雑な箇所の検査• 放置状態の機能の死活監視

個人的に感じるメリット• リリースに自信がでる。 ( よく聞く )• リファクタリングに勇気がでる。 ( よく聞く )• 面接の時言える。• 自動テストは、意識高そう。

自動テストに吹く逆風• テストを作成するコスト、教育にかかるコスト• コストが高い場合は、周囲の理解を得られないことが多い。• テスト書いたことの無いエンジニアの自動テストアレルギーは侮れない。

まとめ• メリットはある。 ( 断言 )• 既存機能の改修と、安定したリリースに確実に貢献する。• コストが高いというイメージはつきまとう。

3. 自動テスト失敗の体験談

ケース 1) テスト作れない

テスト作れない問題• やったことない。• どうやればいいか分からない。• 教育工数が取れない。• 結果的に、日々の作業に追われて業務が改善されない。

テスト作れない理由• そもそも教育工数が取れない組織自体に問題がある。• 自動テストへの心理的ハードルは、結構高い。• 効率の良い運用が出来なくて、時間がなくなっていく負のスパイラル

ケース 2) 自動テストの遺跡

遺跡が生まれる過程• 新規プロジェクトで新しい WAF を採用！• このタイミングで TDD 導入！• メンバーもノリノリ。

【プロジェクト初期】

遺跡が生まれる過程• controller も model もテストできる• DI コンテナ万歳！＼ (^o^)／• よーし、 fixture でテストデータ登録しちゃうぞー

【プロジェクト中期】

遺跡が生まれる過程• 駆け込みで作る機能はテスト無し• いいから動くものを・・・• 外注の部分はごっそりテストがない・・・• 応援メンバーへのテストツール教育が・・・

【プロジェクト後期】

遺跡• アレ、 test が動かない。でもバグ修正は今日。• この「 test 」というディレクトリは何ですか？• そして、誰も触れなくなってくる。

【運用期間】

遺跡が生まれる理由• アプリ全体を網羅しようとする完璧主義• CI不在で、テストが定期的に実行されていない。• CI不在だと、特定個人の環境でしかテストが動かないなどの問題がある• 不完全でも特定環境に依存しない形で CI されないと遺跡化する。

ケース 3) テストの放置

テストは動いている・・・• Jenkins にテスト実行ログとかはグラフででてる。• グラフは綺麗。• テストを実行しているだけ、失敗・成功の通知が ML に飛んでいるが、誰も反応しない。• 最悪、失敗状態でリリースを重ねてたりする。

放置テストの理由• リリースツールは、テスト失敗時はリリース出来ちゃダメ。• 通知が ML だと、他人事にする人が多い。• 自動テスト導入後の運用も含めてトータルに考えないと、あっという間に廃れる

自動テストの成功を阻む要因1. テストツールの教育不足2. 個人依存のテスト実行環境3. 導入後の通知や運用ルールの不備

※ 組織の政治的な理由による場合は○クルートエー○ェントとかに相談してください。

余談• 押し付けても現場に自動テストは浸透しない• 現場における平均レベルのエンジニアが自然と実行できるレベルにまで噛み砕く。• オラっても上手くいかない。 ( 体験談 )

4. Behat について

Behat って何 ?

• BDD テストフレームワーク• Cucumber に inspire された• テストシナリオは Gherkin形式• PHP製 ( ココ大事 )

Behat で出来ること• デフォルト状態では何もない• テスト (feature), アサーション (step) は自分で作る• 一般的には extension を導入して使う

主な extension

• Mink => 汎用 Web アプリ向けテスト拡張• Symfony2• Laravel• CakePHP

実際の Behat テストコード# language: en

Feature: Do Some Sample Testing

Scenario: ls Given I am in the "directory" When I execute "command" Then I should get "file1,file2"

feature ( テストシナリオ )

実際の Behat テストコードstep ( テストコード )<?php/** * Defines application features from the specific context. */class FeatureContext implements Context, SnippetAcceptingContext{ /** * @Given I am in the :arg1 */ public function iAmInThe($arg1) { throw new PendingException(); }}

構成はシンプル.├─ behat.yml└─ features/ ├── bootstrap │   └── FeatureContext.php └── sample.feature•behat の設定ファイル• feature ( テストシナリオ )•step (PHP で記述されたテストコード )

Behat とは ( まとめ )

• Cucumber ライクなテストツール• PHP製で、拡張が簡単

特殊なツールではないし、すごく目新しいわけでもない。ほどよく簡単。

5. Behat と現場の相性

Behat はバランスが良い1. 低コスト ( 時間 )

2. テスト対象を問わない3. 既存のプロジェクトに後付が簡単。4. Composer 利用で CI との相性も良い

1. 低コスト• 拡張を利用した E2E テストは作成コストが低い# language : en

Feature: stock search

Scenario: get stock code Given I am on the homepage When I follow " ファイナンス " When I fill in "searchText" with "九州電力 " When I press "searchButton" Then I should see "9508"(例 ) yahoo ファイナンスで株価検索するテスト [5 分で制作 ]

2. テスト対象は問わない• PHP4 でも、 PHP5.2以下でも・・・• もっと言うなら、 RoR でも Python, Perl のアプリでも。

3. 後付が簡単。• E2E テスト• メソッドの詳細をテストするわけではない。• ブラウザ操作レベルに抽象化出来る。

4. CI との相性• Composer でインストール OK

language: phpphp: - 5.5 - 5.4

before_script: - composer install

script: - vendor/bin/behat(例 ) .travis.yml

6. Behat Driven Dev

ここで 5 分余ってないとやばい

自動テストの成功を阻む要因1. テストツールの教育不足2. 個人依存のテスト実行環境3. 導入後の通知や運用ルールの不備

おさらい

1. テストツールの教育• PHP製という強み• Qiita や、後述の参考資料の内容を 1 時間程度やれば、十分把握可能• E2E テスト前提であれば、 Mink拡張を利用するだけなので、 PHP のコードは一行も書かない。

2. 個人非依存のテスト実行環境• Composer で install 可能 • 近代的な CI ツールなら簡単に構築可能 ( 前述 )

※ composer を知らない PHPer は存在しないという前提だが、大丈夫。問題ない。

3. 導入後の通知や運用ルール整備• 最近の CI ツールは通知拡張を備えている

(slack とか )• テスト失敗時に deploy 出来ないフローにする。• PR 開発によるコードレビューは相性が良い。

BeDD の必須構成要素VCS CI

Notification

BeDD のフロー 1

2. Webhook でテスト実行

1. ソースコードの push

BeDD のフロー 2

テスト用既存アプリBehat テスト

1. 実行

2. 通知

PHP5.3 以上であれば、既存アプリにテストを含めるのもアリ。

BeDD のフロー 3

本番環境

1. テスト OK であれば、 deploy が走る

2. 通知

参考資料

役に立つリンク• はじめてのBehat• 15分で作れるBehatテスト - e2e編• Behatエクステンション作成

( 参考 ) トレンド

( 参考 ) トレンド 2

Any questions?

Ask me @hanhan1978