【TDD】テスト駆動開発【TestFirst】

**デフォルトの名無しさん** · 2010/09/19(日) 21:26:12

テスト駆動開発 (test-driven development; TDD) についてﾏﾀｰﾘ語りましょう

ツールについては別スレで
テストツールについて語るスレ 2
http://hibari.2ch.net/test/read.cgi/tech/1208013693/

**デフォルトの名無しさん** · 2010/09/19(日) 21:46:07

>>1
よろしければTDD入門によいWABサイトや、
書籍などの紹介を頼みます。

**デフォルトの名無しさん** · 2010/09/19(日) 21:49:44

日本人にテストファーストはなじまないと思うよ。
作りながら考えるPGが多すぎる。かくいう俺もそうだけどｗ

フレームワークが出来た後なら余裕だけど、
フレームワークを作ってる最中は作業に水を差されてるみたいでなんか辛い。

**デフォルトの名無しさん** · 2010/09/19(日) 22:22:46

プロトタイプ作ってる間はテストファーストはなあ。
フレームワークありきでTDDは効果出るよね。

フレームワークもある程度固まったらテスト書かないとふあんだけど。

ドラフト状態部分のフレームワーク部分はテストを後に回してもいいキガス。

てか設計に掛けられる時間が少なかったり、
複数人で設計をレビューしながらまとめる文化がないよね。

**デフォルトの名無しさん** · 2010/09/19(日) 23:05:17

ここは天才チンパンジーのアイちゃん（ｒｙ

**デフォルトの名無しさん** · 2010/09/19(日) 23:48:40

>>3
作りながら考えるからこそ
テストファーストになるんじゃないのか？

**デフォルトの名無しさん** · 2010/09/20(月) 01:28:15

最近TDDじゃなくてアレだよね
名前なんていうのか忘れたけど
DDDだっけ？HDDだっけ？

**デフォルトの名無しさん** · 2010/09/20(月) 01:35:38

DDD: GNUのGUIデバッガ
HDD: ハードディスクドライブ

**デフォルトの名無しさん** · 2010/09/20(月) 02:18:41

RDDのことか

**デフォルトの名無しさん** · 2010/09/20(月) 08:17:43

テストコードって書くの楽しくないからどうしても後回しにしたくなるんだよな
どうすれば楽しくなるのかな

**デフォルトの名無しさん** · 2010/09/20(月) 10:22:31

>>6
関数書き始めたとき、その関数がどんな時にエラーを返すか
詳細に検討してないことは、ままあるな。
先に考えるのメンドクセ。

**デフォルトの名無しさん** · 2010/09/20(月) 14:18:37

ググって見つかった最初のページに
↓

以下は参考サイトのまとめ

○基本

[link]テスト駆動開発とPDCAサイクル - 開発者がテスト駆動開発をすると、生産性が上がる理由
[link]@IT - 「テスト駆動開発」はプログラマのストレスを軽減するか？
[link]テスト駆動開発やユニットテストを定着させるには

○実践

実際の開発では、すべてのコードに対してテストコードを書くなんてのは不可能。
どのコードに対してテストコードを書くと効果的か（価値があるか）、その判断基準の参考になる。

[link]リファクタリングとテストの関係(PDF)

**デフォルトの名無しさん** · 2010/09/20(月) 21:56:28

オライリーのビューティフルシリーズってどうなの？

ttp://www.oreilly.co.jp/catalog/soon.html
ビューティフルテスティング 978-4-87311-474-3 \\\\3,360 2010年10月

**デフォルトの名無しさん** · 2010/09/20(月) 23:44:18

>>1
スレタイにBDDもいれろ

**デフォルトの名無しさん** · 2010/09/20(月) 23:46:06

それは置いておいて、
webアプリ作る時ってプロトタイプを3日間とかもしくは2時間ぐらいで
モックとともにガゥーーーっと作るじゃん？

そういうのっていちいちBDDなんかで振る舞いや仕様を定義して・・・とかやってると
とてもじゃないが時間かかりすぎるんだけどどうしてるの？

**デフォルトの名無しさん** · 2010/09/20(月) 23:49:35

おまえ、まさかプロトタイプを本番に使ってないよな？

**デフォルトの名無しさん** · 2010/09/21(火) 01:10:31

え、、、、

ダメなの？

**デフォルトの名無しさん** · 2010/09/21(火) 01:33:37

おまwww

捨てるプロトタイプと、コア実装としてのプロトタイプが
あるとは思うけど、後者はちゃんと設計して作るもんだ。

説明用に2時間で作ったもんは捨てれ。

**デフォルトの名無しさん** · 2010/09/21(火) 06:55:26

趣味なのか仕事なのかでも違うと思う

が、趣味でも大型の変更は一回作って傾向見て捨てて
その経験だけ頭に入れて別途作り直したほうが結局は早いな
1回目のコードを大事にしようとすると歪が溜まるのは同じ

**デフォルトの名無しさん** · 2010/09/21(火) 09:53:02

プロトタイプを実践で使いたいなら導入時にテストをかいておきたいなあ。

**デフォルトの名無しさん** · 2010/10/11(月) 20:33:31

なんかテスト駆動開発を勘違いしている奴多くないか。
全関数をテストするわけじゃなく、ある程度の単位でまとめて、そこで外部とのI/F決める。
その単位でのテストが目的で、普通は仮にでもそこを決めてから、コーディング始めるだろ。
じゃなかったら複数人での開発なんかできないぞ。

**デフォルトの名無しさん** · 2010/10/12(火) 07:07:20

>>21
テスト駆動開発やテストファーストの「テスト」という単語が勘違いされてるからな
そのために、振る舞い駆動開発などというものもでてきているんじゃないのか？
ようするに

　「あれは(お前らが考えてる)テストじゃないんだ。振る舞いを定義してるんだ」

なんて

**デフォルトの名無しさん** · 2010/12/22(水) 04:02:54

設計や実装の不具合がないことを示すテストじゃなくて
とりあえず実装完了を示すテストだといってみたらどうだろう

**デフォルトの名無しさん** · 2010/12/22(水) 07:01:25

プリミティブ、配列、ツリーだけでインプットとアウトプットを
構成することを規約化したらエクセルドキュメントから
テストコードを自動生成できないかな

モックとテストファーストが満たせないか

**デフォルトの名無しさん** · 2010/12/22(水) 20:20:05

