はじめに
- 先日、JaSST'18 Tokyoが開催されました。
JaSSTソフトウェアテストシンポジウム-JaSST'18 Tokyo
- 最大7トラックにまで別れた中、私はテスト駆動開発関連のセッションにも参加しました。
- そのセッションで得た以下の内容を記載していきます。
JaSST'18 Tokyo チュートリアル「コードを書きながら学ぶテスト駆動開発」
- テスト駆動開発(TDD)の第一人者であるt_wadaさんが講師となってTDDを学びました。
当日のツイートまとめ
- 以下のページです。*1
チュートリアルの構成
t_wadaさんによるライブコーディング付きのTDDの方法についての発表
@t_wada さんのライブコーディング、安定しててヤバい。
— ブロッコリー (@nihonbuson) 2018年3月7日
いや、何回もやっているんだろうけど。
もう、この一言に尽きる。こんなになめらかなライブコーディングは初めて見た。
滑らかすぎて、必死についてきてツイートしたので、それは上記のまとめページを見てください。
自分は初めてTDDを学んだのですが、何よりも「TODOの出し方」から「1回目のRed解消」までのやり方は非常に参考になりました。
FizzBuzz問題を切り出していく。
— ブロッコリー (@nihonbuson) 2018年3月7日
1. 改行する
2. 「1から100までの数」が面倒。
3. 「プリントするプログラム」って難しい。#JaSST
TODO
— ブロッコリー (@nihonbuson) 2018年3月7日
============
- [ ] 数を文字列に変換する
ただし、
- [ ] 3の倍数のときは数の代わりに「Fizz」と変換する
- [ ] 5の倍数のときは数の代わりに「Buzz」と変換する
- [ ] 3と5の両方の倍数の場合は数の代わりに「FizzBuzz」と変換する
- [ ] 1から100まで
- [ ] プリントする #JaSST
今回は全員がeclipseを利用するという制限で行っていましたが、それによって「ライブコーディングで示したいたのと同じことを、自分が使っているIDEでできるのか!」と共感できました。
特に、以下の一連の流れは、「テストコードを書く」というよりも、「実装する(それがたまたまテストコードだった)」という感覚になりました。
また、JUnit5ならではのテクニックも参考になりました。
JUnit5では @Nested をつけてあげれば良い#JaSST
— ブロッコリー (@nihonbuson) 2018年3月7日
@RunWith(Enclosed.class) を付けることで、eclipseのバグを回避@DisplayName でJUnitでの表示名を付けられる(JUnit5以降)#JaSST
— ブロッコリー (@nihonbuson) 2018年3月7日
ペアプログラミングでのTDD体験
さて、t_wadaさんの発表を聞いただけでは、理解はできても実感はできません。
この体験を通じて、色々とTDDでの苦労を体験できました。*2
- TODOの分割で、優先度の高いものがどれになるか考えられない
- 取り掛かるテストコードが具体的にならず、試行錯誤で具体的にしていた
- 何を入力値で、何が期待結果になるか分からぬまま、取り掛かろうとしていました
- 細かい関数に分けて考えられない
- 1つの塊のコードで考えるクセが付いているらしく、それを細かく区切るというところに頭が回らない
- ナビゲートが大変
- 経験年数から見て、今回は自分がナビゲート役でしたが、TDDは初めてだったので、上記の苦労した点の改善策を上手く相方に伝えられませんでした…。
ここらへんは、もっともっとTDDに慣れ、ペアプロに慣れることで改善していきたいと思います。
チュートリアルならではの内容で非常に勉強になりました!
JaSST'18 Tokyo招待講演「私が経験したソフトウェアテストの変遷」
- 今回の招待講演は柴田芳樹さんによるお話でした。
当日のツイートまとめ
招待講演の構成
大きく分けて、以下の3部構成でした。
- TDD、CIの話
- 柴田さんの経験談
- ソフトウェア開発とQA
TDD、CIの話
個人的には以下で紹介する「フィードバックループを短くする」の図が招待講演の中で一番響いた部分です。
QAテストなどは開発者へのフィードバックが長い。
http://jasst.jp/symposium/jasst18tokyo/pdf/A7.pdf#page=9
- 単体テストになると開発者へのフィードバックは短くなる。
- しかし、実はこれが最短ではない。
http://jasst.jp/symposium/jasst18tokyo/pdf/A7.pdf#page=10
- テストファーストで実装することで、最も短いフィードバックになる。
http://jasst.jp/symposium/jasst18tokyo/pdf/A7.pdf#page=11
Unitテストの作成だとデバッグしている感覚だが、TDDは常に実装している感覚
— ブロッコリー (@nihonbuson) 2018年3月8日
あー、この感覚は昨日のTDDチュートリアルで感じたわ#JaSST
- t_wadaさんのチュートリアルのおかげで、「常に実装している感覚」が実体験と共に実感できました。
2000年以降は基本的に自動化したテストを書き、
— Takuto Wada (@t_wada) 2018年3月8日
コンピュータによる自動実行可能なテストコードを資産として残す。
手で行ったテストは資産ではない。
自動化されたテストが無いソフトウェアは次第に腐っていく。 #jasst
- 手で行ったテストは資産ではない…「自動テスト実装までやると余計なコストがー」という人に聞かせてあげたい。
柴田さんの経験談
- ブログに書き残すことができない話もしていたため、あまりメモを残せていません…。
- ただ、Flakyなテストに悩んでいた話も聞けて、「ここでもFlakyが!」と一人で反応してました。
ソフトウェア開発とQA
「テスト設計がうまくできないソフトウェアエンジニアが多い」
— ブロッコリー (@nihonbuson) 2018年3月8日
「API設計がうまくできないソフトウェアエンジニアが多い」
「コードカバレッジを品質基準にしているソフトウェア開発組織が多い」
分かるー#JaSST
- 実装より前に設計するという、ソフトウェア開発において当たり前の話がなかなかできていない気がします。
- そして、それを上司が理解していない場合、考えをひっくり返すのにパワーがいるという話は「確かにー」と思ってしまいました。
質問
API設計ができる開発者がいないという話について
— ブロッコリー (@nihonbuson) 2018年3月8日
それを教育していくのには、経験を積む以外に良い方法はあるか?
経験については、きちんとできる人のレビューを受ける経験。
1人でAPIを設計するには、教育は「教育でやっただけ」ではダメ。「教育(架空)と現場指導(実際)をセットで行う」#JaSST
- この質問が印象的でした。
- この質問では、「API設計」を前提とした質問でしたが、教育についてはどんな場合でも同じようにいえると思う。
- 教育や研修については、どれだけ現場と近付いて協力的に行えるか、もっと考えるべきだなと思っている。
- そういう意味でもペアプログラミングは教育的視点も含めて良い方法なのだろうなと感じました。
終わりに
- 今回のJaSSTでは如何に開発とテストが協同して行われるかが(個人的に)テーマだった気がします。
- 基調講演などでは自動テストがテーマでしたが、今回参加・紹介したテスト駆動開発もその一つだったと感じました。
関連記事
- JaSST'18 Tokyoでは自動テストの話も盛んに行われていました。自動テストに関する記事はコチラです。