２４時間CakePHP

CakePHP 2.0.3 が焼きあがりました（訳）

和訳, CakePHP2.0, Test Suite

訳

このCakePHPの新しいバージョンは2.0ブランチへの安定性の向上と、PHPUnit 3.6の完全な互換性、PHP5.4のサポートをもたらします。

CakePHPコアチームは迅速にCakePHP2.0.3*1が利用可能になったことを誇りに思います。前のリリースからPHPの世界に多くのことが起き、この新バージョンにはPHPフレームワークの進化し続ける世界に適応するために必要なすべての変更が組み込まれています。

大きな変更があったうちの一つは、PHPUnit 3.6が安定版になりPEARインストーラを通したデフォルトのバージョンとなったことです。この変更は多くの開発者にとって驚きとなりました。PHPUnitの主要な変更により開発者はCakePHPの組み込みテストスイートを実行するのが難しくなりました。PHPUnitの3.5と3.6の両方のバージョンで問題が起きないように2.0.3が確実に実行できるように必要な変更を加えました。

全ての出力がPHPUnitに吸収されWEBテストページやCLIテストのどちらでも表示されないということが多くの人が単体テストを書く時に気づくであろう大きな違いとなります。このやっかいごとを乗り越えるには、CLIインターフェースを使っているときに--debug修飾子を使ってください。

２番目の良いニュースはPHP5.4-rc1が利用可能になったことです。このPHPバージョンに対する私たちのフレームワークをテストするのに時間をかけ、自動テストを実行中に発見された多くの細かい警告(notice)や問題を修正しました。もしあなたが早くも5.4に飛びついているとすると、CakePHPがその中でスムーズに実行できるフレームワークの一つと考えることもできるでしょう。

2.0.3では合計で、66のコミットがあり、32の問題が解決されました。変更ログページ*2で完全な変更のリストを見ることができますが、以下は2.0.3でされた変更の簡単な要約となります:

• PHP5.4でのスムーズな実行
• RESTを用いたコントローラのテスト
• DboSource::insertMulti()で真偽値の正しい操作
• PHPUnit 3.6の完全な互換性
• いくつかのコマンドラインのbakeユーティリティの小さな問題の修正
• レスポンスの本文の前に送られるバッファ出力がある時のContent-Lengthの計算の修正
• UpgradeShellでの種々の向上
• DboSource::lastAffected()が正しい整数を返すようになった

CakePHPへの増え続ける関心に感謝します。コードとドキュメント両方に多くのプルリクエストを受け取り、この新バージョンを作成している話題全てに興奮を覚えました。あなた方全ての貢献がなかったら、CakePHPはなかったことでしょう。

後書き

Bakeryのリリースノートの訳です

http://bakery.cakephp.org/articles/lorenzo/2011/11/14/cakephp_2_0_3_out_of_the_oven

私的にですが、2.0.2まではPHPUnit3.6のサポートが無く、Jenkins(旧Hadson)がうまく動かせないなどして困っていたのでこの迅速なサポートは非常に有難いところです。

ドキュメントのほうでも、ロシア語が追加され、また多くのコミットがあり活気だっています。

勢いに衰えが見えないところが素晴らしいですね。

新しいマニュアルを翻訳するのは、元（cookbookのCakePHP <= 1.3)からコピーする部分も多く非常に簡単なので、是非参加してみてください。

＃あと、TransitionComponentをforkした人はさっさとpull requestを（

ツイートする

Permalink | コメント(0) | トラックバック(1) | 16:20

CakePHPとPHPUnit（訳）

CakePHP2.0, Test Suite, 和訳

この訳について

CakePHPのコアデベロッパーの中心となる、mark storyがCakePHP2.0のテストのフレームワークをSimpleTestからPHPUnitに変更するということについて、経緯とその有用性、移行についての悩みどころについて詳細な記事を書いてくれました。

元記事： http://mark-story.com/posts/view/cakephp-and-phpunit

この訳はその記事の対訳にあたります。

注意点

• 翻訳の記事をブログに掲載する許可は得ています。
• 英語力に不安がある人が翻訳してますので、英語が読める方は元記事を読むことを強く推奨します。
• （一応）個人的な記事ということで、ラフな口語訳をしていますが、割とフォーマルな英文だったので失敗してるかもしれません。許して！

対訳