テストコードからExcelファイルを自動生成すればよくね、Apache POI辺りを使って

**デフォルトの名無しさん** · 2010/12/23(木) 10:05:36

テストコードからExcel吐いたりしている人はいるらしい

Cucumberみたいな自然言語使う流れもあるけど、あれは誰に見せるものなんだよw

**デフォルトの名無しさん** · 2010/12/23(木) 14:23:43

1.テストケース（ドキュメント）
2.テストコード
3.実装

でしょ？

テストコード書いてテストケース生成するのはまずいのでは？

**デフォルトの名無しさん** · 2010/12/23(木) 20:43:31

テストコードがドキュメントみたいな開発スタイルもある
1週間で作るとか1ヶ月とかのプロジェクトだとドキュメントなんて作ってられん

**デフォルトの名無しさん** · 2010/12/24(金) 01:55:26

それは俗にいう誤ったＴＤＤ、
カウボーイ・コーディングのアジャイルでしょ

アジャイルに関する実際の需要はそっちだったりする？ｗ

**デフォルトの名無しさん** · 2010/12/24(金) 06:57:25

安易に「誤った」なんて言っちゃうマヌケw

**デフォルトの名無しさん** · 2010/12/25(土) 14:32:58

テストコードからHTML生成やってみようかと思ったが
テストコード側が最悪に書きにくくなりそうだ
振る舞いのフローチャート化も本当に単純なことしかできそうにない

ttp://www.filebank.co.jp/filelink/133adb79503b26f344fad4fea1d0cf38

**デフォルトの名無しさん** · 2010/12/25(土) 14:52:11

>>31
Javaだったらすでにそういうツールありそうだな

**デフォルトの名無しさん** · 2010/12/25(土) 16:20:19

日本語のソースフォージにはなさそうだったから
立ち上げてみようかな。フローチャート図吐き出す案が思いついたら

**デフォルトの名無しさん** · 2010/12/25(土) 17:43:00

>31
JDaveにHTML reportってのは有る。

31 · 2010/12/27(月) 07:16:40

垂直に上から下への一本線のフローチャートしかおもいつかないや
シーケンス図っぽくしたら良いのだろうか

**デフォルトの名無しさん** · 2010/12/27(月) 10:19:51

ユニットテストなら生成→値をセット・実行→値をゲット→検証
ぐらいの短いサイクルだけで十分

**デフォルトの名無しさん** · 2010/12/27(月) 11:42:33

RSpecの本まだー？
早う日本語で専門書だせー-

**デフォルトの名無しさん** · 2011/01/17(月) 05:52:00

粒度の高い結合テストしてから粒度の低い単体テストしないと無駄が多いって
聞いたことがあるけど

粒度の低いクラスから作っていく印象があるTDDはどうなのよ

**デフォルトの名無しさん** · 2011/01/22(土) 20:49:54

ネタがないね

**デフォルトの名無しさん** · 2011/01/23(日) 20:54:27

Twitterとかじゃ盛り上がっているようだな

**デフォルトの名無しさん** · 2011/02/05(土) 08:30:07

Fit: Framework for Integrated Test

久しぶりにあさってみるか

**デフォルトの名無しさん** · 2011/02/05(土) 12:02:06

いい参考図書はないでしょうか？

>>12の@ITの記事を参考にやってみたけどどうもシックリこないので…
・まずテストを書いて…ってどこから書くの？
・テストを書くのは関数単位？クラス単位？外部I/Fのみ？
　外部I/Fのみが一番正しそうだけど、その場合別途ユニットテストも書くの?
　内部が複雑な場合くっつけた状態でモレなくテストするのって難しいのでは？
・どこまで書いたら終わり？できたコードをみると引数チェックのヌケモレとかチラホラと
細かく回すメリットは理解できるのですがやってみると
品質も実装効率もガタ落ちなのでなにか根本的に間違えてそうな気がします。

**デフォルトの名無しさん** · 2011/02/07(月) 11:01:02

別に無理してやらなくてもいいのでは？
隣の芝生が青いだけでしょ

**デフォルトの名無しさん** · 2011/02/07(月) 11:10:00

不慣れなうちは実装効率が落ちるってのは分かるけど
品質が落ちるってのは…

新しい事に手を出すのは、余裕のある時の方がいいと思うよ

**デフォルトの名無しさん** · 2011/02/07(月) 19:25:39

おいらはTDDやったことありませんが
TDDとかBDD のテストやスペックは
あとで細かい大量のテストを書くための布石ぐらいに考え
大雑把なものでいいというわけにはいかないの？

**デフォルトの名無しさん** · 2011/02/07(月) 20:12:43

>>42
UnitTestはクラスの振る舞いをチェックするものだから公開されているインターフェースを使ったときに正しい振る舞い（結果を生む）かどうかがチェックされればそれでいいのだよ
テストが足りないと感じるときは、起きてはいけないこと（異常なパラメータを渡したときの振る舞い）が予期した結果を生成するかチェックする

それで品質が落ちるってのは根本的に間違ったコードってことじゃんよ

**デフォルトの名無しさん** · 2011/02/07(月) 23:32:23

>>42
すごいわかる。自分も同じ気持ち。
なれるまでは、あまり効果でないよね。

**デフォルトの名無しさん** · 2011/02/08(火) 07:48:30

よくあるAnimal->Dog,Catなクラスのbark関数ってどうやってテストするの？
javaであればSystem.out.print("Mew");, C++なら cout<<"Mew"; ってのがちゃんと出てるかテストするような道具もＴＤＤツールにはあるのかな？

**デフォルトの名無しさん** · 2011/02/08(火) 08:40:12

>>48
他の言語はよく知らないけど、Pythonだとsys.stdoutを一時的に別のオブジェクトにすればprint文の出力結果を横取りできる。

import sys
from StringIO import StringIO
# 標準入出力オブジェクトをバックアップ
stdin_bkup = sys.stdin
stdout_bkup = sys.stdout
try:
　# 標準入出力オブジェクトをStringIOで置き換える
　sys.stdin = StringIO('dummy input text')
　sys.stdout = StringIO()
　# print文を使ったコード
　print("Hello")
　# StringIOから値を取り出して、expectedと比較する
　expected = "Hello¥n"
　output = sys.stdout.getvalue()
　self.assertEqual(output, expected)
finally:
　# 標準入出力オブジェクトをもとに戻す
　sys.stdin = stdin_bkup
　sys.stdout = stdout_bkup

