雑ノート(仮)

適当なメモ。

「BPStudy#125〜テスト駆動開発(TDD)の真髄」に参加

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

ライブコーディング

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

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

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

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

排除すべき重複の判断

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

のサイクルがTDDの基本ですが テストコードの重複の排除は慎重に行う必要があり、 2箇所だと行わない、という意見もあるそうです(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前書きより

テスト駆動開発

テスト駆動開発

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

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

作者の気持ちを答えよ、

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

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

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

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

LT

錬金術MeetUpへのお誘い

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

UnitTest Anti-Pattern

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

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

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

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

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

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

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

感想

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

qiita.com

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

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

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

わからなかったこと

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

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

  • 質問の際にうまく考えがまとまらなかった
  • 初心者だから遠慮するというしょうもない選択肢を取ってしまった

ので質疑応答の際に発言できませんでした。

*1:DBアクセスを伴わない、オンメモリ上で完結するクラスの計算などの場合は・・・と前置きして説明されましたが、DBやネットワークなどが絡んでくるとまた違うのでしょうか?そこの説明は特にありませんでした。

*2:私に関しては10年前にもいけていませんが

*3:きちんとメモを取っていなかったので勘違いでしたらすいません

*4:またシグネチャを凍結するレベルの詳細設計書を書いてからコーディングをするような雰囲気があるのでリファクタリングなど禁じられないか不安です。