ビープラウドさんが主催されているBPStudyに参加しました。生でt_wadaさんを見るのは初めてだったのでちょっと緊張しました。

ライブコーディング

@t_wadaさんのライブコーディング(TDD)を見ることができました。ライブコーディングではFizzBuzzをコーディングしながら、 TDDにおけるノウハウ・テクニックを和田さんが実践して提示する、というスタイルでした。

基本的書籍のテスト駆動開発に書かれているテクニックと同じでしたが、ライブコーディングを見ていて本には書かれていない、面白いテクニックが何点かありました。

わざとエラーとなるコードを書いてEclipseにコードを生成させる

これは私もVisualStudioでよくやるのですが、足りないメソッドを追加させたり、が関の山で、t_wadaさんはテスト対象のクラスまでEclipseに作らせていました。確かに、完璧にテストファーストで実践すれば、IDEのメニューをマウスでカチカチ選んで追加するのはテストファースの「テスト」のみで良いはずです。これは新しい気付きでした。

排除すべき重複の判断

RED -> GREEN -> リファクタリング(重複を除く)

のサイクルがTDDの基本ですがテストコードの重複の排除は慎重に行う必要があり、２箇所だと行わない、という意見もあるそうです(3つ以上で初めて本質的な重複と考える)

これをスリーアウトと呼ばれていました。

Assert rouletteアンチパターン

xUnit Test Patternsの「テストコードの不吉な匂い」に書かれている内容の一部のようです。

xUTP Magazine - xUTP Topics: 第三回 xUnit Test Patterns の世界観「テストコードの不吉な臭い」

まだ、本書を全部読んだわけではないですが、antiとか rouletteとかで検索してなかったので多分載っていないと思います。 FizzBuzzだと3,5の倍数以外は普通の整数を返しますが、それをまとめて

@Test
void testNumber(){
  assertEquals(fizzBuzz(1),"1");
  assertEquals(fizzBuzz(2),"2");
  assertEquals(fizzBuzz(2),"4");
  ...(以下略)
}

という風に書いてはいけない、ということです。

理由は・失敗した場合、どのデータで失敗したのかわからない・失敗した時点でテストが切り上げられる・後から見返した時に何をテストしたかったのかわからない。などです。

@Test
void testNumber1(){
  assertEquals(fizzBuzz(1),"1");
}

@Test
void testNumber2(){
  assertEquals(fizzBuzz(2),"2");
}
...(以下略)

のように、assertionを追加するのではなく、テストメソッドを新しく作りましょう、という提案がありました。*1

TDDの現状

“テスト駆動開発は、プログラミング中の不安をコントロールする手法だ。”

抜粋Test-Driven Development前書きより

テスト駆動開発

作者: ＫｅｎｔＢｅｃｋ
出版社/メーカー: オーム社
発売日: 2017/11/13
メディア: Kindle版
この商品を含むブログを見る

不安な箇所のテスト粒度はどうしても細くなる
自身がある箇所のテストはステップが大きくなる

という傾向があり、TDDでテストを作ると基本的に粒度が揃わないそうです。実装していない人が、後からテストを見直しても、粒度の違いから何も読み取れず、

作者の気持ちを答えよ、

状態になってしまう。という指摘がありました。

TDDで開発した後に、テスト粒度を揃えることが大事です。 常に対称性を持たせろ、という意味ではなく、意味のある構造を持たせろとのことでした。

最近は前任者がよくわからないテストを残していったが、なんのためのテストかわからなくなっているが、消すのも怖いので管理するコストが増加している、というのが最近の傾向とのことです。

10年前に比べてテストは書くようになったけど技術的負債になりがち*2

LT

錬金術MeetUpへのお誘い

TDDの読書会に参加されておられる方のLTです賢者の石を作ろう、的なものではなくお金を編み出す技術、についての会合らしいです。

錬金術MeetUpへのお誘い from Hiroyuki Ohnaka

UnitTest Anti-Pattern

Unit Testのアンチパターンの紹介です。実践している人向けだと思います。経験値のない初心者(私)には厳しいです。

オンラインPython学習サービスPyQの価格決め

主催の佐藤社長の発表です。

オンラインPython学習サービスPyQの価格決め from Haruo Sato

ぐるぐる読書会というコンセプトがいいなと思いました。

各自が本を持ち合って、付箋などで気づいたことを共有しながら本を読むそうです*3

電子書籍でもKindleやePubで遠隔地の人同士でSNS的に出来ると面白そう、と思いました。ビジネス的には本は共有出来なくてもメモは共有できると思います。 epubのリーダーにSNS的な機能がつけば実現できるのかな？と思いました。

おすすめの本は早速書いました。

人もお金も動き出す! 都合のいい読書術 [新書版]バカになるほど、本を読め! (PHPビジネス新書)

作者: 神田昌典
出版社/メーカー: PHP研究所
発売日: 2017/08/19
メディア: 新書
この商品を含むブログを見る

感想

自動テストではありませんが、FizzBuzzのテストは一度考えたことがある、ので

qiita.com

TDDならこうなるのかというコントラストが印象的でした。

TDDを実践すると、少しずつソース・テストが育っていくのだ、ということを改めて実感しました。講演中に和田さんがなんどもおっしゃっていましたが、「どちらが正しいとかはない」「正解はない」というのは本当だと思います。

「テストの自動化」とか「テスト駆動開発」はかなりのパワーワードなので手段が目的化しないように気をつけたいところです。

わからなかったこと

私は業務でテストコードを書いたことがまだない、全くの初心者ですが、例えばFizzBuzz程度の小さなプログラムでもテスト駆動で作るようなものなのか気になりました。

というのも私のTDDデビューとなりそうなプログラムがFizzBuzz並みに小さく、TDDで書くより普通に組んだ方が早く思えてしまいます。加えてデータベース接続とファイル作成削除があるのでTDDをやろうと思うと、モックやインターフェースやラップクラスがたくさん出来てしまい、単純な機能なのに無駄に管理コストが高くならないか、という日頃の不安から、上記の疑問点を思いつきました。 *4