Rubyならたしか$stdinと$stdoutを同じように置き換えればいい。
JavaもSystem.outを置き換えればいいんじゃないかな。

**デフォルトの名無しさん** · 2011/02/09(水) 00:44:31

>>48
テストしにくい、つまり設計がよくないということがテストできた

**デフォルトの名無しさん** · 2011/02/09(水) 00:46:33

一応、Javaでも可能。
うろ覚えだがこんな感じ
ByteArrayOutputStream out = new ByteArrayOutputStream();
System.setOut(new PrintWriter(out));
//テスト実行
String text = new String(out.getBytes());
assertThat(text, is("baw"));

**デフォルトの名無しさん** · 2011/02/09(水) 15:18:10

csvとかファイル受け取って処理するコードのテストって、どうかくの？

**デフォルトの名無しさん** · 2011/02/09(水) 19:19:09

自分ならファイルを情報を取得する部分と
その内容を処理する部分に分けて設計し個別にテスト。

**デフォルトの名無しさん** · 2011/02/09(水) 21:02:09

えっ

**デフォルトの名無しさん** · 2011/02/15(火) 14:58:24

テスト可搬性高＝コード最適化じゃないからね
リファクタリングも含めて
この辺りの誤解が未だにあるような気がする

**デフォルトの名無しさん** · 2011/02/15(火) 15:45:51

>>53のケースへの適切な対処法を具体的に聞きたいな
分けて作ったらどうダメなん？

**デフォルトの名無しさん** · 2011/02/15(火) 15:49:58

むしろ分けずに書くのはドシロウトだろ

**デフォルトの名無しさん** · 2011/02/17(木) 07:40:15

まぁ環境によるわな
メモリが少ない環境だと、ストリームから逐一取り出してゴニョゴニョしたいときもあるだろうし

**デフォルトの名無しさん** · 2011/02/17(木) 08:07:11

それでもわけるだろ

**デフォルトの名無しさん** · 2011/02/17(木) 08:10:58

分けねえよ
「ファイルを取得して目的の形式で返す」までが単一の機能だろう

**デフォルトの名無しさん** · 2011/02/17(木) 08:25:07

言語によるかもしれん
Rubyだと、なんかよくわからん細かさのメソッドが（ユーザーから隠されて）存在するほうが喜ばれる気がする
オープンクラス利用して手元で動作修正することがしばしば行われるので、クラスやメソッドがどでんと大きいと面倒

**デフォルトの名無しさん** · 2011/02/17(木) 10:34:31

>>60
ん？それが分けるってことじゃ？
①ストリームオープン
　　②-1 ストリームから一行取得して目的の形式で返す
　　②-2 目的の形式のデータをごにょごにょ処理して何かをアウトプット
③データがなくなるまでループ

**デフォルトの名無しさん** · 2011/02/17(木) 12:11:39

>>60
>「ファイルを取得して目的の形式で返す」までが単一の機能だろう
要求されているのが単一の機能だとしても、それを複数に分けてはいけないと
いうルールはない。
分けた方がテストしやすいのなら、分けるべきだろう。

**デフォルトの名無しさん** · 2011/02/17(木) 12:47:22

四の五の言わずにソース貼れや

**デフォルトの名無しさん** · 2011/02/18(金) 00:37:33

大抵はreaderとhandlerにわける

**デフォルトの名無しさん** · 2011/02/19(土) 12:18:19

結局公開インターフェースだけテストすればいいのかな
その辺のサジ加減がわからん

**デフォルトの名無しさん** · 2011/02/19(土) 12:55:17

よく言われるのは自分の不安がなくなるまでかな
これで大丈夫と思ったらテストなんて書かなくて正解
あーこんなときどうするんだろって不安に思ったらテスト書く

**デフォルトの名無しさん** · 2011/02/19(土) 13:28:24

それはちょっと違くねえか
TDD的に

**デフォルトの名無しさん** · 2011/02/19(土) 15:22:27

×不安になったらテストを書く。
○不安が出ないように事前にテストを書く。

**デフォルトの名無しさん** · 2011/02/20(日) 00:51:21.25

角谷さんの記事が参考になった
http://kakutani.com/20080216.html#p01

忍法帖【Lv=1,xxxP】 · 2011/05/11(水) 10:31:59.12

**デフォルトの名無しさん** · 2011/06/14(火) 11:09:22.79

フィクスチャって、テストデータのことだよね？違う？
ひとによってはsetUp()/tearDown()のことをフィクスチャといっているんだけど、どうなん？

**デフォルトの名無しさん** · 2011/06/14(火) 20:35:50.80

>フィクスチャとは、テスト・ケースのもととなるオブジェクトの集合です
http://www.metabolics.co.jp/XP/cppunit-doc/cookbook.htm

>テストコードにおいて、ある状態にオブジェクトを設定するためのコードを、テストの「フィクスチャ（土台）」と呼びます。
http://d.hatena.ne.jp/asakichy/20100405/1270437389

らしいから
>setUp()/tearDown()のことをフィクスチャといっている
でも問題なさそう

**デフォルトの名無しさん** · 2011/06/15(水) 10:29:49.07

むしろテストデータをフィクスチャとか、マジ素人

**デフォルトの名無しさん** · 2011/06/15(水) 13:18:41.30

Wikipediaに説明があった。
ttp://ja.wikipedia.org/wiki/XUnit

> テストフィクスチャ
> テストを実行、成功させるために必要な状態や前提条件の集合を、フィクスチャと呼ぶ。
> これらはテストコンテキストとも呼ばれる。
> 開発者はテストの実行前にテストに適した状態を整え、テスト実行後に元の状態を復元することが望ましい。

これじゃ何のことか分かりにくいなあ。

**デフォルトの名無しさん** · 2011/06/15(水) 18:50:16.06

知ってる人なら意味が分かる、ってやつだな
初学の人がこれ読んだだけじゃチンプンカンプンだろう

**デフォルトの名無しさん** · 2011/06/18(土) 23:25:11.37

> これらはテストコンテキストとも呼ばれる。

これで充分わかるだろ

**デフォルトの名無しさん** · 2011/06/22(水) 14:42:58.40

テストフィクスチャは言葉の意味にぶれが結構あって文化や人によって若干違ってくる。

例えばRailsだとテストデータをyamlで用意する手段があって、それをフィクスチャと呼んでる。

基本的にはテストするために用意するテストデータやオブジェクトのことだと思っておけば大丈夫。

