JaSST関西’18に行ってきた話（基調講演編）
毎年のことなのですが、JaSST（ソフトウェアテストシンポジウム）関西’18に行ってきました。過去のプログラムを見ると2010年あたりから見覚えのある内容になっているのでかれこれ7-8年は通っていることになります。
なんでまた急にブログるのと言われると、電子化された予稿集を参照するために今年からノートPCを投入するようになったのと、その勢いではてなブログの開設手続きをやっちゃったからだったりします。正直なところ、ほぼ講演と同時進行で実況
はされてるし、多分すごい詳しいエントリとかも投稿されるんだとは思いますが、自分の感想の整理を兼ねてやってみようかなと。（多分小学生の作文みたいに、あとに行くほどしぼんでしまう感じになりそうだけど）
ということで早速基調講演の内容です。TDD（テスト駆動開発）で有名なt_wadaこと和田卓人さんの講演です。（後日資料公開あると言われていたのでそちらも参照ください）
ネットではライオンのAAが有名だそうで、実際”t_wada”でグーグル画像検索したら上位５位までライオンAAがでてきました。一種のなまはげみたいなもんとご本人もおっしゃっていました。「テスト書いてないとライオン来るよ」みたいな感じでしょうか。もちろんご本人の人格とは異なりますとのこと（そりゃそうですね）
あ、あと、今どきのモダンな開発では「テストコードを書いていない」ことはレビューをリジェクトする立派な理由になるんだそうです。「テストコード書いてきてから出直してね」というわけです。ウチの勤務先でもテストしてない、ってことはないにしてもテストコードを全部書いてるかというと多分そうじゃないと予想するので、世の中もうそこまで進んでるんだなーと思いました。
また、書籍「プログラマが知るべき97のこと」（監修）、「SQLアンチパターン」（監訳）、「テスト駆動開発」（翻訳）、そしてpower-assertというテストフレームワークなどを手がけられているそうです。（すいません開発しないのであまりよくわかっていません）
そして本題ですが、今回の基調講演ではTDDやってるところを聴衆に見せて、その上でソフトウェアテストとの接点を探りたい、ということでした。和田さんはJaSSTで講演されるのは2回め（以前にJaSST北海道で講演されたことがある）なんだそうですが、過去の講演で多かった質問が「TDDがなんなのかわからない」「やりかたがわからない」というものだったそうです。それに対する答えが「これからあなた方が目撃するものがTDDです」。うーん、カッコ良すぎですね。（より詳しくは書籍「テスト駆動開発」参照ということだそうです）私もたまーに社内で研修の講師やれよと言われますが「これからあなた方が目撃するものが○○です」とかよう言わん。講師自身がよくわかってないこともあるし（汗）
ということで、実際に講演でTDDがはじまります。ライブコーディングです。目の前でガリガリとコードとテストが書かれていきます。このあたり、自分が開発経験ないので、うまく表現できませんが、ガサゴソとネット検索してみたら、以下が見つかりました。
23:00付近からのデモを見れば講演時のライブコーディングがどんな様子だったのかを感じていただけると思います。
細かい話は私にはわからないところもあるので、概念としてこれはと感じたあたりを以下列挙です。
- 要求を箇条書きにし、さらに表現をそろえつつ「一撃」（ひとくちサイズ）できる粒度に調整していくところ
これは開発に限った話ではなく、色んな所で重要だと思います。特に言い換えたりして表現を揃えていく、というのは大事だなと思いました。グーグル翻訳とかで入力の日本語をコネコネするような感じでしょうか。調整せずにそのままやりきってしまおうとすると無理が生じる、というのはどんなことでもよくあるな、と。
問題を小さく分割して各個撃破するのと、最適な順番を考えるというのはTDDに重要なスキルなんだ、と説明されていました。 - タスクは重要なものからやるか、簡単なものからやるか、だがオススメは後者
これも序盤に勢いつけたいとか、準備が重いのでタスク自体は軽めのものから入るほうがいい、とかプログラミングにかかわらず有用なノウハウだなぁと。 - 「ただし」は要注意ワード
これはテストするときでもあるあるですね。正常系以外の内容や例外条件とかが出てくる予兆ですね - TDDではテストコードのそのまた下に当たる部分（＝検証部分）を先にかく。目的をブレさせないため。
考えながら走っていると目的地を見失う、というのはよくあるので先にゴールを設定しておくというわけですね。これもいろんなことに共通で使える考え方ですね - 作る前に使う側に回って考える
作ってしまうと「こうこう使ってほしい」というバイアスが発生するので作る前に使う側に回って考えて検証部分を先に書いてしまうと。余計な束縛を受けないための知恵ですね。テストでも事前に中身を知りすぎると無意識に遠慮したりするという心理はありそうなので、そういったところをカバーするのにいい考え方ですね。
さて一通りライブコーディングが一巡したところで、話はテストへと向かっていきます。次の疑問はこれです。
「TDDになって開発者がテストするようになったらテストエンジニアはもう不要なの？」
TDDのTは当然テストですが、このテストについて和田さんはこう言います。TDDのテストは動作するきれいなコードに到達するための手段だと。これはJ. マイヤーズのいうところのソフトウェアテストの定義「テストとは、エラーを見つけるつもりでプログラムを実行する過程である」とは違ってますよね、と和田さんは続けます。TDDのテストはプログラミングテクニックであってソフトウェアテストではないと。TDDのテストは
で言われているところの“Checking”だとあっさり認めてしまいます。実際チェッキングだよねと。なんでTDDはCDD（Checking Driven Development）にならないんだろう、という点については書籍「テスト駆動開発」の付録C参照、だそうです(笑)
アジャイルテストの4象限だとビジネス面/技術面、チーム支援/製品批評の2軸があるのだそうですが、TDDのテストはそのうちのチーム支援が主眼なので製品批評的なテスト、探索的なテストやセキュリティテストはTDDではカバーできないので引き続き必要になるはずだ、ということでした。
では両者は独立した別々のものなのでしょうか？和田さんはテスティングフレームワークを用いている以上、両者をなだらかにつなぐことができるのではないかといいます。TDDに必要なスキルにテストの構造化とリファクタリングがあり、そこにテストエンジニアの貢献を期待しているというのです。どういうことかというと、TDDで作成したテストコードのメンテナンスコストを抑えるために、保守性を確保する必要があるが開発者は実装を進めていく以外の動機が弱いのでいろいろと困ることが出てくるのだそうです。
例えば先程のFizzBuzz問題のライブコーディングに戻ってみると、○○を渡したら文字列××を返す、みたいな具体的な振る舞いだけが記載されたテストコードが多数並んでいます。だけど、一口サイズに分割した結果、もともとこれらのテストケースを作成しなければならなかった理由、つまりFizzBuzzの仕様はテストケースからはよくわからない状態になっています。この状態で担当者が代わったりしてしまうと、テストケースの重要度や階層構造が全くないので全部のテストを丸呑みしてしまわざるを得なく、それがメンテナンスコストを押し上げているというわけです。
これを解決するにはテストコードを構造化したり、それぞれのテストケースに根拠を与える必要がありますが、そういったことに長けているのがテストエンジニアで、値の選び方とかツリー化やテストケースの増減に対する根拠付けなどの面で開発への貢献が可能なんだ、という話をされていました。書くだけがテストなんじゃなくて、考えて分類して、というのが大事なんだけど、そのへんが開発者には足りないことが多いのでテストエンジニアと協業できるんではないか、という話でした。
質疑ですが、「テストコードがないコードを抱えている状態である場合、どうすれば良いですか？」という質問が出ていました。これはもっともよく現場で要望されることらしく、詳しくは「レガシーコード改善ガイド」という書籍を参照のこと、ということでしたが、こういう状況の場合無理やり大外（WEB系ならばEnd to Endとか）からテストを書いていくか、もしくはテストが書けそうになるまで慎重にリファクタを続けていく、の2択だそうで、ご紹介の書籍には後者のノウハウが豊富（stack overflowでの被引用数No.1）なんだそうです。
たぶんこのエントリもリファクタしないといけないのだろうなー、と思いはするのですが、とりあえずGreenになったということで乱文ご容赦いただければ。
しかし講演内容をまとめるのは大変だな・・・・。速報的に投稿してる人たちはすごいなぁ・・・。基調講演以外をエントリできるのはいつのことやら・・・。
