難しい状況を言語化する能力がコミュニケーション能力での重要ポイントだと思う。
もっと言語化するクセつければ、コミュニケーション能力向上になるんじゃないかな

render呼んだ後
すぐexit();
してる？

>>473
遅レスだが、ソースの頭にBOMを付けたら表示されるようになた。
が、viewのファイルは8Nで保存しておかないと、たまに悪さをするようだ。

>>502
もっと常識的な質問たのむ

>>502
してないよ

cakePHPのテスト環境だけど
SeleniumとSimpleTestの組み合わせが最強？

>>507
そっちのテストなら、ｾﾚﾆｳﾑだろうと手作業だろうとなんだって良くね？

ユニットテストをするのなら1.2から正式対応したSimpleTestって言うだろうけど。

ていうか、テスト駆動開発って面倒ですよね、時間がかかるけど出来上がり安定するのは確かだけど。

正確にはテスト駆動じゃないけど、
ある程度の規模になったら、ユニットテストをやらないなんて
考えられないよ。

修正があるたびに同じテストなんてやってられない。
それこそ時間がかかる。

なにこの寂びれぶり

んじゃ、おれがこのスレを潤わせてやるぜ
ビヘイビアって使ってる？

>>512
荒らしが去ったので落ち着いただけ。

CakePHPを使って、ようやくサイトを公開できた。
思ったより使いやすいね、CakePHP。

コンポーネント、ビヘイビア、ヘルパーの中では
ビヘイビアを一番使うな。

よくよく考えると、ソフトウェアの中心はモデル。
その中心の共通処理なんだからよく使うのは当たり前か。

>>515
ソフトウェアの中心はコントローラー
なぜならコントローラーはモデルとビューにも指令を出すが
モデルは、たいていコントローラを介してのやりとりになるから

そういう考えで行けば、よく使うのはコンポーネントじゃないとおかしい

>>516
アフォがあらわれた

うん。アフォだ。ワロタｗ

コントローラなんて所詮インターフェースに過ぎんよ。
実際の処理じゃなくて、ブラウザから引数を受け取って
それを少々加工してモデルに渡す。
またモデルから受け取ったデータを少々加工してビューに渡す。

流れとしてはこんな感じだね。

「ブラウザ」→「コントローラ（加工）」→「モデル（実際の処理）」→「コントローラ（加工）」→「ビュー（HTML出力）」

っていうか、このように作らないとテストがしづらいったらありゃしない。

SeleniumやCakeWebTestCaseがあるとはいえ、
コントローラを操作してのテストでは範囲が大きすぎる。
もっと小さな範囲でテストできるようにしないといけない。

一番重要な処理を最小限の大きさ（なるべく他に依存しない）で
テストすること考えれば、自然とこうなるはず。

ガソリン安いな～
これほど自民党の一党独裁の問題点が分かりやすい現象は無いなw

>>519
そうなんだ。だから本にもモデルのテストの方法しか書いてなかったんだ。
モデルよりコントローラーをテストしたいんだけど・・・ってずっと思ってた。

ということは、僕のプログラムの組み方がよくないんでしょうか。

>>515,>>121
さきほどはアフォと一言で片付けてしまって申し訳ない、2ch流の愛情表現だと思ってくれ

で、>>519のいうとおりアプリケーションの中心となるビジネスロジックについてはコントローラなどでは
なくモデル内で実装するべき。一番大切なテストはビジネスロジックであるわけだし、モデルに集約して
（かつコントローラとのｲﾝﾀﾌｪｰｽも疎結合にして）コアロジックを実装することでコアロジックを別システムに
再利用しやすくなるというメリットも受けられる。

なので、コントローラはある意味、テストをしなくても問題ないくらい「薄い」実装にするべきだし、コントローラ
内で繰り返しよく使う処理についてはコンポーネント化してあげたほうが、ユニットテストで品質を保証できるので
良いかと。

こんな感じで考えていますが、どうでしょう？

>>519
Seleniumこれだけあれば、全く十分なんだが
これ以外でテストしようとすればコストかかるだけやろ
どんくさい作業してんな、赤字やろ？

>>522
だから何ってかんじだが、それがどうしたんだよ
リファレンスに書いてあるようなこと、なんで必死に訴えてるのｗｗｗ

自演厨きたー。うぜえええ

Seleniumなんかでテストしたら時間（＝コスト）がかかるよ。
ブラウザを起動する為、そもそも動作が遅いってのもあるが、

Seleniumだといくつものモジュールが組み合わさった状態で
テストするしかないから、どこのバグがあるのか見つけにくい。

またデータの初期化などが出来ない。
途中で内部のデータを調べることも出来ない。

CakePHPにはSimpleTestでブラウザをエミュレートした状態の
テストもできるので基本はそれを使ったほうが良い。

Seleniumを使うとしたら、SimpleTestではできない
JavaScriptが絡んだ処理のテストぐらいだな。