**デフォルトの名無しさん** · 2011/06/22(水) 16:09:43.38

>>78
ちがうよ

**デフォルトの名無しさん** · 2011/06/22(水) 16:36:00.05

テストデータっていうよりか
テストの為のお膳立てじゃね？

**デフォルトの名無しさん** · 2011/06/22(水) 17:15:39.89

>>79
なにが違うか説明してくれよ

**デフォルトの名無しさん** · 2011/06/22(水) 17:32:04.40

コピーはゼロックスだがゼロックスはコピーとは限らないだろ

**デフォルトの名無しさん** · 2011/06/22(水) 17:42:11.76

そういう関係じゃないと思う
テスト用のデータなのか、テスト用のプログラムなのかって違い

**デフォルトの名無しさん** · 2011/06/27(月) 14:42:18.25

テストの前提となる環境データその他を指すんじゃねぇの

**デフォルトの名無しさん** · 2011/06/27(月) 15:01:59.49

何でもデータの一言で片付けるのは
開発者としてどうよ

**デフォルトの名無しさん** · 2011/06/27(月) 15:20:10.96

データなんだからデータでいいだろ
data =

**デフォルトの名無しさん** · 2011/07/02(土) 00:38:39.15

まあ、とりあえずTDDといったら、日本人ならt_wadaさんだな。

**デフォルトの名無しさん** · 2011/07/04(月) 17:02:36.68

t_wadaって実践が伴ってるんだろうか

**デフォルトの名無しさん** · 2011/07/04(月) 21:57:39.91

数年前にご一緒したことありますが、プラグマティックな方でしたよ

**デフォルトの名無しさん** · 2011/07/05(火) 11:28:38.99

>>89
それは実践が伴ってるという意味？
別に全部見てるわけじゃ無いけど、最近TDDでプログラミングとかバリバリしてるようには見えない。
実践が伴わなければ本とか記事とか書くなと言うわけじゃ無いんだが、どうもうさんくさい。

**デフォルトの名無しさん** · 2011/07/05(火) 17:09:05.74

だいたい名前が売れてる人は、実際には他人のコードなのに、そいつが書いたかのような事になっている。

**デフォルトの名無しさん** · 2011/07/06(水) 20:26:40.58

>>91
そんな事実みたことねーよ。

**デフォルトの名無しさん** · 2011/07/06(水) 20:36:51.52

ぶっちゃけ他社のソース見ることはないな
うち元請けじゃないし

**デフォルトの名無しさん** · 2011/07/13(水) 00:20:56.20

t-wadaは真心。
t_wadaは下心。
Twitterで流れていたネタｗ

**デフォルトの名無しさん** · 2011/07/13(水) 17:00:39.07

>>94
古いね。

**デフォルトの名無しさん** · 2011/07/14(木) 08:02:22.70

こんなしょーもないネタを事情通っぽく「古いね」とか言われてもなぁ。

**デフォルトの名無しさん** · 2011/07/14(木) 09:49:55.26

おまえらTDDについて話せよ。

ということで話題を投下。ちょっと新人にTDD教えるのにペアプロしようと思うんだがなにかいいお題はないかな。

言語はRubyで仕事はRailsだけど、とりあえずTDDについておしえたいのでWebアプリをお題にするのは避けようと思ってる。

定番どころだとボーリングなのかもしれんが、サンプルとしてあまり良い気がしないんだよな。

**デフォルトの名無しさん** · 2011/07/14(木) 11:22:03.40

別に構えてお題を用意する必要ないだろ
今までやってた業務のやつやらしゃいいじゃん

**デフォルトの名無しさん** · 2011/07/14(木) 22:29:28.39

だよなあ

**デフォルトの名無しさん** · 2011/07/15(金) 04:17:44.07

ここにいる人ってTDDBCとか出たり、テスト駆動開発入門の本を読んだりしないで
適当に実業務の中でTDDを覚えたり2chやWebの記事やblogなどで勉強した感じですかね？
少なくともTDDBCとかには出ていない雰囲気がする。。。

**デフォルトの名無しさん** · 2011/07/15(金) 12:53:11.73

ヒント：今までのTDDBCの参加のべ人数を推定してみよう

**デフォルトの名無しさん** · 2011/07/16(土) 00:39:49.48

あんなイベント出てるやつは「TDDBCに参加することでTDDをなんとなく理解をしている自分に酔ってる」と思う。
まあ、2chの練習も程度が低いので五十歩百歩だなｗｗｗ

**デフォルトの名無しさん** · 2011/07/16(土) 00:40:56.78

ああいう、オフのイベントに参加できるだけリア充だと思う。
俺には考えられない。。。

**デフォルトの名無しさん** · 2011/07/16(土) 04:16:36.95

reviewで充分だよな

**デフォルトの名無しさん** · 2011/07/17(日) 22:35:19.81

>>102
入り口はそれでもいいんだよ

**デフォルトの名無しさん** · 2011/07/19(火) 17:32:31.53

bootcampに参加する奴って、人脈を広げたい奴か、自分で書籍を読み通すことができない奴か、
暇人かのどれかでしょ。

**デフォルトの名無しさん** · 2011/07/19(火) 18:57:09.08

どうした、bootcampで小馬鹿にでもされたか？

**デフォルトの名無しさん** · 2011/07/19(火) 19:23:10.60

TDDBCを叩いてる奴は和田さんに相手にしてもらえなくて悲しい思いでもしたのか？

**デフォルトの名無しさん** · 2011/07/19(火) 20:35:24.16

これは酷い

**デフォルトの名無しさん** · 2011/07/19(火) 21:19:32.09

TDDBC参加すらしたことのない小者が2chでTDD？ﾌﾟｹﾞﾗ。

とかいいながらそれは無いわ…。引くわ…。

**デフォルトの名無しさん** · 2011/07/20(水) 11:50:04.76

なんつーか、マ板でやれお前ら

**デフォルトの名無しさん** · 2011/07/20(水) 21:38:39.32

まずは、外に出て人に会うことから始めろよｗｗｗ

**デフォルトの名無しさん** · 2011/07/20(水) 21:54:26.24

堪忍して

**デフォルトの名無しさん** · 2011/07/28(木) 18:40:18.43

テストに関するオススメの良書教えて

**デフォルトの名無しさん** · 2011/07/28(木) 18:46:36.80

あげ

