XP祭り 2018

随時更新記事

とりあえずメモベースで公開

【基調講演】テスト駆動開発の過去・現在・未来（和田卓人さん）

  • 本の付録Cについて
  • ケント・ベックの本が絶版になった
  • １５年前の本を訳し治すだけではなく、まとめとして付録をつけた
  • 付録Cが扱っているのは２００２年から２０１４年
  • ４冊の本と一人の人物
  • TDD生誕前
  • 大きくは４人が関わっている
  • パターンコミュニティが関わっている
  • コンパイラの開発者がテストコードを書いていた
  • TDD2章はjunitの作り方とほぼ同じ
  • オブジェクト指向へのカンファレンスへの飛行機の上でペアプログラミングをした
  • Kent BeckはJavaが知りたかった。Erich Gammaはテストが知りたかった
  • テスト駆動開発はテストファーストにインクリメントな要素を入れたものと定義している
  • C2 wikiには当時の議論が全て残っている
  • TDDの誕生から現在まで
  • 2007年までに事例の本がいっぱい出てきた
  • その間の本は用語が統一されていなかった。用語も統一されていなかった。
  • そのときにxUnit Test PATTERNSという本が出た
  • この本はネットで公開されている。
  • ↑この本を書いた人がなぜこの本を出せたのかを調べたらパターンマニアだった
  • Mockにも広義のmockと狭義のmockがある
  • 理想は学習コストが高いが、学習したあとは開発が楽になると思っていたが、現実はそうなっていない。
  • この本では、もうそのことに言及していて、どうリファクタリングしていくかが記載されている
  • その後、Growing Object-Oriented Software, Guided By Tests(実践テスト駆動開発)が出る
  • ロンドンにXPを話し合うコミュニティがあった
  • テスト駆動開発に流派が大きく２つあった（ケント・ベックが書いた本をベースにした古典派と、mockを使ったロンドンの流派）
  • 今で言う広義のmockオブジェクトが生まれた
  • mockオブジェクトは依存関係を排除することで、開発の順番も変えられる事に気がついた
  • その結果、お客さんに近い部分（画面）から作成できるようになった
  • TDDのTについて考える
  • マイヤーズのテストの定義とTDDのTの定義がずれていた
  • TDDのTはテストお一部に過ぎない
  • 2002年にtesting Extreme Programing という本が出ていた（日本では未翻訳）
  • アジャイルの中でテストエンジニアが何ができるかが書かれている
  • ４象限のモデルを2003年にもう定義している
  • TDDはテストではなく、チェックキングだということを早くから言っている
  • テストエンジニアは自動化できないマニュアルテスト（探索的テストなど）を高めようと言っている
  • アジャイルにおけるテストとはテストフェーズではなく、日々の行いである
  • TDDからBDDへ
  • 2003年、テストコードからドキュメントを作成するようになる
  • 仕様を示すメソッド名をつけるとドキュメントとして残る様になった。それがBDDへになった。
  • testではなく、shouldを使うようになった
  • BDDはコードだから、お客と円滑に会話できないという議論が出てきた
  • BDDは２つの流派に別れた。今までのBDDとcucumberのように仕様記述のBDDに別れた
  • そして現在
  • 2014年何が起こったか
  • 教条主義化が起きた。テスト駆動開発の義務化、高圧化が起きた。
  • 最初のテスト駆動開発の本もTDDの強要ほど、TDDのの普及を妨げるものはない、と記載されている
  • David Heinemeier Hansson氏によって、TDD is dead. Long live testingという記事が書かれた
  • 意味の希薄化
  • 応用情報技術者試験でTDDの問題が出たが、意味があっていない
  • テストファーストとテスト駆動開発の違いがわからなくなっている
  • mockライブラリが強力になった結果、設計改善効果はなくなってきている
  • mockが書きにくいときは、設計が悪いという判断基準になっていたのに今は無理やりテストを通る様になっている
  • コードを書く段階になったらTDDとBDDに違いはない。RSpecは厳密にいうとテストツールではない。
  • 未来について
  • 意味が希薄化され、ツールだけが残っている
  • テストは品質を挙げない

QA to AQ – Being Agile at Quality: Values, Practices, and Patterns（Joseph Yoderさん、鷲崎さん）

(英語ベースのセッションだったので、私の理解で書いています。)

  • アジャイルでは、開発者、QA、プロダクトオーナーなどの人の壁を取って一つのチームとしてして扱う
  • そこで、QAはチームに加わりQA的な観点でvalueを考える必要がある
  • 今回行ったのは、アジャイル開発における品質シナリオを作成するワークショップ
  • QAもアジャイルにチームに参加したときに、品質を作り込むための品質シナリオをバックログに入れ込む（非機能などをどう担保し、どう計測するかを考える）
  • 品質シナリオは用意されたアーキテクチャに沿って品質シナリオを作成する。
  • stimulus,artiface,enviroment,response,response measure
  • 上げた非機能を担保するバックログは、非機能はプロジェクトのフェーズにより決める段階が異なるため、優先順位付けをする
  • 作り込んだ品質シナリオを実現するようにアーキテクチャの変更を検討する。

『フレーズ』で体験する、あのチーム（とちぎRubyの勉強会（toRuby））

ワークショップというより、”あのチーム”で普段使用しているフレーズを紹介して、参加者が自分の現場と比較してどう思うか、と言うようなことを議論する形式だった。
torubyには未参加だけれど、”あのチーム”の話はよく聞くので、興味があって参加してみた。
感想としては、チームの心理的安全が確保されているからあれらのワードが躊躇なく使えるんだろうなぁということを感じた。
チーム全員が製品のことを考えていて、チームメンバが全体最適を考えていることが素晴らしいなぁと思った。
その環境を作るのはそういう環境にした優れたリーダーや、アジャイルのプラクティスで共通の目標を持つように出来たから、今の環境があるのかなぁと思ったがどうなんだろうか？
"あのチーム"の今より、どうやって今のチームを作成したのかを今後聞いてみたいと思った。


（資料が公開されたらもう少し書く予定）