>>650
いい事言ってだんろうけど、わかりにくい。わかりやすくお願いします！

あーわかった。
ようは、テストもできねーようなコード書くなということか。

テストできるぐらいの役割に分割しないとね

テストがしにくいコードってのはあるし、
テストをする意味が無いコードもあるんだよ。

一連の処理の中から冗長なコードを取り除いていくと
最終的にはコードというより定義に近くなる。

PHPのスレだからまあ、WordPressのは例を出すと、
wp_config.php これは一応PHPのコードだろ？
だけどこれをテストする意味が俺にはわからない。

設定ファイルでもない限りここまで定義のみに
できることはないけどそれでもテストする意味あるのか？って
思えるほど減らすことは出来るよ。

テストは後付で加えるものじゃない。
テストが出来るようにコードを書いていくんだ。
テストがしにくいと感じたら、テストを書く技術を磨く前に
テストがしやすいコードを書く開発技術を身につけるんだ。

>>655
（釈迦に説法ではありますが）RESTfulな設計思想で、エラーを発生させた場合にはエラーメッセージと共に
200以外のHttpステタースコードを投げるのは、異論はないと思います。

論点としては、「RESTful」な設計だとしても
エラーを発生させるような処理を確認するテストの場合に、
エラー発生を「HTTP status code等」でテスト結果を確認すべきか否か？
というところを言いたいのだと思いますが、、、、ここは議論の余地があるかと思います。

> そのエラーを最終的に400としてクライアントに伝えるというのはただの定義でしかない。
現状、クライアント側の実装でも、
「ステータスコードを見て処理を振り分ける」処理があるため、
テストをやっておいた方がいいのではないかと思った次第です。

>>648　についてですが、
testActionなどの後では、$this->controller　でインスタンスに
触れるようですが、、、 responseの内容は相変わらず取得できません。

>>656
やらないよりはやったほうがいいけど、意味が少ないというだけ。
そして、費用対効果まで考えるとそこまでやる意味ないんじゃないってこと。

なぜなら400を返すまでのコードが正しければ絶対400返るでしょ？一回確認すれば十分じゃない？
その400を返すコードは400を返すという仕様そのものが変わらない限りもう変えることはないでしょ？
それよりも複雑なのは400を返すまでの仮定であってその仮定が正しければ400返すでしょ？

そういう難しくもなく安定したコードのために、どうやってテストをすればー
なんて言うのなら、やっても時間がかかるだけで効果が無いと思うよ。

> 現状、クライアント側の実装でも、
> 「ステータスコードを見て処理を振り分ける」処理があるため、
もしかしてサーバーとクライアント一緒にしてテストしてない？
サーバー側の実装がどうであれ、400が返って来た場合のテストをすればいい。
だから400を返すだけのアプリ（モック）を使えばいい。
もっと言えば、クライアントだけで400が返って来たかのようにエミュレートさせれば
クライアントだけでテストできる。

どんなものでもテストしてやるぞ。ではなくアプリに手を加えてテストが簡単にできる
ようにするというのはこういう話。

>>657
引き続き、お付き合いいただきありがとうございます。
全体的なテストの思想、手法のお話しについては概ね同意いたします。
（クライアント側はSinon等を使っており、おっしゃるようなテストを書いております）

ご教示いただいている、お話しについては
「○○のようなテストはやるべきか、やらないべきか？」という形に収束しつつありますので、
スレに添う、単純なCakePHPの
「○○の実装の方法は？」というような部分について引き続き、お知恵をお借りできれば幸いです。

>>658
無駄な努力を頑張れやｗ

自己解決しました。
ありがとうございました。

先の例では、
$this->testActionのあとに
$this->assertEqual( 400, $this->controller->response->statusCode() );
$this->assertEqual( "something", $this->controller->response->body() );
$this->assertEqual( "json" $this->controller->response->type() );
のような形で対応できました。

お騒がせしてすみません。

クラス名も書かず$this $thisって・・・メソッドで判断できるからまあいいけど
問題にしてるクラスが何かってことくらい明確に書いたほうが回答者が質問の意図わかりやすいと思うの

あとRESTfulかどうかってステータスコードの扱いと何か直接的な関係あるの？
ステータスコードを適切に設計するのはREST以前の問題でしょうに

PDOでCake風に使えるライブラリを書こうとしたけど、面倒で止めた

>>666
cakeを使おうと思わないのは何故なんだろう？

>>667
Cakeだと規模が大きくなりすぎるし、ファイル数も多い。
それに既に運用しているサイトだと、
Cake使わないほうが静的ファイルとの共存がしやすい。

俺、人の作ったcakephpとか触ったことないんだけど、みんなは、DB設計とかめちゃくちゃでも我慢してその上からコードを編集するの？

DB設計？モデルのことか？
プラグインなんか使う時は自分のやり方と違うから戸惑うけど、
気にせずに編集していくな。