リファレンスに書いてあるようなことなのだから、
間違いではないということだなｗ

>>522
アプリケーションの中心となるビジネスロジックて何？
どんなロジック？

一番大切なテストてどんなテスト？

>>モデルに集約して
（かつコントローラとのｲﾝﾀﾌｪｰｽも疎結合にして）コアロジックを実装

プラグインと違うの？

>>なので、コントローラはある意味、テストをしなくても問題ないくらい「薄い」実装にするべき

モデルとビューに命令出すのに薄い実装なんて物理的に無理
モデルはカラッポでＯＫ

>>526
ブラウザ上でテストするだけなのにモジュールとか関係ないしｗｗｗ
JavaScriptテストやるなら加工しないと出来ないだろｗｗｗ

内部のデータを調べるようなテスト時間かかるに決まってるやろ

また、例の嵐だな。

とりあえず言っておくけど、CIは糞だから、
糞スレでやってねｗ

>>532
たしかに！

>>522
日本語でおｋ

なんか、CI普及の為（？）にわざとアフォなことを言っている気がする。
いや、まて、わざと悪い例を出しているのか？

まあ、訂正している俺は考えをまとめられていいけどな。
（そして訂正している文を見て学習する人もいるだろう）

> モデルとビューに命令出すのに薄い実装なんて物理的に無理
> モデルはカラッポでＯＫ

コントローラが出す命令はすごく小さなものだよ。
モデルに対して、「データ取って来い！」「書き込め！」「削除しろ！」
そして、「複雑な一連の処理をしろ！」

前三つは、CakePHPの自動生成コードでも書いてあるから
簡単にわかると思うけど最後の「複雑な一連の処理をしろ！」を
モデルに書くべきってことをわかってない人が多いんだよね。
複雑な一連の処理をコントローラに書いてしまう。悪い例だ。

>>537
テストのことを考えていってんの？俺はテストはブラウザでしかしないからｗ

テスト中心に設計するならモデルに詰め込めるだけ詰め込めばいいんじゃね

>>537
複雑な一連の処理を具体的に述べよ
はなしはそれからだ

where が入るような条件文はモデルに書けばいいの？

>>537
モデルにもっていっていいのは
どこからどこまで？

>>537
いくら給料もらってんだよ
俺はＰＨＰプログラマで36万円

　
　
　
モデル上で別のモデルのデータ取得できなくね？
　
　
　

>>542
どこまでをモデルでやるかは結局設計しだいだけど、

>>541
ユーザーがフォームからの条件入力。URL形式での条件入力
、つまりコントローラのアクション関数の引数に入る場合。

その引数をもとにモデルを呼び出すわけだけど、
このときのモデルの関数は汎用的なfind関数でもいいし、
もっと簡単に扱いたければ、モデルに専用の関数を作って呼び出す。

汎用的なfind関数を使う場合には、array('key' => '= ' . $value)なんて
条件データに加工しないといけないよね？ これがコントローラの処理。

モデルに専用の関数を作る場合、もっと簡単に使える関数にするね。
もちろんその場合、モデル内部でfind関数を使うことになるだろうし、
そのための条件の加工もモデルに書く。

ユーザーの入力した条件が、POSTでくる場合は、
$this->dataから条件を作り出す所までもうちょっと
コントローラでやる仕事が増えるだろう。

それでもコントローラの処理（モデルを呼び出すところまで）はこれだけ。
俺ならこのように作るよ。

あとモデルから戻ってきたデータを、ビューで使いやすいように
単純化するのもコントローラの仕事だね。

>>544

> モデル上で別のモデルのデータ取得できなくね？

モデル上で別のモデルのデータを使用したいと思ったとき、
その二つのモデル間には関連性がある。

つまりアソシエーションを定義している。
アソシエーションを定義しているのなら、
モデル内で、別のモデルを呼び出すことが出来る。

Model1の中から、$this->Model2->findAll(); 感じで呼び出せる。

>>545
モデルから戻ってきたデータを、ビューで使いやすいように単純化

数字にコンマ付けたりとか？

>>546
わざわざアソシエーションするの？
いつも結合されて重くなるじゃん

>>547
それは見た目を変えるだけだからビューの仕事だろうね。

モデルから戻ってきたデータとは、汎用的なfind関数の場合、

$data => array(
　モデル名 => array(
　　フィールド名1 => 値1,
　　フィールド名2 => 値2,
　　フィールド名3 => 値3,
　)
)

こんな値が返ってくる。もちろん、これをそのまま
ビューに渡してもいいんだけど、これじゃあビューで使いにくい！
って言う場合加工する。

そんな場合あるのかって？ 余り無いだろう。
そう、だからコントローラの仕事は少ない。

モデルから取得した値をビューに渡す$this->set(・・・) は
コントローラの仕事ね。