元スレ【PHP】フレームワーク CakePHP 17ホール目【v2.4】

php覧

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

501 = :

さっぱり意味が分からん

502 = :

例えば「足し算」ていうメソッドを作成したとする。
これは引数に例えば「1と2を入れると3が返る」というもの。

1「テストを書かないやりかた」

こんな簡単なメソッド、どうやってもミスるわけない。
とりあえず作る。最初に動くか確認する。
動いた・・・終わり

2「テストを書くやりかた」

「1と2を入力すると3が返る」というテストを書く。
開発しながらテストを走らせて正常か確認する。
テストが異常なら、異常がなくなるまでプログラムを修正する。
これをずっと繰り返す。

3「テストを先に書くやり方」

2のテストを先に書く。メソッドは空からスタート。
テストが通るまで開発を行う。

504 = :

上司がテストケース書いて、部下にそれに合うようなコードを書かせるってのなら良いと思う。

ただcakephp1が2になったりするとテストも書き直しだよね。
結局テスト書いてもそれ以上にプログラムの進歩が速いような気もするんだよね。

ちなみにヤフーとかって10年前くらいにcgiをphpに書き直したみたいなこと聞いたけど、あれ以来書き換えてないのかな。

それとも地道に書き換えまくってるのかな？

505 = :

>ただcakephp1が2になったりするとテストも書き直しだよね。

いきなりスパン長い話になってね？

ビジネスロジックまで全部変わるわけじゃないんだからテストコードも一部はそのまま使えるでしょ
テストコードまったくなしに書きなおすよりはいくらか書きやすいと思う

506 = :

>>500の説明で合ってるんだが、何がわからないのかわからない

507 = :

>>506
ありがとう。そういうメリットもあるんですね。

>>506
わからない人にとっては全くわからないんだよね。テストケースのメリット。


俺、gitもテストケースも使ったことないというか使えないので勉強します。

508 = :

なんだかんだ言って教えるのなw

509 = :

経験ないとわからないかもしれんね
愚者は経験に学ぶと言うけど人間なんて全員愚者だから、がんばって経験を積もう

510 = :

>>496
こういう >>493 時に必要になるんだよ。

例えば1日の区切りが0時じゃなく4時なサービスがあるとしよう。
DateTimeオブジェクトや日時の文字列を受けて、何日かを返すメソッドがあるんだけど、
中身を見たらこりゃひどい実装だなという時、
テストがあれば、中身を書き換えても同じ結果を返す実装にできたとわかりやすい。

511 = :

お前ら俺が以前テストの質問した時はスルーしたくせに
テストの話題で盛り上がりやがって

512 = :

>>511
たぶんそれから必死で勉強したんだよ

513 = :

>>510
>中身を見たらこりゃひどい実装だなという時、
>テストがあれば、中身を書き換えても同じ結果を返す実装にできたとわかりやすい。

ここが想像できないんだよ。中身（モデル？）が酷い実装っていうけど、
前は動いてたんだよな？それを変更する時に「酷い」が分かるんだろ？

なら、テストも書き直しだと思うんだよ。俺も>>504と同じ疑問を持ってる。
Cakeのバージョンアップではなくとも、仕様が変わればテストも変わるでしょ。

514 = :

０か１で考えてんな
少なくとも単体テストしやすいように設計してれば
仕様を変えた部分の他に影響がないことを保証しやすいんじゃないか


テストが書いてない誰かが作ったソフトウェアを改修する時に
あっち変えたらこっち動かなくなったよみたいな経験ない？

515 = :

んじゃあ次はgitってなんなのよ？

516 = :

>>515
俺も思うな。
一人で開発したことしかないからか、
前に戻したくなることなんてまず無い。

毎回、add、commitする手間の方が面倒な気がするけど。

ただ、いつでも何処にでも戻せる安心感ってのは大きいのかもしれない。
dropboxでも戻せるけどどこに戻せば良いのかすらわからない。

517 = :

>>513
別人だけど、中身ってコードのこと言ってるんだろ。
テストが完璧な仕様を表したものだと仮定すると、
テスト通りに動く限りは、実装コードはいくら変えても構わない、という理屈。
テストコードの方も変える必要がない（というか、変えたら同一の保証ができなくなる）。

