Agile Samurai Base Camp 2014 Re:TDDに参加してきた！

うらら〜。うらら〜。春うらら〜。

今日、日曜日は、渋谷マークシティのCA社（２回目）に行ってきました。

実は１回目は昨年12/8。このblogを始めるきっかけにもなった、感動と、衝撃と、自分も動き出さなきゃ！っていう最高の刺激を頂いた機会であり、はてブやTwitterのプロフ写真も・・・（ry　とにかく個人的にとても想い深いイベントでありまして・・・

とにかく、その刺激がリフレインしまくったそんな一日でした。

※ピザとbeerの交流会もあったり、前回以上にいろいろなお話を聞いたり、質問できたり、満腹♪満腹♪

※この手作り感も大好き!!

※スピーカーの皆様、スタッフの皆様、お話しできた皆様、本当にありがとうございましたm(_ _)m

12/8の最初の記事。

Agile Samurai Base Campに参加してみた - 部屋とアジャイルと私（仮称）

その後、社内勉強会でTDDのサワリを発表したり、すんごいモチベーションもゲッツ。

明日からTDDをやってみよう！ - 部屋とアジャイルと私（仮称）

TDDと直接関係ないが、前回もご説明いただいた同じスライドでも、１回目に感じなかったことが、沢山あったこと自体、blogを始めたおかげであり、そんなきっかけを頂けたことを改めてここに感謝♪感謝♪感謝♪

しかも前回に増して、参加者メンバの中でも、TDDを実際にやっている方（チームだったり、個人だったりはさておき）が結構いて、その現場の本音を聞けたのもすごい収穫でした。

自分は、まだまだ、TDDを「分かった気になってしまっていた」ってことに気づかせていただいたのも、とっても良かった。

分かったつもり、一番の自分の悪い癖。

(・A・)ｲｸﾅｲ!! (・A・)ｲｸﾅｲ!! 

うむむ。相変わらず前振り長すぎ・・・orz

～～～～～～～～～～～～～～～～～

■当記事のアジェンダ

（１）今日の自分テーマ

（２）結果サマリ

（３）その他、雑メモ

（４）補足・・・関連リンク集とか

～～～～～～～～～～～～～～～～～

（１）今日の自分テーマ

事前に考えていた、今日ノ場で学びたいこと主な５つ

●仕様のテストと実装のテストの件。実装詳細をテストする必要はないとある。でも不安をテストするともある。自分が前回一番理解できなかった（勘違いしてるっぽいところ）

●レガシーコード改善から始めるTDDに取り組む件（これが一番自分の周辺にハマりそう）

●テスト粒度（テストコードのメンテナンスと、テストコードの資産価値、小さいテストを積み上げてEnd2Endのテスト、どこまでがTDDなのか）

 

●三種類のテスト（Developer、QA、Customer）

 

●TDD三原則。TDD実践においてどこまで厳格に（原理的に）したほうがいいのかの加減を含めて。

（２）感想サマリ

※自分テーマと順不同

●テストを必ず先に書かなければいけない訳ではない。そこにテストコードが存在することが重要。あまり原理的になる必要はなく、その辺の加減・工夫がいろいろな現場でいろいろ方にノウハウあり、自分なりにTDDをうまく使えるようになることが一番大事だろう。

●TDDはプログラミングの一部であり、TDDだけで品質が保証される（担保される）わけではない。TDDでソースもエンジニア自身も「健康に」というメッセージは非常に深い！

●仕様のテストこそ、テストコードとして価値がある。実装のテストはリファクタリングすることでテストコードが崩れてしまうので、積極的に書くのではなく、でも不安がある場合は、一歩一歩階段を上るという意味でも実装を確認する。（＝思った通りに動くことを確認する＝つまり不安をテストする＝TDD）

※「仕様のテスト」と「実装のテスト」についての参考：

「実装をテストする」とは？ - ふぃーるどのーつ

●エンジニアのスキルアップには、フィードバックが細かければ細かいほど良い。TDDのサイクルは小さく小さく回したほうがいい。（でも自信があるときは大股で走ってもよく、でも一歩一歩確認しながら、赤くして自信があってたことを確認する癖をつける）

●自身のモチベーションを保つための工夫は人それぞれ。ひとりから始められるのもTDDのいいところ。こういう社外勉強会にも今後積極的に参加していきたい！

（３）その他、雑メモ

