約70ページにもわたって MONEY EXAMPLE という事例が書かれています。 あまりに多いので一気に読むのはちょっと辛いですが、テストドリブンを夢見てがんばって読んでいます。 今回は テストドリブンの序盤となる部分をyんでみました。
実装の前にテストをすべて書くのは無理
MONEY EXAMPLE のところを見ると、 Kent Beck ですら最初にすべてのコードを書かない ということがわかります。 MONEY EXAMPLE で取り上げられている単純な金額の掛け算でも、コードが徐々に完成していくのにつれてテストコードも変わっていきます。 よく、最初にテストコードを書くなんて無理だからテスト駆動開発は無理だという人がいますが、テスト駆動とはそういうことではないんですね。
MONEY EXAMPLE では、 存在しないクラスを使ってテストを書き始めます。 Red どころか コンパイルすらできないテストを書くところから始めています。 必要なクラスを考えてクラスのテストから書き始めるのかと思いましたがそうではありませんでした。 最後の理想形をテストに書いていました。
テストドリブンの手順
ToDo の整理をしてからテストを始めます。 この ToDo List はコードが完成するまでついて回ります。 載っている事例では、 存在しない Dollar クラス を使ってテストを書くところから始めています。 そして テストを通してできるクラスのメソッドは(最初は)あくまでスタブです。
MONEY EXAMPLE は次のようにして進めていました。
テストを書く。存在しないクラスも使ってよい。
テストをコンパイルできるようにする。
テストを Green にする。
リファクタを行い、重複を取り除く。
テストを Green にする方法
固定値を返すなどして、テストを通るようにする。 (実装コードとしては完成ではない)
明らかにわかるコードを実装する。
複数の側面からのテストを書く。 (Triangulation )
Triangulation というのは、 テストケースを追加することで固定値での返り値を返せないようにするように、複数のパターンのテストを書くことで実装コードを規定していく方法です。 たとえば 1 から n までの総和を求める関数があったとして、 Sum(1) == 1 だけだったら Sum の返り値は 固定の 1 でもいいですが、 Sum(5) == 15 だと実装せざるを得なくなります。 Kent Beck は本当にどのようにリファクタすればよいか迷うようなときに Triangulation を使うそうです。 どうすればいいのかわかっている場合は Triangulation のためのテストコードは書かれません。
MONEY EXAMPLE の中で出てきた Value Object というのも重要だと思うのでまとめておきます。
Value Object
一種のインスタンス変数で、コンストラクタで設定された値はそれ以降変わることがありません。 これにより、ポインタを通じた意図しない値の書き換えの発生を防ぎます。 別の言葉で書くなら 副作用対策です。
Value Object の持つメソッドの戻り値は必ず新しいオブジェクトにします。 下に例を書きました。 Num の add メソッドの戻り値は新しいインスタンスになっています。 これにより add の前後で Num のインスタンスは変更することがありません。 また、 primitive value ではないので、 別途 equal メソッドを実装しておかないとテストコードを書くときに困ることがあります。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
class Num
def initialize ( amount )
@amount = amount
end
def get _ amount
return @amount
end
def add ( num )
return Num . new ( get_amount + num . get_amount )
end
def equal ( num )
return get_amount === num . get _ amount
end
end
Test-Driven Development By Example の JAVA のコードをまねて作ったのですが、 言語が ruby なので実践的には get_amount を書かずに attr_reader :amount と書きますね。
FuelPHP でどのデータベースが使えるのか、コードを覗いてみました。
使用可能なデータベース
FuelPHP では 次の DBMS を扱うことができます。 扱うことができるといってもドライバとして参照するというだけで、 完璧に使えるわけではありません。
Cubrid
FreeTDS
Microsoft SQL Server
Sybase
FirebirdIBM DB2
IBM Informix Dynamic Server
MySQL
Oracle Call Interface
ODBC v3 (IBM DB2, unixODBC and win32 ODBC)
PostgreSQL
SQLite 3, 2
SQL Azure
4D
調べ方
まずはマニュアルを読みます。 Database Introduction のところに Can be mysql, mysqli or pdo と あります。 つまり、 mysql の専用ドライバか、PDOドライバが使えるんですね。
続いて PDO について PHP のドキュメント を確認します。 すると、上述の DBMS すべてについて PDO が使えることがわかります。 もちろん PDOドライバがマシンに入っていればの話ですし、PDOとDBMSのバージョンには気をつけないといけませんね。
本当に PDO で繋がるのか？ と思ったら、 FuelPHP のコアファイルの中の接続部分を担っているコードを見ましょう。 mysql, mysqli, PDO の3通りの connection.php があり、 PDO であれば PDO ドライバを使って DB に接続するようになっていることがわかります。
sqlite を使う場合の注意点
sqlite を使う場合にはいくつか気をつけることがあります。 (FuelPHP version 1.7.2)
Primary Key に注意
Primary Key を他のデータベースと同じように設定しようとすると migration が動きません。 sqlite3 では、 Primary Key に名前をつけることができません。 例えば MySQL なら Primary Key id (id) となるところが、 sqlite3 だと Primary Key (id) というようになります。
直接SQLを作って実行するか、 FuelPHP の該当箇所を書き換えるかして凌ぐしかないです。 Primary Key を使わないという選択肢もありますが、おすすめはしません。
また通常は migration file を php oil を使って作成すると 自動で UNSIGNED の id が作成されて AUTO_INCREMENT が設定されますが、 sqlite ではこれが動きません。 sqlite では AUTO_INCREMENT ではなく AUTOINCREMENT になります。 いまのところ自動生成のスクリプトでは対応していませんので FuelPHP の core のコードを変更する必要があります。 そして自動生成される UNSIGNED は 削除しましょう。 sqlite では UNSIGNED BIT INT というのが使えますが、 使ったところで INTEGER と解釈されます。
charset を空にする
sqlite3 では charset の指定方法が他のデータベースとは異なります。 PRAGMA statement を使います。 (確か sqlite3 では標準文字コードが utf-8 だったと思います。)
データベースの設定(config/db.php)で文字コードの指定をしないと php oil migrate を実行する際に CREATE TABLE の構文で 末尾に DEFAULT CHARACTER SET utf8 のついたSQLが発行されてしまい、エラーになります。 これを防ぐためには charset => '' と、 charset に 空文字列 を指定します。 すると、 DEFAULT から始まる文字コード指定部分がなくなり、 sqlite3 でも php oil migrate が動くようになります。
db.php は次のように書きます。
<?php
return array (
'default' = > array (
'type' = > 'pdo' ,
'connection' = > array (
'dsn' = > 'sqlite:' . APPPATH . 'migrations/' . Fuel:: $env . '.sqlite3' ,
) ,
'table_prefix' = > '' ,
'charset' = > '' ,
) ,
) ;
このようにすると、 環境ごとに別の DB が作成されます。 table_prefix は php oil r migration の時には不要ですが、 php oil r migration:down の時に必要になることがあります。
PostgreSQL を使う場合の注意点
migration ファイル を作っても動きません。 これは Syntax が MySQL とだいぶ違うからです。 FuelPHP に PostgreSQL を使うためのプラグインがあるのでそちらを使うという方法もあります。
charset を空にする
charset に値が入っていると 接続情報(dns)に charset が含まれるようになるのですが、 PostgreSQL はこれを受け付けません。 そこで charset = '' と設定しておきましょう。 この点は SQLITE と同じです。
constraint を削除する
php oil g migration create_xxx のようにして テーブル作成のマイグレーションファイルを作成すると、 id カラム が自動的に作成され、 'constraint' => 11 という設定がされます。 この状態だと テーブル作成の SQL で id カラムは INT(11) に指定されます。 しかし、 PostgreSQL は INT(11) を受け付けません。 INT なら SQL が通ります。
そこで 'constraint' => 11 の設定を削除します。
どうやったら雑談 できるのか。 雑談力を上げるセミナーに行ってきました。 数人での雑談を前提に、どのようにすれば雑談できるようになるのか、聞いてきたことをアウトプットします。
話のできない人の共通点
話ができない人には共通点があるそうです。
他人 ( ひと ) 評価をやけに気にする
沈黙が嫌い
どうしよう！？ っていう戸惑いが出てくるんですね。 言い換えるならば、 自分がどうするのか ということにフォーカスしています。 つまるところ “何を話せばいいのか” というのが最大の課題になっているのではないでしょうか。 私もそのひとりなのですが。
何を話せばいいのか
話すことが決まってしまえばあとは楽なんですが、話すことが決まらないからこそつらいんです。 そんな課題を解決するためには、考え方を変えましょう。
知りたいことを聴く
相手について「もっと知りたい」と思うことを聴きましょう。 自分が話さなくてもいいんです。 これで、話のスタートができますね。
トップ営業マンと言われる人たちに共通していえるのも、知りたいことを聴いているということです。 知りたいことを聴くと 他の人が知らないことも知ることができるようになり、 営業成績につながっていくそうです。
雑談の聴き方
さて、話のスタートはできるようになりましたが、どうやって聴けばいいんでしょうか。 聴き方 にもコツがあります。
相手がどんなことを考えているか、想像しながら聴く。
他人のいいところを見つけるつもりで聴く。
この中に「相手の言っていることを正確に聞き取る」なんてことは入っていません。 言葉や文字ではないんですね。 私は過去に営業部の課長から「言っていることをそのまま聴くんじゃなくて、相手の意図することは何かを考えて聴け」と言われたことがあります。
雑談をする上でまず大切なのは、「相手がどんなことを考えているか、想像しながら聴く」ことです。 相手と同じ視点に立つことで、相手の言っていることも理解しやすくなり、共感しやすくなるんですね。
また、いいところを見つける習慣をつけておけば、挨拶として使うこともできるようになるのでおすすめです。
相手の話に興味が持てない時は、自分にもメリットのある話だと思って聴くのがいいそうです。
行動で雑談を楽しくする
雑談を更に面白くする方法があります。 雑談といっても文字で書かれた文章とは違って、その場で表現されるわけですから、視覚的な要素も重要になってきます。 方法を2つ紹介します。
相手が見たい顔をする
相手が見たい顔ってどんな顔でしょう。 それは笑顔 です。 あたりまえですけれど、今一度考えてみましょう。 挨拶するとき、話をするとき、相手が笑顔だったら話しやすくなりませんか？ こちらが笑顔でいることで相手も話しやすくなり、円滑に話ができるようになります。
聴いていることをアピールする
相槌 ( あいづち )
これは講師から聞いた話ですが、過去にディズニーのキャストをしていた人のリアクションは “そこまでやる！？” と思うほどのオーバーリアクションだったそうです。 でもやりすぎってことはないそうです。 特にパーティーの席や合コンなどではそこまでやらないと埋もれてしまいますね。
こういったことは反応心理学 として研究もされています。
以上、セミナーの内容をまとめてみました。
同僚の勧めで Test-Driven Development By Example Kent Beck です。 日本語のものもあるのですが、そちらは絶版になっているので買うなら中古です。
この本では具体例が示されていて、どのようにテストができていき どのようにコードができていくのかがよくわかります。 まだ最初のほうしか読んでいませんが、他人(Kent Beck )のテストの書き方がわかるので、自分のやり方を見直すよい機会になります。
Test Driven の基本
Preface のところに Test Driven の基本ルールが書いてあります。
自動テストに失敗するまで新しいコードを書かない。
重複は排除する。
テストで失敗するまでコードを書いてはいけません。 これに関連して よくはまる落とし穴に、「テストコードのテストコードを書く必要はないのか」というのがあります。 これについて 同僚は次のような説明をしてくれました。
自動テストがないときはどうやってテストしていましたか？ (PHPの場合) var_dump などでテストをしていたと思います。 テストコードのテストコードというのは、 その var_dump と 目視 のテストを書くってことと同じことなんですよ。 テストコードそのものの正しさは開発者が担保するようにして進めるんです。
わかったようなわからないような説明かもしれませんが、要するにそんなこと言っていたらきりがないからテストコードは開発者のチェックとコードの間に入れる保険なんだと思います。 またテストコードのバグについてはじゃんじゃん直していいそうです。
そして Kent Beck はコードの書き方について重要な方針を書いています。
自分の書いたコードのテストは自分で書こう
これ重要ですね。 この本をバイブルってことにしておけば、自分で書いたコードのテストは自分で書いてくれって言えますからね。 Red / Green / Refactor の順でやろうと思ったら自分で書くしかないんですけどね。
テスト駆動・自動テストのメリット
開発現場では往々にして「自動テストなんてやって意味あるのか」「時間がかかるだけじゃないのか」という議論が勃発します。 地位の高い人がそういうことを言い出すとどうしようもなくなったりします。 モチベーションにも繋がるところなので 自動テストのメリットを再確認しましょう。 本書では social implications として4つのことが書かれているのですが、それを仕事上のメリットとして書くと次のようになります。
汚いコードの密度が減り、品質保証は受け身の仕事じゃなくて能動的な仕事になる。
自分でコードを書くことが品質保証に繋がるので、問い合わせを受けてから手を動かすようなものではなくなります。
ドッキリするようなコードに遭遇することが減り、マネージャの見積もり精度が上がる。
開発者のみならずマネージャにとっても嬉しいことが起こります。
技術的な会話の議題が明確になり、同僚との協力作業の効率が高まる。
開発者の能力にもよると思いますが、書籍上ではそういうことが書かれています。
汚いコードの密度が減り、新機能の追加されたリリース可能なコードが毎日増えて顧客との関係が向上する。
毎日というのは言い過ぎかもしれませんが、バグを見落とすことが少なくなるので新規機能の追加に集中できるようになります。
特に2番目は重要ポイントですね、 テストドリブンとは関係なさそうな人にもメリットがもたらされるので。 どれも理想論に見えますが、テストドリブンの目指すところは上記のメリットです。
この本を読んで今以上にテストドリブンに力を入れていこうと思いました。 中にはテストを書かない人もいるのですが、具体的な進め方も書いてある本なので 他人への説明も楽にできると思っています。
目薬 にはいろんな種類があります。 どれを買えばいいのか全くわからない中、成分についていろいろと調べたことをまとめました。
続きを読む 目薬に含まれる成分の効果 →
投稿ナビゲーション
A Life Summary of an Gypsy
