これ僕.com:行動分析学マニアがおくる行動戦略

意図と行動のギャップから生じる「不自由さ」への挑戦。果たして僕たちに自由はあるのか?

オブジェクト倶楽部 夏イベントの感想(2) デベロッパーテスティング

午前のセッションは、t-wadaさんの「デベロッパーテスティング」。

デベロッパーテストとは

テストの分類

まず、テストの目的について確認。

  • Developer Test
    • 開発促進
    • フィードバックを伴う設計行為
  • Customer Test
  • QA Test
    • 非機能要件のテスト
デベロッパーテストとは

プログラマーの
プログラマーによる
プログラマーのための
プログラマーが書いたテスト。


で、以下の特徴がある。

  • コード(プログラム)であること
  • すばやく動作すること
  • 自動化されていること
テストフレームワーク xUnit

xUnitと呼ばれるテストフレームワークを使う。
テストフレームワークを使うことによって、
テスト記述方法と実行方法が共通化された。
実行方法が共通化されたことによって、
「書いた人でなくても実行できる」ようになった。
さらに、「機械にも実行できる」ようになった。

自動化から自働化へ

機械の特徴は、

  • 正確
  • 一貫している
  • 疲れない

である。
タスクをスケジューリングして自動起動し、
人間が求めなくても自ら結果を通知するようにする。
機械をプロジェクトの一員として旨く働かせよう。
人間の時間を有効活用するために、自動化から自働化へ。

なぜデベロッパーテストを行うのか?

Why?

テストで確認できるのは、コードが意図的に動作することだ。
さらに、自動化(自働化)によって「常に」確認できるようになる。
つまり、デベロッパーテストによって、
常にコードを信頼できる状態に保てる。(7/4: 文を修正)
結果、常に安心でき、勇気がもてる、と。
実は、デベロッパーテストを行う最大の理由は、
「心理的なもの」なのである。

プロジェクト健康宣言

デベロッパーテストの真の目的は「健康」。
ここで言う健康とは、

  • ソフトウェアの健康
  • 開発者の健康

である。


以下にプロジェクト健康宣言を記す。

  • デベロッパーテストは、心身共に健康な状態で、健康なソフトウェアを開発する手段である
  • 健康は信頼をもたらす
  • ソフトウェアも開発者も、健康であり続けること(継続可能)
  • ソフトウェアにも開発者にも、意識が行き届いていること
    • ヤバイことに気づき、改善できるということ

デベロッパーテストのバリエーション

xUnitを使ったテストコードのバリエーションが色々紹介されました。

Stub/Mock

特定のリソースに依存するコードをテストする際に、
その動きをシミュレーションするダミーオブジェクトを用意する。
主に以下に関連するテスト行うときに利用。

Learning Test

通常、ライブラリを初めて使う場合、

  1. ライブラリの使い方を習得する
  2. ライブラリを活用してコード書く

という2ステップが必要で、
ライブラリを使い始めるための一歩が大きい。


そこで、「ライブラリの使い方」に限定して、
学習目的のみのテストを書く。

  • テストコードによってライブラリの具体的な動作が確認できる
  • テストするためにライブラリを利用する具体的なコードを書く
  • 学習結果がテストとして残るので、他の人と共有できる
Assumption Test

外部ライブラリに依存した機能を開発するときに行う。
外部ライブラリの動作をテストコードで確認しておく。
こうすることで、

  • 外部ライブラリが、実際にどう動くかが確認できる
  • 外部ライブラリの仕様が変わった時に、テストが失敗するのですぐに分かる
Debugging Test

バグが見つかった時に、以下の手順に従う。

  1. バグをテストコードで再現する
  2. テストを実行し、失敗することを確認する
  3. テストが成功するように実装する

これを地道に積み重ねることで、
テストコードがより信頼できるものとなる。
スケジュールが押している場合は、
心理的に難しいけど、我慢のしどころらしい。
確かに。

Test As Document

ソースにはHowを
テストにはWhatを
ドキュメントにはWhyを。

すばらしい。

どうやって覚えるか?

デベロッパーテストのスキル習得方法について。

スキルである

デベロッパーテストは「才能ではなくスキル」である。
つまり、練習すれば誰でもできるようになる。
いっぱい練習してマスターしましょう!(量は質へ転化する)

習得方法1「写経」

本のコードを読むだけではなくて、
実際に手を動かして書いてみる。
おすすめの本。


