Agile Samurai Base Campっていうイベントに参加してきました。
http://www.agilesamuraibasecamp.org/
角谷氏の基調講演から始まって、インセプションデッキとテスト駆動開発の2グループに分かれてセッションが行われました。
講演者の一人である和田卓人氏は、以前ペアプロをしてもらったこともあり、もう一度お話を聞きたかったので、今回のイベントに参加しました。というわけで自分自身はテスト駆動開発のセッションに参加しました。
印象に残ったのは
テストを書くのは不安を取り除くためというのは、ペアプロをしてくださったときに何度も言われていたけど、今回も強調していっていたのでやはり重要なのだなあと再確認できました。実際にテストを書いて進めてたときは、気持ちが楽だったし。
また、あるリリース済みの機能の仕様変更が来た場合、テストコードの変更が大量に発生してしまう場合はどうしたらいいですか?という質問をしました。
当たり前のことだけど、仕様変更が大きければテストコードの変更が多くなるのは当然のことで、その変更をできるだけ少なくするためにはテストフレームワークをカスタマイズする等して対応すると良いとのことでした。
ただ、テストフレームワークのカスタマイズって、どのレイヤーの話だ?もうちょっと掘り下げて質問すれば良かったけど、自分の技量ではまだ理解できないと思ったのでやめといた。
また、TDDしてるプロジェクトのソースコードレビューの観点を質問したが、テストコードをよく見るとのことでした。
多くの講演者の方々が、一人でも始められるとおっしゃっていたので、がんばってみようと思う。和田さんにも久しぶりにお会いできて、やる気でました。
明日からまた塹壕に帰ります。がんばるぞー!
角谷氏の基調講演から始まって、インセプションデッキとテスト駆動開発の2グループに分かれてセッションが行われました。
講演者の一人である和田卓人氏は、以前ペアプロをしてもらったこともあり、もう一度お話を聞きたかったので、今回のイベントに参加しました。というわけで自分自身はテスト駆動開発のセッションに参加しました。
和田さんのお話
冒頭は、まず目標を考え、それを示すテストを書き、red --> green --> refactoringのサイクルを回しましょう(黄金の回転)という、いつものお話から始まりました。印象に残ったのは
- 「複数を相手にしない。一人ずつ対処する。」(五輪書)
- いきなり全てのテストを書いてRedだらけにしない
- TODOリストから一つのタスクを引っ張ってきて、テストを書く
- 一つずつテストをひっぱってきて、黄金の回転ですばやく倒す
テストを書くのは不安を取り除くためというのは、ペアプロをしてくださったときに何度も言われていたけど、今回も強調していっていたのでやはり重要なのだなあと再確認できました。実際にテストを書いて進めてたときは、気持ちが楽だったし。
また、あるリリース済みの機能の仕様変更が来た場合、テストコードの変更が大量に発生してしまう場合はどうしたらいいですか?という質問をしました。
当たり前のことだけど、仕様変更が大きければテストコードの変更が多くなるのは当然のことで、その変更をできるだけ少なくするためにはテストフレームワークをカスタマイズする等して対応すると良いとのことでした。
ただ、テストフレームワークのカスタマイズって、どのレイヤーの話だ?もうちょっと掘り下げて質問すれば良かったけど、自分の技量ではまだ理解できないと思ったのでやめといた。
テスト駆動開発の事例の話
ここで印象に残ったのは、レガシーコードのTDDの話。これは、自分の環境にも近いものがあり、参考になりました。また、TDDしてるプロジェクトのソースコードレビューの観点を質問したが、テストコードをよく見るとのことでした。
- テストが小さな粒度に分解されているか
- 一つのテストケースで複数のアサーションが入っていないか
テストコード以外の部分は、普通のレビューと同じらしいです。
まとめ
朝9:30からのイベントだったので、結構疲れた。多くの講演者の方々が、一人でも始められるとおっしゃっていたので、がんばってみようと思う。和田さんにも久しぶりにお会いできて、やる気でました。
明日からまた塹壕に帰ります。がんばるぞー!