NDS FM

第13回NDSFMはまさるさん(masaru_b_cl) をゲストにお迎えしてTDDBC長岡の開催前情報としてTDDとは何か、TDDBCに参加するとどんなことが体験できるのかについて話しました。

💡お知らせ

• 2019.02.09 (土) 長岡まちなかキャンパスで TDDBC 長岡 が開催されます
• 2019.03.02 (土) 長岡まちなかキャンパスで 第59回NDS勉強会 が開催されます

内容

TDD とはなんでしょうか？

Test Driven Development、テスト駆動開発などと日本語では訳しますが、プログラムの挙動を確認しながら開発を行おうという開発手法です。開発者の思い通りにプログラムが動作することを確認し、安全にコードを書き進めるためにテストを書きます。

TDDの「黄金の回転」(inspired by STEEL BALL RUN)

1. テストを書く
2. テストを実行して失敗させる(Red)
3. 目的を達成するための最短のコードを書く
4. テストを実行して成功させる(Green)
5. テストが通ったまま本来あるべきコードに段階的に変更する(Refactoring)
6. 1〜5を繰り返す

どんなテストを書くべきでしょうか？テストにも設計や仕様書は必要ですか？

TDDで書くテストは「開発者テスト」です。つまり「開発者が思った通りに動くことを確認する」テストを書きます。 したがって、テストとしての仕様書はなくても構いませんが、プログラムの設計書や仕様書はあった方が良いでしょう。あと、「思った通りに動くこと」を保証するには、どのような観点や条件のテストを行ったら良いかを知らなけれいけません。そのためには、基本的な「テスト技法」を知っていた方が良いでしょう。

• 同値分割
• 境界値分析
• デシジョンテーブル
• Pairwise法
• etc…

TDDBC に出るとどんな良いことがありますか？

日本におけるTDDの第一人者である和田卓人氏から、直にそのエッセンスを学ぶことができます。 また、TDDを学びたいという同志と出会い、共に第一歩を踏み出せます。一人でもTDDは始められますが、一人よりは二人の方が気持ちの上でのハードルは下がりますからね

テストは必ず必要ですか？カバレッジは100％である必要はありますか？

プログラムを構成するコードには、実際にはテストがしやすいものとそうでないものがあります。 例えば、UIに関する動作については、そもそもUIの自動化自体のハードルが高いことに加え、UIはもっとも変更されやすい部分の一つであるため、せっかく書いたテストがすぐ陳腐化してしまうということがあります。したがって、UIに関するテストは、必ずしも書かないといけないものではありません。 また、よくある質問に「プライベートメソッドのテストは必要か？」というものがあります。こちらについては、本来テストで確認すべきなのは、プログラムの入出力であるはずで、実際に「どのように」動作しているかはブラックボックスでも構わないはずです。したがって、プライベートメソッドはパブリックメソッドを通じてテストされるはずなので、無理をしてプライベートメソッドのテストはしなくても良いです。なお、プライベートメソッドは変更される頻度が高めであるということも、テストしないでも良い理由の一つです。 それでもなおテストしたいプライベートメソッドが出てきたら、それはもうプライベートメソッドではなく、別の型やパッケージのメソッド、関数として切り出すべきです。その方が、テストをするコストも小さく済みます。 どんな時にテストを書いて、どんな時に書かないかについては、ボブおじさんことロバート・C・マーチンが書いた「Pragmatic TDD」というブログエントリも参考になります。高野が意訳もりもりで訳したエントリもありますので、ぜひ見てみてください。

• The Pragmatics of TDD - Clean Coder Blog
• TDDしないケースについてのUncle Bobの考え - be free

テストにはどんなツールを使うのが良いでしょうか？

最近の大抵のプログラミング言語には、デファクトスタンダードとなるような「テスティングフレームワーク」があるのでそれを使うのが良いでしょう。

例

• Java
  • JUnit
• C#
  • xUnit.net
  • NUnit
  • MSTest
• JavaScript
  • mocha
  • Jest
  • QUnit
  • Jasmine
• Python
  • pytest
• Go
  • testing

さらに、テストの中で行う「検証」をわかりやすく、簡単に描けるようなサポートライブラリもあるので、こういったものを使うのを検討しても良いでしょう。

例

• Java
  • AssertJ
• C#
  • Chaining Assertion
• JavaScript
  • power-assert

もしテスティングフレームワークがない環境だった時は、「入力」と「出力」の組を与えてプログラムの実行と検証を行うようなスクリプトを自分で書いてしまうのもありです。書籍：テスト駆動開発の第2章では、Pythonを使ってそのような仕組みをTDDで作る過程を扱っていますので、参考にすると良いでしょう。

おすすめの書籍やサイトはありますか？

• 書籍
  • テスト駆動開発 (Kent Beck著、和田卓人監訳、オーム社、2017年)
• サイト
  • TDD のこころ
  • -動画で解説- 和田卓人の“テスト駆動開発”講座：連載｜gihyo.jp … 技術評論社
  • 付録Cだけじゃない！付録Aに隠されたTDDの狙いとは？〜テスト駆動開発をやめて、なお残すべき習慣とは(10)
  • 希薄化したTDD、プロダクトの成長のために必要なものは？〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （６）
  • privateメソッドのテストについて - Togetter

テストを行うために本来必要なスコープを広げる必要があります。問題ないでしょうか？ スコープを狭めることでコードを読む時に気にする範囲も狭めることができます。また、コードを書き換えたり削除する際にも外部に影響が出る心配をしなくて済みます。

スコープを広げるくらいなら、「一つのことをうまくやる」型や関数に切り出し、それを利用するように変更してしまうと良いでしょう。そうすれば、切り出した部分について、別途テストを書いて開発を進めることができます。また、こうすることで、「処理」に必要なインターフェースや状態が明確になるので、結果としてコードがわかりやすくなることもよくあります。

ただし、例外として既に既存の資産が膨大にあり、なおかつある「枠組み」に沿ってコードを書くことが強制されたような環境では、「テストコードからのみ参照できる」ようにスコープを広げることもあります。例えば、Javaの場合アクセス修飾子を書かなければパッケージプライベート(同一パッケージ内からは参照可能)になるので、テストコードと製品コードのパッケージを同じにして対処したりします。また、.NET言語ではInternalsVisibleToという属性をつけると、テストプロジェクトのみ参照可能な状態を作り出せます。