もっとも、リファクタリングの過程で、新しいクラスやインターフェースを追加、とかなることが多いから、
その場合は、テストも変えていく必要はあるけど。

518 = :

バージョン管理してないとかマジか
まあ趣味で小規模のものならそれでもいいのかな…

519 = :

>>516
一人で開発を数年やってるが仕事でも個人サービスでもgitは重宝してる

過去ログとして何をやったかが残ること。
複数同時に機能開発ができること。
gitなしにはもう生きられない。

テストはControllerのテストは書かない。
それより下位層は書いてる。
自分が書いたコードを忘れたころに重宝してる。
他の機能実装のために、さらに下位層を変更したときに重宝してる。

デプロイツールもなしには生きられんな。

520 = :

>>518
残念ながら商用で10以上の製品を扱ってるんだ・・。

gitの前にSubversionを勉強したこともあったけど、
バージョン管理の利点があまり思いつかないんだよな。バックアップ以外で。

マイナーアップデートしてそれをgitで管理する程度ならいいだろうけど、
開発してたら頻繁に更新するわけだろ？コード間違えも多々ある。
なのに、どのタイミングでadd、commitするか分からんし、
毎回してたら515が言うように面倒だ。

521 = :

>>514
例えばこの2ちゃんの掲示板。
名前とメールアドレスと本文入れて投稿すれば掲載される。
この一連の処理が正しく行われるかのテストを書くわけだろ？

で、そこに「画像を追加できる」という機能が加わったとする。
コントローラーとモデルとビューにコードを追加し、テストも書き直すよな？
なら、またテストのやり直しだ。

522 = :

>>521
テストにもいろいろ種類があるが、ここで書け書け言われてるのは、
単体テストと呼ばれるやつな。

で、単体テストの場合、一連の処理をテストするんじゃなくて、
機能単位でテストする。
俺も理解は甘いから、機能単位と言い切って良いのかわからないけど。

なので >>510 のようなメソッドは、戻り値だけに着目すればよくて、テストが書きやすいんだけど、
コントローラーのテストはちょっと書きにくい。
コントローラーのメソッドはアクションで、実行されたあとの結果がいろいろあるからな。

523 = :

>>521
あえて掲示板ということで、CommentsControllerのaddメソッドのテストで考えてみると

1　必須項目を省いてPOSTしたら、書けてない事
2　書き込み成功していいPOSTなら、書けてる事
3　名前を省略したら「nobodyさん」になる事

もっとあるとは思うけど、addメソッドのテストとして、こんなのを確認するテストを書いたとする。

「画像を追加できる」機能が必須項目じゃなければ、「画像を追加できる」を実装した後も、
このテストは3つの部分は期待通りに動いてることを確認できると思う。
で、画像を追加する投稿についてのテストをいくつか追記して、機能追加が完成できる。
この場合あくまでテストは追記だから、テストは書き直しとは言わないと思う。

画像が必須項目だったとしたら、1と2は書き直しになっちゃうだろうけど、これも微修正って範疇じゃないかと。

525 = :

>>523
物凄く分かりやすい！参考になった。
つまり、その1～3をこれまではブラウザでいちいち実行してたのを
テストコードさえ用意しておけば、自動で成否を出してくれるって事だよね？

それならテストを追加する意味もあるし、すごく便利だと思う。

526 = :

>>525
伝わったようで何よりだけど、あげておとすようで悪いが、
質問してた人が言ってたようなデメリットもやっぱりあるよ。

実装が大きく変われば、さすがにテストも修正というより書き直しになるし、
あとさっきも書いたけどコントローラーはテスト書きにくい。
仕様変更で実装が大きく変わりやすい箇所でもある。

あと >>523 この例でいうと、「画像を追加できる」機能を追加した際、
ぶっちゃけテストなんてなくても1～3は壊れないような実装になりそうな気がすごいする。

