STEAM PLACE

エンジニアリングとマネジメント

トップ > TDD > TDDは人間の問題にフォーカスしたものだった

TDDは人間の問題にフォーカスしたものだった

TDD 勉強会 Java

TDDBC Tokyo 2018-09 に参加してきました。

tddbc.connpass.com

とても知が深まり、とても楽しめて刺激的な時間を過ごすことができました。
当初は TDD は開発手法の一種だというくらいの認識だったのですが、人間を考えた深いものだったと気づきました。

事前に「テスト駆動開発」を読んでいったのですが、やはり実践で学べるものは桁違いでした。

テスト駆動開発

テスト駆動開発

こんなことやったよ

  • 基調講演
  • ペアプロデモ
  • ペアプロ(1回目)
  • コードレビュー
  • ペアプロ(2回目)
  • コードレビュー＆休憩
  • 質問コーナー＆クロージング

朝から夜までTDDに浸れました。長いなんて思う暇もなく一瞬で時が過ぎていきます。
#tddbc で当日の興奮が見れます。

3行でまとめ

長い記事なってしまったので先に3行でまとめます。

  • TDD = 開発手法 ≠ テスト技法
  • TDDはテストを書くことが目的ではない
  • TDDは人間の問題にフォーカスしている

基調講演

@yattom さんによる基調講演です。

聴けば聴くほどTDDはただの開発手法ではないということに気付かせてくれます。

TDDについてのお話

テスト駆動開発はふつうの開発です。
まずは動くようにする、そしてきれいにする。というアプローチをとっているだけ。

テストを書いてプロダクトコードを正しいか確認をすると考えた時に、テストが正しいことはどうやって確認するのでしょうか？
それは、シンプルなプロダクトコードで確認する、プロダクトコードを使ってテストコードをテストすることです。

Red, Green, Refactoring を1サイクルとして、まずはテストに失敗し、テストを通るようにして、 Refactoring をします。テストが間違っていないかすばやく実行して次のステップに向かいます。

TDDは小さなステップで進めていきます。 TODOリストを作り、ユーザー視点から設計を考え、仮実装、三角測量、そしてリファクタリングします。

いいテストとは

  • 高速である
  • 独立している
  • 再現性がある
  • 自己検証可能
  • 適時性がある

TDDと人間

TDDで動作するきれいなコードを目指す、それはチームにとってお互いが信頼できるコードを作ることができます。
以下のような問題に立ち向かい、チームの健康、ソフトウェアの健康を守ってくれます。

  • 人間の問題
  • 変更容易性の問題
  • テストの自動化と回帰テスト
  • 不安に立ち向かう
  • 命綱を編む

Tips

テストの増やし方

テストを増やす方法は2通りあります。

  1. 1つのテストケースにテスト増やす
  2. テストケースそのものを増やす

1つのテストケースにテストを増やすことよりも、テストケースそのものを増やす方が良いとされています。なぜなら、１つ目の assert でエラーになると、2つ目の assert がどうなったのかわかりません。
挙動はフレームワークによっても異なりますが、基本的にはテストケースを増やのをセオリーと考えましょう。

フレーキーテストはやっかい

外部のサービスに依存していたり、並列で安定していないなど再現性が低いテストはやっかいです。 そのテストを維持するためにコストが非常にかかってしまいます。

TDDはテスト技法ではないので、本当に必要なテストを、開発を進めるテスト書いていきましょう。

ややこしいロジック

ややこしいロジックを書くときは、こんなやり方もありなようです。

  • まずはテストロジック内にメソッドを作って仮実装
  • 固まってきたらプロダクトコードに落とし込む

ペアプロデモ 素因数分解

以下、実演とスライドから気になったワードをピックアップしました。

  • きれいを保つのがリファクタリング
  • 設計も見直し、プロダクトコードも見直す
  • 常にやり続ける
  • 「動くコード」を保証するテストが前提
  • 1つずつ一歩ずつ、段を小さく
  • 複数を相手にしない。ひとりずつ対処する。
  • すばやくまわす
  • 自分が最初のユーザ
  • 不安をテストに
  • 祈るではダメ
  • 命綱を編む

ペアプロ

【お題】
自動販売機のロジックを作成します。

プログラミングのお題: 自動販売機 (設計進化重視バージョン) · GitHub

ボタンを押すとコーラが出る、お金を払う、烏龍茶追加、、、、のようにお題が増えるにつれて複雑になっていきます。 これを TDD + ペアプロ で作っていきました。

以下、ペアプロ中の気づいたことです。

  • 三角測量ですでに同じようなテストがあるときはどうするのか
    • 正解はないが自明な場合は書かないというのもあり
  • テストを進めることで重複が明確にわかることがあり、そのタイミングリファクタリングをやるのがベスト
  • ペアプロで頭に浮かんだものを書き留めるところがあるといい
  • テストコードもリファクタリングするから、その過程でテストコードを削除することも多々あった
  • TDDのサイクルが回った瞬間があり、その瞬間はものすごく気持ちいくてノリノリになる

なんだかんだ、一瞬で時間は経ちました。

アウトプット

タスク一覧をTrelloで管理していたので公開しておきます。
見返すと雑なタスクリストですが、タスクリストで頭を整理しながら実装するのはなかなかいいですね。

実際のソースは下記にアップしました。ペアプロでの時間終了で中断されているので、リファクタリングが中途半端になっていますが、コミットログからコードがどんどん変わっていく様が見れるかと思います。
（Gitのログイン忘れてて daisuke-sato という名前でコミットされちゃってますが）

github.com

書いているときは、先のことを考えて実装しようと思ってしまいますが、その気持をグーっと抑えて最小限のコードで書くようにしていました。
まずは動くようにする、そしてきれいにするですね。（まだきれいになってないけど、このまま冷凍保存しておきます）

ペアになっていただいた @sister__clown さん、ありがとうございました！

質問コーナー

と思っていたことを、みなさんはどうしているか聞いてみました。

なるほどなるほど。と勉強になります。コードの声いいですね。

Kent Beck が3回目だというのはびっくりしたｗ

まとめ

以下の一言に付きます！素晴らしい勉強会でした。

集合写真も撮りました！

懇親会にでれなかったけど、懇親会も盛り上がっていたようですね！