【イベントレポート】TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング

2020年8月1日 12:47

こちらのイベントに参加してきましたのでレポートです。

基調講演の内容はYoutubeのアーカイブで閲覧可能だそうですので、見逃した方はそちらを見ていただけると良いかと思います。

TDDBC本体にも参加したかったので、connpassの事前申し込みには登録していたのですが、本募集始まった事に気付いた時にはチケット売り切れていました... うん、TDDが人気なのは良い事です。もっと広まれ。そして現場で実践しやすい環境になってくれ。

今回はTwitter実況をしていたので自分のツイートを並べつつ、全体的な感想を書くというとても簡易なレポートの形式にチャレンジです。

概要

発表者は言わずと知れた @t_wada さんで、TDDの基本的な説明をされた後、FizzBuzzのライブコーディングを通じてTDDのプラクティスを説明してくださいました。

具体的なプラクティスの中でも自分にとって特に参考になった部分を以下に列挙していこうと思います。

「1~100まで順にプリントする。ただし3の倍数の時はFizz、5の倍数の時はBuzz、3と5の倍数の時はFizzBuzzとプリントする」

この条件のうち、重要な部分を慎重に切り出していくと「3の倍数の時はFizz」「5の倍数の時はBuzz」「3と5の倍数の時はFizzBuzz」の部分が重要なルールです。

「プリントする」は特段ビジネスロジックとしては重要度が低く、かつテストが難しい概念です。こういった部分（CleanArchitectureでいうと入出力に近い部分＝レベルが低い部分）を慎重に取り除いていけば、重要かつテスト容易な部分を切り出す事ができる、という事でした。

今日の講演で最も「なるほど！」と感じた部分がここです。

TDDではテストファーストの考え方が当たり前で、テストコードを書く時にプロダクションコードのメソッド名や引数などを考えるのも当たり前でした。

ただこの時t_wadaさんが仰っていたのは、「使いやすさとか読みやすさは使う側にならないと分からないから、先に使う側になってみて考えるべき。作る前に使えば、コストゼロで使いやすいコードが分かる」ということで、これは至極納得しました。

これは初めて聞いたのですが、テストコードのアンチパターンで、ユニットテストのテストメソッド内に複数のアサーションがあることを指すようです。

- 上に書かれたアサーションが失敗していたら下のアサーションは実行されない
- 失敗したアサーションがどこなのかも分からない
- 後からテストコード見た時に、どのような期待結果なのか見通しが悪い

という問題点があるという話でした。

私、講演資料を1枚スクショ撮ってツイートとか普段しないのですけど、これはびっくりして思わずやってしまいました。

「せめてこのくらいはやってほしい」という話だったけど、このレベルでテストコードが豊かなドキュメントになってる案件、見たことないですよ！！！
#tddbc pic.twitter.com/uRpNmaOUWS
— 脱脂綿 (@anchor_cable) August 1, 2020

Javaであればインナークラスが使えるので、テストクラスの中に抽象的な仕様をまとめるインナークラスを書いて、その中に具体例であるテストメソッドを書くやり方が紹介されていました。

同時に、今までドキュメントにできていると思っていたテストコードが全くそうではなかった事に気付かされました。。。

テクニックとしては自分も実践したことがあるものが殆どだったのですが、「なぜやるのか」という説明が豊富で、その中には自分で理解できていなかったものも含まれていたので、これから実践していく上での納得感が増しそうだなと思いました。

TDDでモブプロやっていくイベントには過去何回か参加経験があるのですが、TDDBC本体はまだなので、次回は参加したい...

この記事が気に入ったらサポートをしてみませんか？