Behat Driven Development

Behat Driven
Development
2015/10/3
㈱オハコ Ryo Tomidokoro
PHP Conference Tokyo 2015

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• controllerもmodelもテストできる
• DIコンテナ万歳！＼(^o^)／
• よーし、fixtureでテストデータ登録しちゃうぞー
【プロジェクト中期】

• 駆け込みで作る機能はテスト無し
• いいから動くものを・・・
• 外注の部分はごっそりテストがない・・・
• 応援メンバーへのテストツール教育が・・・
【プロジェクト後期】

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

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

ケース3) テストの放置

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

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

自動テストの成功を阻む要因
1. テストツールの教育不足
2. 個人依存のテスト実行環境
3. 導入後の通知や運用ルールの不備
※ 組織の政治的な理由による場合は○クルートエー○
ェントとかに相談してください。

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

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製で、拡張が簡単
特殊なツールではないし、すごく目新しいわけ
でもない。ほどよく簡単。

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: php
php:
- 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エクステンション作成

Any questions?
Ask me @hanhan1978

Behat Driven Development

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Behat Driven Development

Semelhante a Behat Driven Development (20)

Behat Driven Development