**デフォルトの名無しさん** · 2011/07/28(木) 21:01:34.98

良書はまだ無い、
原点のテスト駆動開発入門を写経するが吉

**デフォルトの名無しさん** · 2011/07/28(木) 21:21:52.42

テスト駆動開発入門は訳がひどいと書いてあるのが不安になるな
英語の勉強もかねて原著を読むか・・・

↓ここらへんの書籍ってどうなの？

基本から学ぶソフトウェアテスト―テストの「プロ」を目指す人のために
ソフトウェアテスト技法―自動化、品質保証、そしてバグの未然防止のために
ソフトウェアテスト293の鉄則

**デフォルトの名無しさん** · 2011/07/28(木) 21:47:37.60

本読んでTDDできると思ってるやつらおめでたすぎ。
TDDBCに参加しないと真のTDDは実践できない。

**デフォルトの名無しさん** · 2011/07/28(木) 22:09:02.48

釣りにすらなんねーだろ…ｗ

**デフォルトの名無しさん** · 2011/07/28(木) 22:09:20.82

宗教的で気持ち悪いな

**デフォルトの名無しさん** · 2011/07/28(木) 22:16:19.16

>117
テスト駆動開発入門は確かに読みにくいけど、コードを写経する分には問題ない
1回写経してみると読みにくさも気にならないと思う

ソフトウェア技法とかの本はどっちかというと、品質保証系のテストの本。
そっちはそっちで役に立つし、TDDに応用できないかと言えば色々できるけど、別の分野と考えた方がいいかも。
良書ではあると思うよ

**デフォルトの名無しさん** · 2011/07/28(木) 23:24:00.87

TDDは慣れるものじゃなくて、理解して実践する類のもの
写経なんかすんなよ　ケントベック泣いちゃうぞ

写経している奴は、ケントベックが
「他のTODOをやってみたが上手く行かないことが分かったので、先にこっちのTODOをやる」
などとさらっと書いてある部分はどうしてんだろう

**デフォルトの名無しさん** · 2011/07/29(金) 00:52:42.66

右も左も解らない状態でどうやって慣れるのさｗ

**デフォルトの名無しさん** · 2011/07/29(金) 20:43:51.15

テストって二つの意味があるんだよな。
設計をプログラムに落とすテスト駆動開発と。
品質を保証するテスト。

どっちもテストって名前ついているけど、
全くの別物だよ。

**デフォルトの名無しさん** · 2011/07/29(金) 22:55:13.75

そういうデベロッパーテスティングの意味を理解するだけでもTDDBCにいく意味はあると思うぞ。

**デフォルトの名無しさん** · 2011/07/31(日) 08:55:27.49

TDDについて語るスレなんだから、ここで語るんだよ。
TDDBCについて語るスレじゃねーぞｗ

**デフォルトの名無しさん** · 2011/08/01(月) 01:13:08.98

>117 読むなら
レガシーコード改善ガイド
+ パターン指向リファクタリング入門
でおｋ
補足資料としてリファクタリング, テスト駆動開発入門があればって感じだね
まぁ後、アジャイルソフトウェア開発の奥義, コードコンプリートなんかも気休めにはなるだろう。

"品質保証系のテスト"の話がしたいなら別だが。

**デフォルトの名無しさん** · 2011/08/02(火) 08:12:19.14

>>125
なんかもの凄く必死に見えるんだが、そんなにTDDBCの空席目立ったのか？

**デフォルトの名無しさん** · 2011/08/02(火) 15:00:00.36

ttp://d.hatena.ne.jp/absj31/20110731/1312209896
見たけど、なんでt-wadaがTDDのエバンジェリストっぽい立ち居地にいるのかわからん。

**デフォルトの名無しさん** · 2011/08/02(火) 15:25:14.87

>>129
優秀かつ積極的にTDDを広めようとした人が他にいなかったからじゃないか?

**デフォルトの名無しさん** · 2011/08/02(火) 22:30:09.48

いっつもt_yanoとごっちゃになる。

**デフォルトの名無しさん** · 2011/08/03(水) 01:26:15.74

>>129
じゃあ、あなたが立ち上がりましょう！大丈夫、あなたほど優秀な人ならば表の世界で活躍できる！
さあ、怖がらないで！

**デフォルトの名無しさん** · 2011/08/03(水) 18:16:09.36

>>127
ありがとう
その2つ読んでみます。
リファクタリングはちょうどオブジェクト指向の勉強として読んでいます

>>117と似たようなシリーズの「はじめて学ぶソフトウェアのテスト技法」がいつの間にか家にあったので
とりあえず読んでみようと想うのですが、>>117の3つって必要ですかね
なんか表紙が似ているので同じようなものだと嫌だなぁとｗ

**デフォルトの名無しさん** · 2011/08/04(木) 01:42:56.84

> 設計をプログラムに落とすテスト駆動開発
なんかニュアンス違うw

テスト駆動開発でプログラムができあがる、ってまさに設計しながらって感じで
テスト駆動開発の"前"に行う設計ってせいぜいおおまかな下書きラフスケッチみたいなものでしかない。
とてもじゃないがソースに落とせないよ

**デフォルトの名無しさん** · 2011/08/04(木) 02:26:35.10

みんな表に出て議論しようよ。
みなさんの知見をもとにより良い開発について考えていきましょう！

**デフォルトの名無しさん** · 2011/08/04(木) 21:43:36.36

個々の事例となると社外秘だったりするんで
公開の場でってのは難しいわなぁ

**デフォルトの名無しさん** · 2011/08/07(日) 10:18:32.85

BDDになるとどのくらい違うんだっけ？
イマイチ、TDDとの違いがピンと来ないんだが

**デフォルトの名無しさん** · 2011/08/07(日) 14:29:01.42

BDDはただの言い換えでしょ、Spec系の。
俺は嫌い。

**デフォルトの名無しさん** · 2011/08/07(日) 16:34:10.79

うむ

**デフォルトの名無しさん** · 2011/08/07(日) 16:41:55.68

結局BDDってなんだったの感はあるよな。
最近詳しく言及してたのは
ttp://ukstudio.jp/2011/07/02/bdd
ぐらいか?

**デフォルトの名無しさん** · 2011/08/07(日) 17:22:20.47

滝への回帰としか思えん

**デフォルトの名無しさん** · 2011/08/08(月) 01:29:11.62

和田さん入籍おめでとうございます。

