OSC2015北海道で「phpspecで学ぶLondon School TDD」という発表をしてきました
見た目を重視してこんなタイトルにしてみましたが、基本的には私が「実践テスト駆動開発」と「phpspec」をどう解釈したか、というような内容になっています。
45分あってもなかなか伝えるのが難しいテーマだったのですが、とりあえず時間厳守はできてよかったです(一部デモを飛ばしてしまいましたが)。
www.slideshare.net
いくつか補足を。
伝えたかったこと(あるいは上手く伝えられなかったかもしれないこと)
- 外から中へ、あるいは依存関係の上から下へ実装することで、上位が下位に要求するものが明確になる。
- setFoo()のような、プライベート変数をセットするだけのメソッドであっても、それは外から観測できる何かに影響を及ぼすはず(影響を及ぼさないのであればそのメソッド自体不要)。その外から観測できるものをモックを使ってテストできるれば、テストのためだけにgetFoo()を追加する必要は無くなる。
QAより
補完について
Specの書き方が特殊なため、Spec内ではIDEの補完がほとんど効きません。調べてみたところ、部分的には@mixin
アノテーションを使って補完させることができるようです。
PhpStorm & phpspec | Dimitrios Savvopoulos
しかし、この先のshouldReturn()
などは補完することができません。
タイプヒントについて
身内でリハをやったときに、「仮実装を作るときに何故タイプヒントを付けてくれないのか」という質問がありました。
// このような仮実装を生成するが public function toHtmlFromReader($argument1) { return '<p>Hi, there</p>'; } // なぜこのようにしてくれないのか public function toHtmlFromReader(Reader $argument1) { return '<p>Hi, there</p>'; }
これについては議論があったようですが結果的にphpspec自体ではRejectされ、extentionで実装されています。
- ciaranmcnulty/phpspec-typehintedmethods · GitHub
- [Question] type hints for generated methods · Issue #230 · phpspec/phpspec · GitHub
雑感
私は主にLaravel方面をWatchしていますが、ここ最近のPHPのフレームワークは、Composer、PSR、PimpleライクなDIコンテナの発明を経て、HTTPからのアプリケーションの分離みたいな方向に向かっているように思います。Laravel方面ではDDD、CommandBus、CQRS、Event Sourcingといったキーワードが注目されているようです。
そしてこれは、Rails likeなアーキテクチャからの決別でもあります(Railsがダメだというのではなく、PHPでRailsの真似をするのは無理があるという意味です)。
このような方向性に、phpspecはマッチしているのではないかなという気がしています。