引き継ぎ案件の話なんか？

DBの命名規則がよくわかりません。
例えばユーザテーブルを「users」という名前でつけたとして、
ユーザが所持しているアイテムを管理するテーブルを作りたいとします。
そういう場合は

user_items
users_items

どっちの名前が適切なんでしょうか？

>>673
なるほど。
関連するテーブル名を連結させる必要はないんですね。
ありがとうございました。

>>671
引き継ぎ案件。
自分で昔作ったサイトとかもリニューアルする時、DBが複雑になってる時があって構造を直すんだけど相当手間だし、バグの原因になる。

こういう場合はみんなは
そのまま使うか、構造を変えるかどっち？

引き継ぎで、その後のメンテナンスの必要性が明確じゃない時は
なるべくそのままにしておく。

長期間の保守契約も含めた場合は話は別。

自分のサイトなら極限まで自分の好きにする。
じゃなきゃ自分でやる意味なくない？

>>677
ありがとう！

どういたしまして

>>679
誰だよお前ｗ

>>680
俺だよ！ 誰なのかあててみ！

>>681
俺かよ！マジかよ！ざけんなよ！

いや、ここは俺が。

ようじょ、ようじょ

>>685
1レコードそのまま取れなかったっけ？

cakephp1を、そのままcakephp2にしてくれと言ったら、いくら取る？
俺なら最低20万円。

>>687
まぁ規模によるよね。

俺も今 php4 + CakePHP1.1 で稼働しているサイトを php5.4(以上)のサーバーで
稼働できるように頼まれるかもしれない。

工数が全く見えないんだけどどうやって見積もり取ればいいんだろう。

規模もだけど現在のコードによる。

cakephp2を考慮して正しく書かれたコードと
全く考慮しない上に、間違った使い方ばかりした
汚いコードでは100倍ぐらい差がでても不思議ではない。

>>690
移行ではなく、全部最初から作り直しの工数を見積もればいいよ。

仕様を0から考える時間 or 現在のシステムを理解するのにかかる時間
　+
0から開発した時の時間。

決して、今あるコードを再利用できるから
開発時間が短縮できると思ってはいけない。

再利用できるように使えるように作られたコードであれば再利用できるが、
使えるかもしれないというコードは、基本的に使えない。

問題は、自分が過去に作った場合だな。
蔵からしたら「お前が作ったものを新しくするだけだろ？」
ってなもんで、予算をとってもらえないことが多い。

だったら諦めろって話だが、そこで終わると仕事に繋がらないわけで、
結局は安く請け負ってしまうんだよな

>>691-693
おぉ、色々ありがとう！
参考にさせてもらう。

これ、たぶん、断るわｗ

>>693
そういう理解の客って、そもそもCakePHPを新しくするって発想すら出てこないんじゃないの？
目の前には動いてるプロダクトがあるわけで、やって欲しいのは機能の追加とかであって、
機能は増えないし変わらないけど、CakePHP2にするってことじゃないと思うんだが。
逆にCakePHP2にする事の意義を知ってる客なら、
それが簡単じゃない事も知ってるはずだと思った。

>>695
「もっと動作を早くしてほしい」とか「サーバを変えたい」って場合がある。
または、自分がCake2用の開発に切り替えてて、
ライブラリもCake2用に作っている・使用している場合とか。

つまり、「現状より良くしたい」という要求に対して
「開発方法を変えないと出来ません」
ってなったら客も怒るだろ？こっちの事情はともかくとして。

ずっと1.3系＆PHP4系を使い続けるならともかく、
技術の進化と客の要求に対応するなら、
どこかで折り合いをつけなければいけない。

古いとセキュリティがどうのこうの…とか言ってみれば

cakeの1系->2系なんてほとんど互換性ないだろ。
バージョンアップのメリットないから。

>>696
開発方法を変えるなんて言う必要ないよ。
勝手に変えればいい。
どうせ客に言っても理解できない。

>>696
> 技術の進化と客の要求に対応するなら、
> どこかで折り合いをつけなければいけない。

なんか他人のせいにしているように聞こえるけど、
それ、技術力がないからだから。

君に足りない技術はね。今のコードを
新しいコードへ連続的に変化させていく技術だよ。
どうせ、今のを捨てて書きなおすことしか思いつかないんでしょ？

この変化させていく技術力があれば、1系でも2系でも動くコードがかける
PHP4系でもPHP5系でも動くコードがかける。
動かないコードを動くように変えることが出来る。
古いコードを新しいコードから利用できるように出来る。
新しいコードを古いコードから利用できるように出来る。

今の君は、このようなことをするのに何が必要かわからず
またわかったとしてもそれを実現するだけの力がない。
ゴールを見据えてそこまで至るルートを見つける力がない。
ルートがわからないからいつまでたってもゴールに辿りつけない。