**デフォルトの名無しさん** · 2011/08/08(月) 14:43:54.15

テスト駆動開発ってプログラミングを楽にするけど、
メインは、プログラマーの底上げを図るための物だよね。
だから力がある人や、それと同等の力のある人同士で
プロジェクトを作成する人には不要だね。

**デフォルトの名無しさん** · 2011/08/08(月) 15:31:50.53

力がある人もプログラミングを楽にできるのだが

**デフォルトの名無しさん** · 2011/08/08(月) 22:27:31.26

きしださんとか事あるごとにテストに懐疑的な発言してるけど、あの人が言うと業界にいい加減な人を増やすだけだからやめてほしい。

勉強熱心なのは認めるけど、それを解釈する脳ミソや、実践する態度に疑問を感じてならない。

**デフォルトの名無しさん** · 2011/08/09(火) 11:28:30.47

>>145
誰？
どこに何を発言したの？
見たこと無いけど。

**デフォルトの名無しさん** · 2011/08/10(水) 18:58:30.33

このへんか。もっと昔にも言ってたけどこの人発言量多いから探すの面倒だな。

TDDとか「TDDはあなたの心のなかにあります」みたいなあいまいな言葉なんだから、技術用語として使うのはどうかと思う。その言葉を使って意思疎通ができてない。混乱にしかならないので、この言葉ははやめに葬るほうがいい気がするよ。
https://twitter.com/#!/kis/status/100050996616642560
それもこれもケントベックというペテン師が悪い。
https://twitter.com/#!/kis/status/100051107589537792

**デフォルトの名無しさん** · 2011/08/10(水) 23:42:41.43

良いテストを構築できるかどうかがプログラマの腕の見せ所だろ？

**デフォルトの名無しさん** · 2011/08/11(木) 11:21:29.20

>>147
hatenaのページ見つけたけど、ことあるごとにテストに懐疑的な発言をしているとは見えないんだが。
googleでざっと探してみたけど…

TDD site:http://d.hatena.ne.jp/nowokay/
テスト site:http://d.hatena.ne.jp/nowokay/

>このへんか。もっと昔にも言ってたけどこの人発言量多いから探すの面倒だな。

いやいや、ことあるごとに懐疑的な発言をしているんなら、すぐに見つかるんじゃないの？

**デフォルトの名無しさん** · 2011/08/15(月) 14:57:24.37

ソフトウェアテスト総集編のTDDの記事を書いているTDD研究会のケニチロウってどうなの？

TDDにとっついてみようと本を買ったのはいいが、
ピンとこないというか勘所がわからないので、
この人の言うことをどこまで真に受けていいのかわからないw

**デフォルトの名無しさん** · 2011/08/16(火) 04:58:29.70

噂のRuby&Githubに特化した自動テストサービス「Travis CI」を試してみたらすごいよかった... - mochizblog
http://mochizblog.heroku.com/21

**デフォルトの名無しさん** · 2011/08/16(火) 11:45:59.77

>>150
(3, 4, 5)の場合をif文でいったん実装するというのはやり過ぎという議論もあるかもしれないけど、
それ以外はいたってまともで真に受けて良いよ。

**デフォルトの名無しさん** · 2011/08/16(火) 13:29:16.49

>>152
とん、これ参考にお盆中にゴニョゴニョがんばってみる。

忍法帖【Lv=9,xxxP】 · 2011/09/13(火) 04:36:12.81

test

忍法帖【Lv=11,xxxPT】 · 2011/09/14(水) 08:40:20.36

test

**デフォルトの名無しさん** · 2011/09/14(水) 22:59:28.96

自動化テストに対するテストはどうやって…とかグダグダ言う奴って基本的に信頼できん。
じゃあ、お前は手動で行うテスト仕様書に対してテスト仕様書書いて実施してんのかと。
どっちも最終的にはレビューして担保するしかねーんだよ。

忍法帖【Lv=19,xxxPT】 · 2011/09/15(木) 00:22:15.84

test

**デフォルトの名無しさん** · 2011/09/15(木) 13:38:38.82

でも気持ちはわからなくはないかな。

テスト対象を書いた自分が信用できないからテストを書くわけだけど、
そのテストを自分で書いたらやっぱり信用できるテストなのかとうたがいたくなるよね。

まあ実際はそんなことやてたらきりがないわけだけど。

せめてテスト内容のレビューはしたいよね。
少人数プロジェクトはテストすらかかねえからなあ。

**デフォルトの名無しさん** · 2011/09/15(木) 13:43:03.78

普通は「手動で行うテスト仕様書」のレビューは行われるが、
自動化テストのコードレビューは、レビューに耐えうる品質になってないのがほとんどだろうがな。

**デフォルトの名無しさん** · 2011/09/15(木) 14:58:42.17

テストを通すためのプログラミングをしてもだめだろ

**デフォルトの名無しさん** · 2011/09/15(木) 15:06:24.69

テストを通すためにプログラミング、それがTDD

**デフォルトの名無しさん** · 2011/09/15(木) 15:39:05.50

テストさえ通ればあとは知りまへん、それがTDD

忍法帖【Lv=29,xxxPT】 · 2011/09/16(金) 01:45:17.33

test

忍法帖【Lv=37,xxxPT】 · 2011/09/17(土) 00:32:32.20

test

**デフォルトの名無しさん** · 2011/09/17(土) 16:44:34.63

だからTDDでのテストは、本来の意味のテストじゃねぇってばw
まぁ例えるならlintの強化って感じだ

本来の意味のテストは別途行うべし

**デフォルトの名無しさん** · 2011/09/18(日) 18:28:33.11

だからその辺りの勘違いを嫌って
BDDって言い換えようとした流れも有ったんだが
流行んなかったなあ

**デフォルトの名無しさん** · 2011/09/30(金) 00:14:01.08

>>165
本来の意味でのテストってどんなテスト？

**デフォルトの名無しさん** · 2011/09/30(金) 08:15:58.99

実際に手動でシステムを動作させて、結果を目視確認で期待する結果と相違ないかを確認する作業。

俺も昔は自動化テストですべてまかなえると信じたくちだが、最近はやっぱり手動でもやらないとなと痛感している次第。

**デフォルトの名無しさん** · 2011/10/01(土) 20:10:15.37

目視確認か自動化かは悩ましい所だけど、GUI関連はコスパと変更可能性とかを考えると目視確認が妥当なんだろうな