俺としては >>510 のような、ユーティリティ的なライブラリが、テストも書きやすいし恩恵も多いと思う。
実際困ったから書いたんだけど、時間というテストがめんどくさいデータで、
結局動作確認するには、4時丁度とその前後や、逆に0時丁度やその前後を引数に、呼んでみるしかないから、それってテストコードだしな。
で、ユーティリティだからサービスのいろんな箇所で呼ばれてて、ミスったときの影響範囲も広い。
なので、テストコードがないと、修正に及び腰になってしまう。

527 = :

>>526
なんかよく分からなくなってきたな・・・。
コード書いて「こういうイメージ？」って聞こうとしたんだけど、
どう聞けばいいからすら分からず、固まってしまったよw

528 = :

ここはなんのスレですか？

529 = :

スレタイ読めないの？CakePHPのスレですよ？
ちなみにCakePHPにテストという機能がちゃんと用意されてますよ？
だからその事について話し合っているんですよ？

530 = :

>>529
くわしく

531 = :

>>530
http://book.cakephp.org/2.0/ja/development/testing.html

532 = :

>>526
テストコードがないと及び腰ってのすごくわかる。
自分が作ったコードですら触りたくないもん。

533 = :

では、先生方次は最近よく聞く
composerについて教えて下さい。

534 = :

あとで知ったかで話すから、ちょっと勉強する時間をくれ

539 = :

>>538
なるほど、さんきゅー

546 = :

WordPressが記事URLのルーティングを管理画面から変えられるけど、
あんな感じにできれば便利だなとは思う

547 = :

確かにそうだよな。
もっと初期段階でモデルにアクセスできる仕組みのほうがいい気がする。
他のFWとかのプロセスってこの辺りどうなってんのかな。
俺はCakeしか知らないから。

548 = :

>>547
全体のローダーとルーティングで制限がかかるローダーはタイミングが別なものが多いよ
前者でモデルの読み出しができれば使える感じ

550 = :

うん、行ける気がする

で、>>549 こそ何が問題なの？

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ

類似してるかもしれないスレッド

• 【PHP】フレームワーク CakePHP 16ホール目【v2.4】 (1001) - [98%] - 2014/3/3 3:00
• 【PHP】フレームワーク CakePHP 15ホール目【v2.2】 (985) - [96%] - 2013/9/7 8:30
• 【PHP】フレームワーク CakePHP 14ホール目【v2.1】 (1001) - [96%] - 2012/12/3 19:16
• 【PHP】フレームワーク CakePHP 13ホール目【v2.0】 (995) - [96%] - 2012/4/23 21:16 ○
• 【PHP】フレームワーク CakePHP 17ホール目【v3α】 (955) - [95%] - 2016/11/15 20:45
• 【PHP】フレームワーク CakePHP 19ホール目【v3.3】 (844) - [95%] - 2023/2/2 14:30
• 【PHP】フレームワーク CakePHP 11ホール目【v1.3】 (1001) - [95%] - 2011/6/30 22:32
• 【PHP】フレームワーク CakePHP 10ホール目【v1.3】 (1001) - [95%] - 2011/2/13 8:32
• 【PHP】フレームワーク CakePHP 9ホール目【v1.3】 (1001) - [93%] - 2010/11/1 2:53
• 【PHP】フレームワーク CakePHP　7ホール目【v1.2】 (1001) - [92%] - 2010/3/18 1:18 ○
• 【PHP】フレームワーク CakePHP 12ホール目【笑】 (1001) - [92%] - 2011/11/8 7:01
• 【PHP】フレームワーク CakePHP 8ホール目【1.3】 (1001) - [91%] - 2010/7/22 22:16
• 【PHP】フレームワーク CakePHP　6ホール目【v1.2】 (933) - [90%] - 2009/8/19 2:06 ○
• 【PHP】フレームワーク CakePHP　5ホール目【v1.2】 (985) - [90%] - 2009/3/7 4:53 ☆
• 【PHP】フレームワーク CakePHP　4ホール目【v1.2】 (1001) - [90%] - 2008/12/19 21:06 ○
• 【PHP】フレームワーク CakePHP　3ホール目【本命】 (1001) - [84%] - 2008/6/19 7:19 ○