t_wadaさんと柴田芳樹さんの講演から、テスト駆動開発の良さを実感しました。 #JaSST

はじめに

  • 先日、JaSST'18 Tokyoが開催されました。

JaSSTソフトウェアテストシンポジウム-JaSST'18 Tokyo

JaSST'18 Tokyo チュートリアル「コードを書きながら学ぶテスト駆動開発

  • テスト駆動開発(TDD)の第一人者であるt_wadaさんが講師となってTDDを学びました。

当日のツイートまとめ

  • 以下のページです。*1

togetter.com

チュートリアルの構成

t_wadaさんによるライブコーディング付きのTDDの方法についての発表

  • もう、この一言に尽きる。こんなになめらかなライブコーディングは初めて見た。

  • 滑らかすぎて、必死についてきてツイートしたので、それは上記まとめページを見てください。

  • 自分は初めてTDDを学んだのですが、何よりも「TODOの出し方」から「1回目のRed解消」までのやり方は非常に参考になりました。

  • 今回は全員がeclipseを利用するという制限で行っていましたが、それによって「ライブコーディングで示したいたのと同じことを、自分が使っているIDEでできるのか!」と共感できました。

  • 特に、以下の一連の流れは、「テストコードを書く」というよりも、「実装する(それがたまたまテストコードだった)」という感覚になりました。

    • fail()でとりあえず失敗するテストコードを書く
    • まだ作っていない変数や関数を記述して、コンパイルを失敗させる
    • 変数を宣言させてコンパイルを通る状態にしていく
    • 関数を宣言させて、プロダクトのクラスを作成することでコンパイルを通る状態にしていく
    • でっち上げでも良いからテストコードの通る値をreturnして、テストも成功するように変更する
  • また、JUnit5ならではのテクニックも参考になりました。

ペアプログラミングでのTDD体験

  • さて、t_wadaさんの発表を聞いただけでは、理解はできても実感はできません。

  • 今回のチュートリアルでは、2人1組になり、ペアプログラミングをしてTDD体験をしました。

  • この体験を通じて、色々とTDDでの苦労を体験できました。*2

    • TODOの分割で、優先度の高いものがどれになるか考えられない
      • FizzBuzzの例でいえば、「数を文字列に変換」とかを考える前に「3の倍数だったらFizzと変換」とかを考えちゃう
    • 取り掛かるテストコードが具体的にならず、試行錯誤で具体的にしていた
      • 何を入力値で、何が期待結果になるか分からぬまま、取り掛かろうとしていました
    • 細かい関数に分けて考えられない
      • 1つの塊のコードで考えるクセが付いているらしく、それを細かく区切るというところに頭が回らない
    • ナビゲートが大変
      • 経験年数から見て、今回は自分がナビゲート役でしたが、TDDは初めてだったので、上記の苦労した点の改善策を上手く相方に伝えられませんでした…。
  • ここらへんは、もっともっとTDDに慣れ、ペアプロに慣れることで改善していきたいと思います。

  • チュートリアルならではの内容で非常に勉強になりました!

JaSST'18 Tokyo招待講演「私が経験したソフトウェアテストの変遷」

  • 今回の招待講演は柴田芳樹さんによるお話でした。

当日のツイートまとめ

togetter.com

招待講演の構成

  • 大きく分けて、以下の3部構成でした。

    • TDD、CIの話
    • 柴田さんの経験談
    • ソフトウェア開発とQA

TDD、CIの話

  • 個人的には以下で紹介する「フィードバックループを短くする」の図が招待講演の中で一番響いた部分です。

  • QAテストなどは開発者へのフィードバックが長い。

f:id:nihonbuson:20180329092359p:plain

http://jasst.jp/symposium/jasst18tokyo/pdf/A7.pdf#page=9

  • 単体テストになると開発者へのフィードバックは短くなる。
  • しかし、実はこれが最短ではない。

f:id:nihonbuson:20180329092432p:plain

http://jasst.jp/symposium/jasst18tokyo/pdf/A7.pdf#page=10

f:id:nihonbuson:20180329092445p:plain

http://jasst.jp/symposium/jasst18tokyo/pdf/A7.pdf#page=11

  • t_wadaさんのチュートリアルのおかげで、「常に実装している感覚」が実体験と共に実感できました。

  • 手で行ったテストは資産ではない…「自動テスト実装までやると余計なコストがー」という人に聞かせてあげたい。

柴田さんの経験談

  • ブログに書き残すことができない話もしていたため、あまりメモを残せていません…。
  • ただ、Flakyなテストに悩んでいた話も聞けて、「ここでもFlakyが!」と一人で反応してました。

ソフトウェア開発とQA

  • 実装より前に設計するという、ソフトウェア開発において当たり前の話がなかなかできていない気がします。
  • そして、それを上司が理解していない場合、考えをひっくり返すのにパワーがいるという話は「確かにー」と思ってしまいました。

質問

  • この質問が印象的でした。
  • この質問では、「API設計」を前提とした質問でしたが、教育についてはどんな場合でも同じようにいえると思う。
  • 教育や研修については、どれだけ現場と近付いて協力的に行えるか、もっと考えるべきだなと思っている。
  • そういう意味でもペアプログラミングは教育的視点も含めて良い方法なのだろうなと感じました。

終わりに

  • 今回のJaSSTでは如何に開発とテストが協同して行われるかが(個人的に)テーマだった気がします。
  • 基調講演などでは自動テストがテーマでしたが、今回参加・紹介したテスト駆動開発もその一つだったと感じました。

関連記事

  • JaSST'18 Tokyoでは自動テストの話も盛んに行われていました。自動テストに関する記事はコチラです。

nihonbuson.hatenadiary.jp

nihonbuson.hatenadiary.jp

*1:自分以外、誰もツイートしてなくて、「あれ?これってツイート禁止のチュートリアルだっけ?」と不安になりました。

*2:これはTDD自体で残り続ける問題というよりも、慣れで解消できるような問題だと思っています