**デフォルトの名無しさん** · 2011/10/02(日) 11:33:28.50

使い勝手のテストにもなるしねぇ

**デフォルトの名無しさん** · 2011/10/03(月) 08:18:11.42

自動化さろたテストの環境はだいぶ整備されてきてるのにそっちの方のテストはいまだにエクセル管理が多いよなぁ。

**デフォルトの名無しさん** · 2011/10/08(土) 16:23:55.58

継続リリースなら自動化のコストも回収できるだろうけど、単発納品が多いからなぁ

**デフォルトの名無しさん** · 2011/11/10(木) 23:25:22.26

過疎ってんなあ

**デフォルトの名無しさん** · 2011/11/14(月) 00:42:33.46

てめぇが日記でも書いていけや

**デフォルトの名無しさん** · 2012/01/23(月) 03:37:03.56

ユニットテストとは：
想定した入力や操作に対して
プログラマーが想定した結果が返ってくることを確認する工程。

本来のテストとは：
乱数入力やきまぐれ操作によって
プログラマーが想定してなかった欠陥を探す工程。

**デフォルトの名無しさん** · 2012/01/23(月) 21:11:03.75

添削

誤：本来のテストとは ....
正：俺様のテストの定義では ....

**デフォルトの名無しさん** · 2012/01/24(火) 06:25:19.24

>>175
ユニットテストというのはあくまでユニット(関数、クラス、モジュール等)に対するテストという意味だよ。
対比されるべきは結合テスト(複数のユニットに渡るテスト)とか。

プログラマーの想定の範囲内でテストするか、想定の範囲外をテストするかで分類するなら
もう少し別の分類の言葉があると思う。
TDDBCの人が言ってるような、Developer testing、Customer testing、QA testingという
分類がそれに当たるのかもしれない。

**デフォルトの名無しさん** · 2012/01/24(火) 23:29:13.81

>>176
「真の」とか「本当の」とかも同類だねw

**デフォルトの名無しさん** · 2012/02/07(火) 00:06:45.40

>ユニットテストと対比されるべきは結合テスト
結合テストも広義のユニットテストだと思うけど、違うの？

>想定の範囲内でテストするか、想定の範囲外をテストするか
プログラムわからん人に説明するなら分かりやすくていいと思う
仕様の定義漏れテスト

**デフォルトの名無しさん** · 2012/02/07(火) 14:06:58.57

>>179
> 結合テストも広義のユニットテストだと思うけど、違うの？
違う。

> >想定の範囲内でテストするか、想定の範囲外をテストするか
> プログラムわからん人に説明するなら分かりやすくていいと思う
> 仕様の定義漏れテスト
一体何に対する説明なのか良くわからんが、説明する必要がある人（ステークホルダーとか）への
説明なら全然駄目。

**デフォルトの名無しさん** · 2012/02/10(金) 10:51:53.71

TestCaseクラスを、どの単位で作ればいいか迷う。
たとえば
class Foo {
　def method1() {
　}
　def method2() {
　}
}
があったとして、
RSpecなら
describe Foo do
　describe '#method1()' do
　　it "...spec#1..." do ... end
　　it "...spec#2.." do ... end
　end
　describe '#method2()' do
　　it "...spec#1..." do ... end
　　it "...spec#2.." do ... end
　end
end
というふうに、クラス単位・メソッド単位でテストを自然に記述できる。
（つづく）

**デフォルトの名無しさん** · 2012/02/10(金) 10:58:15.99

（つづき）
しかしxUnit系のツール（JUnitとかTest::Unitとか）だと、DSLじゃなくてクラス定義構文とメソッド定義構文を使うから、
こんなかんじ↓になって、テストの記述が不自然になってしまう。

class FooTest(Test::Unit::TestCase)
　# for method1
　def test_method1__spec1() ... end
　def test_method1__spec2() ... end
　# for method2
　def test_method2__spec1() ... end
　def test_method2__spec2() ... end
end

かといって、メソッドごとにクラス定義を分ける↓のは、細かくなり過ぎてやりたくない。

class Foo_method1_Test(Test::Unit::TestCase)
　def test_spec1() ... end
　def test_spec2() ... end
end
class Foo_method2_Test(Test::Unit::TestCase)
　def test_spec1() ... end
　def test_spec2() ... end
end

で、みんなどうしてるんだろうか。

**デフォルトの名無しさん** · 2012/02/10(金) 11:41:52.71

そんな開発者全体で見ると、使用者の割合が0.1%のRubyの話題出されても困ります。

**デフォルトの名無しさん** · 2012/02/11(土) 08:41:31.64

>>183
使用者の割合が0.01%のPythonだと誰も読めないと思って、Rubyにしました。
RSpecはRubyだしね。

**デフォルトの名無しさん** · 2012/02/11(土) 09:07:55.35

Ruby以外の言語だと、XML等でテスト仕様を記述して
そこからテストコードを自動生成するんじゃまいかと思う
いわゆる外部DSLだね

あと、利用者の割合あれこれというより、
Rubyの柔軟性をフル活用した内部DSLであるRSpecをここで持ち出されても、
他の言語利用者には気の毒というか、変態的だと気味悪がられるだけw

**デフォルトの名無しさん** · 2012/02/11(土) 11:10:38.08

PythonやHaskellだとコメントにテストを書くdoctestも定番ですよ

**デフォルトの名無しさん** · 2012/02/12(日) 05:37:05.23

>>181
>TestCaseクラスを、どの単位で作ればいいか迷う。
と書いてあるんだから、別にどの言語であろうと、自分はこういう単位で作ってると教えてあげればいい。
RubyだのRSpecだのにとらわれてるやつは読解力なさすぎ。

自分の場合、Fooクラスに対してFooTestクラスを作り、Fooクラスの機能や仕様ごとに
テストメソッドを書いている。
Fooクラスのメソッド単位での分類はしてない（したいときもあるけど、今はしてない）。

**デフォルトの名無しさん** · 2012/02/13(月) 15:45:37.60

>>184
Pythonも0.1%。
Java(14.2%), C++(10%), C#(5.1%)あたりでよろしく。

**デフォルトの名無しさん** · 2012/02/13(月) 15:47:13.64

>>187
あのー、スレタイ読んで出直してくれます？

**デフォルトの名無しさん** · 2012/02/14(火) 11:02:17.12