ちなみにt-wadaさんは、仕事が忙しくて帰りが午前2時くらいになっても、
帰ってから1時間程度は写経をしていたそうな。
すげー。
やっぱ凄いと思う人は、それに見合う努力をしているんだな。

習得方法2「コードを読む」

最近のオープンソースにはテストコードもついてきているので、
それらのコードを読みましょう、と。

習得方法3「経験者に会う」
  • セミナーや勉強会で経験者の話を聞く
  • 経験者とペアプロする
    • t-wadaさんとペアプロすると驚くらしい。見てみたい・・・。

TDD

開発を促進し、設計を行うためのテストへ。

TDDの目標

TDDの目標は「動作するきれいなコード」。
これを達成する手順が2つ考えられる。

  • きれいなコードをかいて、動作するようにする
  • とりあえず動作するようにして、きれいにする

TDDは後者。

Red、Green、Refactor、Red、・・・

TDDのリズムを説明。

きれい (3)
汚い (1) (2)
動かない 動く

まず(1)からスタート。
テストコードを書いてRedバーを確認。
この時点でコードはまだ動かない。
次に汚くても良いから、
コードを動くようにして(1)から(2)へ移動。
Greenバーを確認。
で、Refactoringで汚いコードをきれいにして(3)へ。
Greenバーが維持されていることを確認。
次のテストを書いて、再び(1)へ戻る。

Red、Green、Commit、Refactor、Commit、・・・

(2)汚い&動くから(3)きれい&動くへ移る前に、
バージョン管理システムにCommit。
そうすることで、Refactorに失敗しても、
すぐGreenの状態に戻してやり直せる。

TDDは設計技法

Redは仕様の設計
Greenは仕様の実装
Refactorは内部設計の改善

テストリストを書く

テスト項目をリストにしておく。
リストを見ることで、
実装モードになった頭を設計モードへ戻すことができる。
テスト結果は今の位置を示し、
テストリストは目的地を示している。

テストを先に書く意義

実装とインターフェースを分けて考えられる。
つまり、Howではなく、Whatを考えられる。
また、利用者の視点を最初から得ることができる。
つまり、そのコードの最初の利用者はテストコードを書いている自分自身、か。


自分に意図や希望、不安を囁き、
それをテストにする。
TDDはゴール指向だ!(To-Beから考える)

GTDとTDD

GTDが出てきた!
GTDとTDDの共通点。

  • 心に着目
  • 開ループのダメージ
  • 一度に1つのものを

そう言われると、テストリストとGTDの次の行動リストは似てるなー。
テストリストを書きながらTDDするときの感覚と、
次の行動リストを書き出した後で作業をこなす感覚は、
全く同じものな気がする。
きっと、開ループのダメージから解放された状態なんだろう。

Ease of Testing

TDDによってテストしやすい設計を行うと、
自然に

  • 責務が少なく、やることがはっきりしている(凝集度が高い)
  • コラボレータが少ない(結合が疎)

な設計を引き出せる!

まとめ

デベロッパーテスティングは「スキル」だ。
すなわち、それは習得可能であることを示す。
そうして得たスキルで「プロジェクトを健康」に!

感想

以下の2点において、非常に収穫があるセッションでした。


その1。
ずばり「プロジェクト健康宣言」。
何に価値を置くのか。
我々の目指すところはどこなのか。
それが共有できる良い言葉だと思いました。


その2。
上記価値を実現するためのノウハウとして、
xUnitの利用方法のバリエーションや、
TDDの進め方が出てくる、と。
あるいは習得方法の話が出てくる、と。
「その1」から「その2」への流れがあることで、
ゴールとゴールへ向けた一歩目の踏み出し方が分かる。
このセッションを受けた人は、
明日からすぐに実践できるんじゃないかなー、と感じました。
当然、私も。


要望。
事前に資料の配付なりダウンロードなりができると嬉しかったです。
結構ハイペースにスライドが進んでいったので、
メモしきれなかったところもあったかな〜。


あと、t-wadaさんがご自身のBlogで書かれてますが、

TDDし続けることで次に見えてくる、
「大量のテストをどうやって運用していくか」
(まさに資産運用です)という問題意識です。

は、非常に興味あり。
最近悩んでることと、似ている気がしまして。(7/4 文を修正)
ソフトウェアを保守していく上で、
なんだか足かせになっているテストコードがあるな〜・・・、と。
この辺、何れどこぞのイベントで聞けるチャンスがあればいいなぁ、
と夢見つつ。