CakePHP 2.0 の開発が進行中であるということについての最近のBakeryの記事で、既にSimpleTestからPHPUnitへの移行が進められていることが紹介されたよね。この決定についてのいくつかの理由と動機、あと長い目で見たときの利益について説明したくなったんだ。

どうして変えるの？

今現在、CakePHPのテストスイートには15,000以上のassertion*1と650以上のファイルがある。巨大なアプリケーションも簡単にこのような多くのテストケースを持つことができるよね。そんなサイズのコードベースに対する基礎的なテストスイートのフレームワークを変更するのは、ちょっとやそっとじゃいかない。SimpleTestからCakePHPが引越しするのを軽く決めたわけじゃないんだ。僕たちがPHPUnitに移行することを決めることになった理由がいくつかある。以下にそれを示そう。

• SimpleTestはE_STRICTに準拠してない。これはコードベースをE_STRICT準拠にすることを阻害する。幾千もの警告を切り抜けて問題とすべき箇所を特定するのは難儀な仕事だよね。PHPUnitへの移行によって、読み取るE_STRICT警告が少なくなると同時に、CakePHP自身ののE_STRICT警告を修正することが簡単になる。
• PHPUnitは継続的インテグレーションから自動化のビルドまで、大量の付属のツールを誇っている。これまでツールサポートの蓄積はPHPUnitに遅れをとってきた。そして、この転換によってCakeの開発者が素晴らしいツールのサポートを利用することができるようになるだろう。
• 今やPHPUnitはテストフレームワークのデファクトスタンダードだ。現在、Zend Fremework、Yii、他の数多くのプロジェクトまでもがPHPUnitを使っているよね。SymfonyとDoctrineは次のリリースでPHPUnitに移行することになるし。ブランドとシェアは明らかにPHPUnitが先を行っている。更に、新規開発者が（訳補：PHPUnitを使った）テストの使い方にすでに詳しいこともあるだろうから、CakePHPがPHPUnitに引っ越すことで、開発者を楽にできる。

だけど全てのテストがぐしゃぐしゃになっちゃった！

ユニットテストのフレームワークを変更することはとても痛みを伴う工程だ。PHPUnitとSimpleTestには内部で大きな差異がある。全てのCakePHPのテストをPHPUnitを使うように移行しなければらない。僕たちはこの痛みにとてもよく気づいている。僕たちの狙いは、テストケースがCakeTestCaseを継承さえしていれば、変化に気づくことさえないかもしれない、ということなんだ。僕たちは様々なSimpleTestとPHPUnitのassertionメソッドの相違を、僕たちができうる範囲でラッピングし適切に動作するように、試行錯誤して確実なものにする予定だ。joze_zapは既にfixtureを移植したんだけど、以前のものとは相違点がないだろうね。一番の大きな問題点はSimpleTestが提供していたMockクラスだ。MockオブジェクトはPHPUnitではかなり異なる実装で、この違いを覆い隠す簡単な方法はない。このようなことについて、移行ガイドにはセクションが設けられ、ユーザが書いたテストをどのように書き直せばいいかをカバーすることになるだろう。

カバレッジの向上

PHPUnitへの移行はコードカバレッジのレポートの作成に莫大な支援をもたらしてくれた。PHPUnitが提供する機能を使えば、コードガバレッジの生成はより早くなり、より多くの情報を提供してもらえる。PHPUnitを用いたコードガバレッジはテストケース中でロードされたすべてのファイルに関して報告するようになった。これでどのファイル・オクジェクトが連動しているかをより完全に捉えることができる。また、PHPUnitテストスイートは特定のコードの行をカバーしているテストメソッドを見つけ出せる機能をもっている。カバーされている行をマウスオーバーすると、どのテストがこの行に対して実行されるかを見ることができる。もちろんこれはtitle属性を正しく扱うブラウザーが必要なんだけどね。

僕はこれは巧みで素晴らしい機能だと思うし、これが示すのはPHPUnitに変更することによっていくつかの改善が得られるであろうということだと思うんだ。アプリケーションをアップグレードするにあたって、この変更は頭の痛くなる点になるだろうということを僕は真に理解している。だけどね、長い目で見れば、これは有益な変更になると思う。より良いツールへアクセスできること、より他のプロジェクトと同じ方式に従ったテスト環境こそが、長期に渡って報われるものとなると僕は感じている。

ツイートする

Permalink | コメント(0) | トラックバック(0) | 11:48