・チームで考えるワークショップいかにボールにチーム全員が触るか（19秒→3秒→0.9秒）

・今年後半ぐらいに「テスト駆動開発入門」が本屋に並ぶかも

・リファクタリングがし難い環境が身近にある・・・動けばいいじゃん。壊したくない。という堕落と恐怖（グサっ！）

・必ずテストコードから書かなくてもよい。少し実装してからテストから書いてみるのもあり。

・リファクタリングは、気づいたときにすぐにやったほうがいい（溜まれば溜まるほどリファクタリングに時間がかかり、理解がないとそんな時間はモラエナイ）ただし、少し先にどのようにリファクタリングすればいいかの答えが見つかりそうなときは一時的にtodoリストに書いておくのもあり

・テストコードが無い現場にて、TDDを普及させていくため、まず最初、まずは依存の少ない部分を狙い撃ちして、テストコードをつくりはじめるとよい。また、その際は大きな仕様のどんどん荒いテストから作り始めて、テストして、カバレッジ範囲を少しづつ広げていくことを繰り返していくとよい

・JUnitの場合、テストコードにGroovyを使うとよい。（これは良いことを聞いた〜）JUnit実践入門「テストフィクスチャ」をあとで見る。

・オフショアでTDD（というかアジャイルプロセスでの開発）を導入している事例。交流会で「アドバイスください」と図々しく・・・、でも、そのチームだけにMacを与えて、周囲が憧れる開発環境のチームをつくるとよい。実は投資額としてはちょっとしたもの。何よりMacでの開発は良いyo！とかナルホドー 

・新人研修でテストコードを書かせて、TDD実践のハードルを下げて組織的に取り組む姿とか眩し（真似したいけどなぁぁぁ）

・レガシーコードにおけるEdit & Pray。ソースを修正して、祈りながらリリース。（ドキっ）

・一人からでも始められるTDD

・レガシーコードの不具合修正で、TDDをつかう（これだけが正解ではないが有効な事例あり）

     →　レガシーコード改善で、自分のTDD力をあげる！！

・スプラウトメソッド（TDDしたい部分をくくりだすのはIDEまかせ）

・まずは手元（ローカル）でJenkinsを回して、テストして、ドヤ顔www

・DBをつかったテストをどうするのか？

　　→　DB環境を毎回つくり直すのが理想（ただ現実問題、そう簡単にはいかない）

　　→　まずは自分でSQLでテストデータを突っ込んで、DBを使った部分のテストを地道に

　　→　周りを巻き込み、新しいDB環境をたててDBUnitでデータを突っ込んでテスト実施

・テストを書きながら進めることで、安全に前にすすめる

・TDD→BDD→ATDDとテスト範囲を広くしていくイメージ・・・テスト粒度はユニットテスト→結合テスト→システムテストに近いイメージ

・プロダクションコードよりもテストコードの方が高いスキルを要求されるとおもう

　　→　テストやり過ぎは疲れてしまうのでハードル低く

　　→　必要最小限のテストをテストコード化して、そこから膨らませていくイメージ

・TDDを組織に文化として根付かせるためのアドバイス

　　→　テストを書いたことを褒める（ハードルを下げる）：高橋さん

　　→　社内勉強会を開催して各自が勉強したことをLTしあったり：中川さん

　　→　ベースキャンプ（ここ）は帰ってくるところ　うまく行っても行かなくても戻ってくれば良い：有野さん

（４）補足・・・関連リンク集とか

Agile Samurai Base Camp 2014 Re:TDD #agilesamurai - Togetterまとめ

Agile Samurai Base Camp 2014 Re:TDDに参加してきました - 個人的なまとめ

Agile Samurai Base Camp Re:TDD に行ってきた！ - 終電23時15分って早くね？

アジャイルサムライ TDDトラック行ってきた - まっつんの日記

Agile Samurai Base Camp 2014 Re:TDD｜ラブリー東京♡気まぐれコリアンの東京日記

※随時追記ヨテイ（しかしみんなblogうp早〜！ ）

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

まだまだ整理が必要で混乱もしている。

自分で手を動かしながら、体現しつつ、少しづつでも前に進みたい。

いきなりTDDというおっきな相手に立ち向かうのではなく、分解して１体づつ倒していく・・・そんなTDDのイメージで、これからもTDDを続けていこう！！

余談

インセプションデッキの２回目もあるらしいよ〜〜〜〜っ (￣ー￣)ﾆﾔﾘ