TDDの場合、頻繁に変更中のクラスのテストを実行するわけだから、テストクラスは
テスト対象クラス単位の方が良い。
そうしないと、class FooTestにclass Barとclass Bazのテスト用が入っている場合、
Bar/Bazのどちらを変更するときも、関係無いクラスのテストを実行しなければならなくなる。

一方、TDDで実行するテストはUnit Testであるという側面を考えた場合、各テストメソッドは
独立している必要がある（テストメソッドが相互に他のテストメソッドに影響を与えてはならない）。
そうすると、最も親和性の高いものはxUnitである。

xUnitはsetUp()->testMethod()->tearDown()という流れでテストが実行される。
上記でテストクラスはテスト対象クラス単位が良いと書いたが、このxUnitの仕組みにより、
テスト対象クラスが同じでもsetUp()の内容が大幅に異なる場合に限り、一つのテスト対象
クラスに対して、複数のテストクラスに分割するということもありえる。
ただし、そのようにせざるを得ないというのはごくまれで、そうしたいと思う時は大抵
テスト対象クラスの責務が大きすぎる。

**デフォルトの名無しさん** · 2012/02/14(火) 15:46:07.43

>>190
>テストクラスは
>テスト対象クラス単位の方が良い。
これに同意するんだけど、その場合、「メソッド」という単位をどう扱ったらいいの？
ちょうど>>182で書かれていることなんだけど。

class FooTest extends TestCase {
　function test_method1_should_return_string() { ... }
　function test_method1_should_throw_error_when_invalid_arg() { ... }
　function test_method2_should_return_integer() { ... }
　function test_method2_should_throw_error_when_invalid_arg() { ... }
}

こんな感じになってるんだけど、こうしかないのかな。
やっぱりテストを入れ子で書けるRSpecがうらやましい。

**デフォルトの名無しさん** · 2012/02/14(火) 17:13:24.75

>>191
> やっぱりテストを入れ子で書けるRSpecがうらやましい。

個人的には、入れ子で書けたとしても、見た目がすっきりする以外のメリットはあまり感じない。
基本的に、class Foo編集時は、class FooTest全体を実行するから。

入れ子をすることが、テストメソッド群をグルーピングすることだけが目的なのであれば、そのような
機能を持つUnit Testing Frameworkもある。（アノテーションを使ったりする）

>>182の後半の書き方（クラスを分ける）のは感心しない。
何度も言うようだが、class Foo編集時は、そのクラス全体が壊れていないのを確認しながら編集するので、
class Fooに対するテスト全部を実行しながら編集を行う。
そのため、class Fooに対するテストが複数テストクラスに分かれていると、テスト実行が面倒になる。

テストメソッドの粒度の話であれば、1テストメソッドは1テストケースの為のものであるべきというのが結論。

**デフォルトの名無しさん** · 2012/02/15(水) 09:02:08.58

>>192
>個人的には、入れ子で書けたとしても、見た目がすっきりする以外のメリットはあまり感じない。
それがすごく大事なんじゃないか。

>そのため、class Fooに対するテストが複数テストクラスに分かれていると、テスト実行が面倒になる。
それは複数のテストクラスを実行するのが面倒なテストツールが悪いのであって、
テストを複数のクラスに分割すること自体は悪くはないと思う。

なんか話の節々からJavaerっぽい感じを受けるけど、Javaでもpublicなinnerクラスを作って、
ひとつのファイルに複数のテストクラスを入れるってことはしないのかな。

**デフォルトの名無しさん** · 2012/02/15(水) 11:44:29.23

>>193
> >個人的には、入れ子で書けたとしても、見た目がすっきりする以外のメリットはあまり感じない。
> それがすごく大事なんじゃないか。

見た目だけが大事なのであれば、コメントで区切るとかすればいいんじゃない？

> >そのため、class Fooに対するテストが複数テストクラスに分かれていると、テスト実行が面倒になる。
> それは複数のテストクラスを実行するのが面倒なテストツールが悪いのであって、
> テストを複数のクラスに分割すること自体は悪くはないと思う。

複数のテストクラスを実行するのが簡単なテストツールが存在するということと、
テストクラスを複数に分割することの是非は分けて考えなければならない。

自分の場合は、FooTestを実行する場合、コマンドラインで「xunitスペースFo[Tab][Return]」で実行する。
TDDの場合、1分に複数回テストを実行する場合もあるので、起動が面倒だと地味にストレスがたまる。

また、第三者がメンテナンスを引き継ぐ場合、1クラス1テストクラスの原則に沿ってない場合、
どのテストクラスがどのクラスのテストなのかを把握するのが大変になる。

> なんか話の節々からJavaerっぽい感じを受けるけど、Javaでもpublicなinnerクラスを作って、
> ひとつのファイルに複数のテストクラスを入れるってことはしないのかな。

Javaは使ってない。
また、前述したとおり、一つのファイルに複数のテストクラスを入れることもしない。

**デフォルトの名無しさん** · 2012/02/15(水) 11:53:55.66

テストを複数のクラスに分割することのデメリットをまとめておく。

1. class Fooのテストがどのテストクラスにあるのか一目でわからない
2. 起動が面倒になる（テストツールもある）
3. （これまで言わなかったが）複数のテストクラスで共通の処理が必要な場合に、
　　テストクラスが一つであった場合よりもコーディングが面倒になる。
　　コーディングが面倒になるということは、積極的なテストクラスのリファクタリングの妨げにもなる。

逆に、1クラス1テストクラスの原則を守るとした場合のデメリットは何だろう？
個人的には、特に見当たらないのだが……。

**デフォルトの名無しさん** · 2012/02/15(水) 13:25:20.41

一ファイル一クラスが前提なのか、一ファイル複数クラスなのかがごっちゃになってる気がする

**デフォルトの名無しさん** · 2012/02/15(水) 20:39:13.34

テスト駆動なのに、駆動する前にどんなクラスを作るか決めちゃうの？

**デフォルトの名無しさん** · 2012/02/15(水) 20:45:13.85

どんなクラスを作るか決める
↓
テストを作る
↓
クラスを実装する

どんなクラスを作るか決めなきゃテストは作れねーよ

**デフォルトの名無しさん** · NG

正確には「クラスのインタフェースだけはキッチリ決める、実装は決めない」。当然ブラックボックスで。

**デフォルトの名無しさん** · 2012/02/16(木) 10:33:22.15

>>197
クラスとテストクラスを成長させてく過程で、テストクラスをどいう風に作ってけばいいかって話でしょ