皆さん、こんにちは。第五回となりました今回は、
初心者枠からちょっと足が出そうな環境構築編でございます。
このあたりが初心者と中級者の分かれ目と個人的には考えてますので、皆さんぜひ読んで試してみてください。
アジェンダは以下の通り。
* UnitTestとは？
* UnitTestが必要とされるのはなぜ？
* PHPUnit使ってみよう
* Testの考え方
UnitTestとは？
Testと聞いてtest.phpとかを想像してもらっては困りますよ！
皆さんはテスト駆動開発やTDDという言葉を聞いたことはないでしょうか？
僕は最初の会社に入社した直後は聞いたこともなく、
確かPHPカンファレンス2010あたりでお話をする方が多かったことでようやく知ったという思い出があります。
【駆動開発】と【DD】の部分は前の文字を主体に動かすと考えてください。
つまりテストを軸として開発を行っていく。テストファーストであると言うイメージで良いです。
TDDの他にもBDD(振る舞い駆動開発)というのもありますが、両方共テストファーストという大雑把な印象づけをとりあえずしてください。
意味ややり方を理解するうちに言葉の違いにも拘り出す時期が来ると思います。
TDD,BDDに関しては検索すれば腐るほど出てきますので興味があったら派生や成り立ちはおってみても面白いかも？
ちなみにアンサイクロペディアには
[締め切り駆動開発](http://ja.uncyclopedia.info/wiki/%E7%B7%A0%E3%82%81%E5%88%87%E3%82%8A%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA)
なんてものがあります。僕の大好きで大嫌いなやつだ！！
UnitTestが必要とされるのはなぜ？
Testと言う言葉自体はプログラムの世界以外でも飛び交っているので意味自体はわかると思います。
例えばパソコンのパフォーマンステストなんていうとベンチマークソフトをダウンロードして実行したらあっというまにテスト完了。
しかしプログラムのテストとなるとそうも行きません。
まずGUIがない！ここで黒い画面恐怖症の方は一歩引きます。
そしてテスト自体は動いてる状態を想像できなければいけません。締め切り駆動開発ではまったくもって無理な話です。
さらには最初の工数がテストを使う前よりも若干あがります。
最終的に動作テストなどの時間を考えたら慣れれば慣れるほど全体工数は短くなるんですが、
理解してても使いこなせてない人は多いと思います。
たとえばテストコードが全くない場合、
三日前のコードを見直すと自分が書いたコードとは思えないと言う話がよく出てきますが、それが一年後に仕様変更が発生した場合どうでしょう？
何を意図した変数定義なのか…？この汚いコード誰だよ！←自分でした。
みたいなことが起こってしまい、たった数行の変更だけでもレグレッションテストに膨大な時間がかかってしまう場合があります。
さらに数年後だと作った人自体が会社にいない！なんてことも…
しかしテストコードさえあれば、最低限仕様変更などでコードを修正した場合でも動作保証がされるわけです。
そしてテストファーストの言葉があるように、テストをあとから組み込むというのもこれまたものすごい労力と精神力がいりますし、
全体をすべて網羅すろというのはかなり大変です。
これから始める方はまず、コンポーネント化されるような小さなパッケージに対してテスト駆動開発を試してみてください。
PHPUnit使ってみよう。(公式丸投げ)
PHPにおけるテストは、PHPUnitやSimpleTestなどがあります。最近のフレームワークにはPHPUnitが搭載されていることが多いですね。
CakePHPだとPHPUnit＋Cake独自の若干の拡張機能付き、みたいな感じです。
PHPUnitの公式はここ
[PHPUnit](https://phpunit.de/)
あんまり公式を見に行く機会がなかったんですが今見ると日本語のスタートガイドもついて便利になってますね。
[日本語スタートガイド](https://phpunit.de/manual/current/ja/index.html)
ここでつらつらと断片的な情報を述べるより最初の使える状態まで持っていくのは公式を見てもらったほうが良い気がします。
ただ、一つだけ注意点があります。
PHPUnit自体もバージョンが存在していますので**なんでもかんでも最新のを入れてしまうとCakePHP2.X系でうまく動かなかったりPHP5.5あたりで使えなかったりします。**
使い慣れたあとなら動きがおかしいことに気づくかもしれませんが、使い始めで一方は最新、一方は一世代前のもので原因が特定しにくい嫌なハマり方をします。
動作対象範囲などはしっかり確認しておきましょう。
個人的になんでもかんでも最新も抜け出す力がないうちは辛かったです…
UnitTestの考え方
ここまでUnitTestは使ったほうがいい！という体で書いては来ましたがなんでもかんでもテストコードを書いていけばいいというわけではないと思っています。
もちろんテストに関する知識や手法は学んでいて間違いではありません。他人が書いたコードを読む際にも必要ですからね。
ただ、よーしじゃあ次のシステムは全部書いちゃえ！というのは早急に感じます。
テストコードを書いた！ イコール 品質は完璧だ！
ではありませんしそもそもテストコード自体が間違ってたら正解ではない動作が保証されてしまいます。
また、そもそもテストコードを書くことに向かない仕様も存在しています。
テスコトードがあるからレグレッションテストが全く必要ないわけでもありません。
テストコードを通る値自体に変更がかかっていたら元も子もないわけです。
また至極単純なコードに対して長々とテストコードを書いてしまってもただ工数がかかってしまうだけです。
ですのでUnitTest、PHPUnitなどの造詣を深めることは100％悪くありませんが、
理解した先に、「この場合はテストコードが必要なのか？」という自問自答をワンクッションいれる気持ちを忘れないでください。
まとめ
* テストファーストという概念を理解しよう。
* 小さいパッケージ（ユニット）からテストを構築していこう。
* 各パッケージのバージョンの確認は怠らず！
* なんにでもテストはNO！
さて、開発環境に関しては前中後と分けてお送りしました。書いてるうちにこれは開発環境なのか…？と思った部分もありましたがご容赦を…
次回はPHP7の情報でもお送りできたらなと思っています。
