安心してください。 テスト書いてます

ENJOJI Yasuto

円城寺康人ともうします

p アジャイルサムライ横浜道場 スタッフ

p XP祭り2015 実行委員

p 認定スクラムマスター

p Twitter @yenjoji

円城寺康人ともうします

p 株式会社 アットウェア Rouleur p 某大手通信会社の法人向けサービス開発プロジェクト

p アジャイル・チョット・シッテルおじさん p 開発者兼Scrumのアドバイザー的なことをやってます

p プログラミングしたいのでスクラムマスターはやってません

p 最近では Atlassian Bamboo と連動するズゴックを職場に配置したりしてます

おしながき

p 私の現場のはなし p TDDをはじめてから今まで

p はじめた理由 p 取っ掛かり p メンバーふえた p チームも増えた

p どんな技術をつかっているか p フレームワークとか

p で実際どうしているのか p 結果どんなかんじか

私達の現場

p 某大手通信会社の法人向けクラウドサービス新規開発 p 2014年1月 スタート p 顧客社員＋協力会社（マルチベンダー）の混成チーム

p 開発プロセスはScrum+XP

私達の現場

p アジャイル開発経験は様々 p TDD経験も様々

p わたし自身も本格的なTDD開発経験はなし p 自動テストは書いたことはある

なぜTDD

p インクリメンタルな開発 p 継続的にサービスを成長させるていく過程で品質を担保するためには自動テストが必須

p 顧客の意識 p 今どきテスト書かないなんてありえない p テストを書くコストはかける価値のあるコストとの認識

TDDの導入

p 新規プロジェクト p チームメンバー

p 11人 p 1チーム p クライアント＋マルチベンダー混成チーム

TDDの導入

p 最初はとかく不安になることが多い p どうやればいいのか？ p やり方はあっているのか？

p そこに対して“大丈夫です”と言ってくれる人の存在は大きいと思います。

p ベロシティが全然上がらない中それでもテストを書き続けた

TDDの導入

p TDD師匠の存在 p @setoazusa 氏の存在

p ペアプロ p お互いにフォローしながら p TDDのプロセスについてティーチング＆コーチングしながら

p （いい意味で）意識高い系人材が集まった p 品質への意識

チームのスケールアップ

p チーム人数増加 p 11人ｰ>21人 p 1チームｰ>2チーム

チームのスケールアップ

p 人が増えると、また違った価値観の人が増えてきます。 p ペアプロしたくないとか p テスト書きたくないとか

p ただ、私達のチームにはそういう人がいなかったため、新しいメンバーにチームのやり方を教えればOKでした。

チームのスケールアップ

p ペアプロ p テストを書くことに慣れていない人のトレーニング

p 周りが自然にテストを書いている風景 p 巻き込まれ感・長いものに巻かれる感 p そもそもメンバーみんな意識高い系？

p 完成（Done）の定義に明記！

チームのスケールアウト

p 隣のグループにヨコ展開 p 新規に2チーム追加 p 全部で4チームに

チームのスケールアウト

p 更にチームを増やす p アジャイル開発経験のないメンバー p そもそもやったことないです！！！

p 何も知らない人にはうまく言いくるめてTDDでやってもらってみました。

p 最初につまずかないように気をつけました。

チームのスケールアウト

p すでにあるチームからメンバー加入 p 取っ掛かりの障害排除 p 相談できる環境を用意する

p ペアプロ p 軌道に乗るまではがっちりと p やっぱり直接コーチング・ティーチング

p 当然 完成（Done）の定義に！ p ベロシティに一喜一憂しない

システムのアーキテクチャ

p フロントエンド p Backbone.js or Angular.js のどちらか（チームによる）

p バックエンド p Java (Spring) でのRESTful API p Spring Batch を利用したバッチ処理 p 永続化は JPA(Hibernate)

フロントのテスト

p Backbone.js p Mocha+chaiでのユニットテスト p Casper.jsでの機能テスト

p Angular.js p Karma+jasmineでのユニットテスト p ProtractorでのE2Eテスト

バックエンドのテスト

p Controllerのテスト p Spring MVC Test を利用したHTTP経由でのアクセスをエミュレートしたテスト

p ビジネスロジックはJmockitでモック p ビジネスロジックのテスト

p データベースアクセスを実施 p DBUnitを使用 p 外部サービスなどはJmockitでモック

リグレッションテスト

p Geb+Spockで自動化 p 一部手動テストもあり p 導入していないチームもある

p 毎朝9時にAtlassian Bambooから自動実行 p エラーがあったらHipChatに通知

テストを取り巻く環境

p 開発管理ツールはAtlassian p Jira ＋ Jira Agile

p BTS/ITS p Confluence

p Wiki p Stash

p Gitリポジトリ管理 p Bamboo

p CIサーバー p テストケース管理はTestlinkかRedmine+Impasse p メトリクスはSonarQube

テストを取り巻く環境

p 現場がツールの導入に積極的 p Atlassianとか p Dockerとか p ChefとかServerspecとか p SonarQubeとか

p 新しい技術もいいと思ったら積極的に採用 p Gebとか

p Scrumの検査と適用による継続的なカイゼン

こういう環境で 日々TDDに励んでます！

残　念

残　念

実際問題TDDしてません

p やっていないこと p “Red -> Green -> Refactor” p いわゆる３原則への準拠

p やっていること p “Coding -> Test ｰ> Refactor” p 安心してください。テスト書いてます。

それでも僕は（TDD）やってない

p チームの合意のもと p 形にこだわらない p 自動テストちゃんとは書くということについては合意

p チケットのススメ方として結合テストケース（手動）は最初に書く p 広義ではテストファースト？

Not dogma followers

p TDDにメリットがあることを認めつつもチームがよりやりやすい方法を選択

p プラクティスに縛られて嫌になるよりはテストがある方が嬉しいという結論

p チームが最終的に品質を担保できることが目標 p 自動テスト、手動テスト、QAチームが相互に補完しあう関係

p 定期的にふりかえりを行うことによりその時の最適解を模索する

わたしがTDD自動テストで得たもの

アパティア

心の平穏

p テストがあることの安心感 p 常に実行され続けている p 自分の目以外でチェックされる

p リファクタリングできる p 壊していないことの確認 p 健全なコード＝バグりにくい

心の平穏

p デグレ怖いからの開放 p ファーストリリース（2014/7）から6回のアップデートリリースを行うも大きな障害なし

p リリース前には次のリリースの開発に専念出来る p 虫つぶしに追われていません

p むしろリリース作業をサクッと終わらせて飲みに行ける！

私達がやった、やっていること

p チームがその時のベターと思われることを選択しました p TDDを強制しない p 自動テストは書く

p 定期的にふりかえって見なおしてます p チームの成熟度とかメンバーによって今後やり方は変わっていくと思います

ご静聴ありがとうございました

参考URL

p 私の現場での技術的な課題とその解決について p http://www.slideshare.net/setoazusa/jug-2014-fall-how-to-intoroduce-tdd/

p 私達がテストファーストしないことについての技術的バックグラウンドについての考察 p http://blog.fieldnotes.jp/entry/2014/05/07/225129