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

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2010/09/19(日) 21:26:12
テスト駆動開発 (test-driven development; TDD) について ﾏﾀｰﾘ 語りましょう

ツールについては別スレで
テストツールについて語るスレ 2
http://hibari.2ch.net/test/read.cgi/tech/1208013693/
2013/03/07(木) 23:02:09.96
>>237
> だからテストもループで回したくなってしまう。

それが正解。

> でもテストコードでループ使ってassertを繰り返すのっていいの？

ループで回す先の要素の失敗によって
後続のテストに信頼性が失われるのなら、
assertを使うべき。

各要素がそれぞれ他の要素から独立しており、
個々のテストの成否が他のテストに影響を与えないのなら、
テストの成否に関わらず後続のテストを続けるタイプの
テスト関数（マクロ）を使うべき。
（例えば gtest なら EXPECT_* マクロ）
2013/03/07(木) 23:55:12.86
>>238
ありがとうございます。

各要素は独立していたので、テストを継続するタイプのマクロを使用することに、
ループで繰り返すことにしました。
2013/03/08(金) 07:02:25.85
ちなみに、後続のテストの信頼性が失われるかどうかの判断は、
意外に難しかったりするから注意。

理論上は依存しない仕様のプログラムが、
本当に依存していないかどうかを調べるのも
テストする動機のひとつであることを忘れずに。
2013/03/08(金) 11:53:10.03
TDDなんだから、失敗したらそこで終了で良いのでは？
何で続けたいのかしら。
2013/03/08(金) 12:36:28.56
>>241
独立したテストなら、結果を一覧できた方が作業効率が良い
2013/03/08(金) 14:31:30.19
>>242
ちょっと言ってることが良くわからない。

ひょっとして「後続のテスト」と言ってるのは、
function test1() {}
function test2() {}
function test3() {}
とあったときの、test1()実行後のtest2(), test3()のこと？

もしそうだとしたら、test1(), test2(), test3()は、それぞれ独立したものにすべき。
各テストメソッドの成功/失敗や実行順序でテストの信頼性が失われるなんてもってのほか。

「後続のテスト」が
function test()
{
asssert("test 1");
asssert("test 2");
asssert("test 3");
}
のtest1のアサーション後のtest2, test3のことだとするなら、それはtest1が失敗したところで終了でいいのではということ。
TDDなんだから。
2013/03/08(金) 14:38:22.75
というか、

>>238
> テストの成否に関わらず後続のテストを続けるタイプの
> テスト関数（マクロ）を使うべき。
> （例えば gtest なら EXPECT_* マクロ）

これも良くわからない。
普通のテストツールって、テストが失敗しても後続のテストは続けるんじゃないの？
gtestは知らないけど、gtestってテストが失敗したらそこで終わっちゃうの？

「後続のテスト」というのが、あるテストメソッド内の複数のassertionのことなら前述した通り。
2013/03/08(金) 14:53:32.40
質問者が回答者にレスするスレはここですか？
2013/03/08(金) 17:01:39.12
質問者が回答者にレスしても何も問題ないと思うが、それはともかく、>>243,244は俺なんだが質問者ではない。

なんだか良くわからん質問>>237に対して、さらに良くわからん>>238という回答がついてたのでコメントした。
2013/03/08(金) 19:54:01.96
>>243
例えば、2つの変数 a と b があり、これをそれぞれある値にするための
「計算方法をテストしたい」とする。

私が言った「後続のテスト」とは、a をテストしてから b をテストする場合の、
b のテストの方を指す。

ここで、b の計算には直接的あるいは間接的に a の値を用いるとする。

この場合、a のテストがパスしなければ、b のテストには意味が無くなる。
なぜなら、本来 b の計算のテストと言えば、b の計算方法がテストできる事を期待し、
b の計算に使用する材料は全て正しいものという前提で行うが、
これでは a の結果が間違っているから b のテストがパスしないのか、
b の計算方法が間違っているから b のテストがパスしないのか分からない。
つまり、b の計算方法を正しくテストしているという確証が得られない。
だから a のテストにパスしなければ、そこでテストを止めるべきだ。

しかし、b の計算に a の値が使われない場合、
a の計算方法のテストと b の計算方法のテストは独立している。
よって、たとえ a のテストがパスしなくても、b のテストは問題なく行える。

また、このように後者の場合において、a のテストと b のとテストを同時に行う方が
テストの作業効率が良い場合も少なくない。
例えば、a と b のそれぞれの計算は独立しているが、もっと大きな枠組みにおいて、
a と b（やその他のものが）合わさってある一つの機能を実現している場合などだ。
その機能をテストする前に個々の要素をテストしているのなら、
a と b などの独立したテストの結果は一望できた方が良いと私は思う。
2013/03/08(金) 22:21:28.50
>>247
アホなの？
aのテストがパスするまで実装とテストを繰り返してからbの実装をするか、stubやmock使えよ。
2013/03/08(金) 23:47:04.07
それもそうか
2013/04/28(日) 19:09:53.06
これから本買って読もうと思いますが、TDDにxUnit的ツールは必須なんでしょうか
コンソールに結果出力するだけでもいいのでしょうか
2013/04/28(日) 19:34:15.22
あった方が断然楽しい
2013/04/28(日) 20:08:05.56
あった方がいいのは分かりますが、必須ではなさそうですね
HEW+ルネサスコンパイラで、ツール買う予算も取れないので、assertとprintfで凌ぎます
2013/04/29(月) 21:09:30.71
組込みやってるやつは可哀想だ
しかもルネとはw
2013/04/29(月) 21:41:33.37
>>252はアホ
2013/04/30(火) 15:46:55.50
コンソールがあって、さらにはprintfとassertが使えるなら、xUnitも使えるだろうが
256アホ
垢版 |
2013/05/01(水) 05:26:40.17
CUnitとかCppUnit etcって、makeする時に実行されるもんじゃないの?
バイナリ実行すればコンソールに表示されるようなもんなの?
257アホ
垢版 |
2013/05/01(水) 08:04:01.43
CUnit入れてコンパイルまでは通したけど、全部FAILEDになるぜドチクショウ
スレ汚し失礼しました
2013/06/27(木) 08:16:11.07
>>247
stubあんのにそんな長文、恥ずかしくないの？
2013/07/12(金) NY:AN:NY.AN
TDD始めてみたんだが、暗号化するメソッドと複合化するメソッドがあって、あるデータを暗号化して複合したらもとのデータ戻るってテストはどうやって書くのがいいの？
2013/07/12(金) NY:AN:NY.AN
既知の平文と暗号文の対を用意して
「平文→暗号化メソッド→暗号文」 というテストと
「暗号文→復号メソッド→平文」 というテストをすればいいと思うよ
2013/07/22(月) NY:AN:NY.AN
>>260
既知の暗号文無いから暗号文を求めようとしても、手で計算するのがものすごく大変。
計算機で計算しようとしても、その数式がコードそのものだから本末転倒なんだよね。
2013/07/22(月) NY:AN:NY.AN
知らんがな(´・ω・｀)
いかに大変でも期待通りの暗号化処理が正しくなされてるか確認するためには最低1回は答え合わせをせざるを得なかろうよ
2013/07/24(水) NY:AN:NY.AN
>>261はTDD以前に自分が何をテストしなければならないのかすら
分かってない気がする
2013/07/28(日) NY:AN:NY.AN
>>263
もしかしてこういうのってテストしなくてもいいの？
2013/07/28(日) NY:AN:NY.AN
TDDのテストは開発者が設計実装を駆動するためのホワイトボックステストで、
開発者がテストとコードを両方見て主観的にコードが正しいことに確信を持てる程度のものにする。

暗号化とか神経質にならざるを得ないかもしれないが
その品質用テストを用意するのはTDDの範疇外というだけで
要らないものではないと思われ
2013/07/28(日) NY:AN:NY.AN
仕様書に入出力（平文と暗号文）のサンプルくらい記載されているもんじゃないのか
それコピペすれば最低限のテストはできる思うけど

入出力が分からないんじゃTDD以前の問題だわ
2013/07/28(日) NY:AN:NY.AN
>>265
そうなのだろうが、暗号化するコードなのに肝心の「暗号化できているか」をまったく調べることができないと、コードの正しさに確信が持てないんだよなあ。
というかTDDのテストってブラックボックスじゃないの？
2013/07/28(日) NY:AN:NY.AN
>>266
やっぱり出力を先に手計算しといたほうがいいのかな？
add(1,1) == 2 になることを調べるテストだって、右辺の2は前もって人間が計算してるわけだし。

ただ今回の場合は簡単な解が無くて、暗号化計算してわけのわからん値になったもの同士を比較するテストをして通っても、そのメソッドが正しいという確信が得られるような気がしないんだよなあ。
そんなテストよりは、暗号文の特性、複合すると元に戻ることとかを調べたほうが直感的な気がしたんだが…なんかもやもやする。
2013/07/28(日) NY:AN:NY.AN
>>268
たとえば解の候補が３パターンあるとして
①顧客の解（要望）…AESで作ってほしい
②設計者の解（仕様書）…Twofishを採用しよう
③>>268の解(実装)…分けわからんが0xABCDでビットマスクで実装すればいいんだよな？

で、>>268がやろうとしているのは「③」をパスするテストコードを書くってことだ
それをパスすることに意味はあるのか？　「①＝②＝③」なら問題ないが
2013/07/29(月) NY:AN:NY.AN
>>269
どういうこと？
すまん、さっき「解」っていったのは、メソッドの返す値って意味で。
複合すると元に戻るっていうのを調べるテストは、それをパスする他のアルゴリズムがあるから、仕様をテストが表現できていないって感じの意味か？確かに、そう考えるとやばそう…。

だが手計算で計算するのが大変で、プログラムのテストというより、自分の計算のテストになりそうなんだけど。結構時間もかかるだろうし。
2013/08/01(木) NY:AN:NY.AN
そもそも単体テストってassert(expression)だから、expressionを自分で定義できなきゃやりようがないわな
272デフォルトの名無しさん
垢版 |
2013/10/19(土) 14:06:55.25
マジでどうしたらいいかわからん助けて

encryptメソッドの仕様は
encrypt(text, pass) = salt+aes(sha(pass)+text, pass, salt)
salt=sha(rand)
aesはaes暗号、shaはハッシュ関数のやつ、randは乱数、+は文字列の結合な。
あと、textやpassは空文字でもok

decrypt(crypt, pass)はそれの復号メソッドで、もしcryptにaesの復号エラーにならないようなでたらめな値入れられても、復号文の先頭のsha(pass)が一致しなければ自作例外を投げる仕様。

お前らならどうテストすんの？
2013/10/19(土) 20:41:24.25
レスに書いてあることそのままテストすりゃいいんじゃないの
2013/10/19(土) 21:46:37.57
crypt = encrypt(text, pass);
try {
decrypted = decrypt(crypt, pass);
assert(decrypted == text);
}
catch {
assert(false);
}
try {
decrypt(nonsense_crypt_not_aes_decrypt_error, pass);
assert(false);
}
catch {
assert(true);
}
2013/12/06(金) 15:11:53.63
http://the-little-book-of-busterjs.readthedocs.org/en/latest/doc/column/TravisCI/
276デフォルトの名無しさん
垢版 |
2013/12/26(木) 15:53:04.30
TDD Advent Calendar 2013
http://qiita.com/advent-calendar/2013/tddadventjp
2013/12/26(木) 17:18:52.11
メソッドの名前をリファクタリングで変更するだけで
テスト毎ぶっこわれる動的言語ではTDDは辛すぎる
2014/01/13(月) 10:28:34.81
CUI のアプリを作っているのですが、ユーザーからの入力や、
それに対する出力などをテストしたいです。

ビジネスロジックの方では、入力と出力の関係は既に正しくテストされている前提です。
あくまで、UI の部分のテストの話です。

CUI用のUIテスト自動化フレームワークは何かないでしょうか。


[環境]
Linux
2014/01/13(月) 11:15:01.01
>>278
シェルスクリプト書けばいいだけでは？
2014/01/13(月) 11:19:04.03
追加。入力周りは昔はexpectというtclの拡張コマンドがよく使われてたけど、今はtclなんて流行らないよね…。
たぶん、perlとか、他のスクリプト言語にもexpect相当のライブラリがあるのでは？
281278
垢版 |
2014/01/13(月) 11:42:00.72
なるほど、確かに。
自分の得意なスクリプト言語で作ればいいんですよね。

頭が堅すぎたようです。

ありがとうございました。
2014/01/14(火) 08:16:34.22
TAPを出すシェルスクリプトを書いて
proveでテスト実行とかかな
283デフォルトの名無しさん
垢版 |
2014/01/26(日) 12:33:01.79
テスト駆動流行りだけど、誰がどこを勝手に直すかわからないOSSみたいな
開発形態では意図せぬデグレートが起きないように抑止する効果はあっても、
きちんと統制が取れた企業内開発じゃさして意味ないよなあ。
最初から通るテストを書いているわけで、結局コードを書いているのと同じ
レベルになって、バグは入り込むわけだし。
284デフォルトの名無しさん
垢版 |
2014/01/26(日) 12:34:16.46
テストせやかて工藤
285デフォルトの名無しさん
垢版 |
2014/01/26(日) 12:37:38.39
>>283
根本的にOSSというのを勘違いしているから
その後に発言が無意味になってる。
2014/01/27(月) 11:19:03.88
> 最初から通るテストを書いているわけで、結局コードを書いているのと同じ
> レベルになって、バグは入り込むわけだし。

それはテストコードと言えないだろうね
テストが通れば確実にバグってない事が保証出来るコードでないと意味ないよね
ようするに単純なテストを積み重ねていく感じか
2014/01/27(月) 15:53:46.32
仕様に明記されていないことはやらない（コードに落とさない）
仕様に明記されている内容はまずテストコードに落とし、次にコードを書き、テストを通す
2014/01/27(月) 17:11:28.38
コードをテストに合わせるからバグが減る
テストをコードに合わせてはいけない
2014/01/28(火) 08:16:11.34
TDDで後から実行可能なテストも手に入るのはオマケやで
出来てしまったテストを捨てることもないだろうが
あくまで開発を前に進ませる手段や
2014/01/28(火) 08:17:03.85
> 仕様に明記されていないことはやらない（コードに落とさない）
> 仕様に明記されている内容はまずテストコードに落とし、次にコードを書き、テストを通す

仕様等の出発点からどのように粒度を落としていくか（設計していくか）の方向性として
テストするという観点を掲げているのがケントベックが本で語ったTDDなのだが
この開発の最初に必要とされるであろうステップが
日本語のWebサイト上のいろいろある解説ではびっくりするくらい完全に無視されている
2014/01/28(火) 08:36:37.02
何見て解説してるのかわからんな
292デフォルトの名無しさん
垢版 |
2014/01/28(火) 11:12:20.43
>>290
TDDのそもそもの意味/意図である「テスト駆動」の「駆動」を忘れてるのか知らないのか無視してる奴が多いね。
なんとなくのイメージで「xUnitを使って自動テストをしながらコードを書く」くらいの理解の奴が多い感じ。
2014/01/28(火) 13:08:16.58
Test First と Test Driven はどう違う？
2014/01/28(火) 13:48:03.51
>>293
ざっくり言えば、TDD = Design First + Test First + Refactoring
2014/01/28(火) 15:13:31.12
>「駆動」を忘れてるのか知らないのか無視してる奴が多い

スレタイのせいかもな
2014/01/28(火) 18:22:31.47
BDDと形式手法の違いって？
2014/01/28(火) 18:34:16.93
>>296
形式手法って何？
2014/01/28(火) 21:50:39.87
テストを書くときの気持ちのこと
2014/01/29(水) 10:13:17.67
ぐぐればすぐ出てくるものを即座に質問する
これを脊髄駆動レスと呼びます
2014/01/29(水) 12:52:40.18
>>299
>>296のことなのか、>>297のことなのか
2014/01/31(金) 10:18:11.76
ぐぐれ
2014/02/02(日) 04:03:14.23
こんなスレあったのか
しかもだいぶ前からあるとは

俺はTDDは必要だと思ってる
元々ゴリゴリコーディングして、デバッガー使ったりで人力でテストしてって感じだったけど、
思想を知ってから、あぁこんな洗練されたものがあったのかと思った
昔はテストなんて面倒くさいと思ってたけど、それでも思想を知ってからは無理して身体に覚えさせた
慣れだよね

DBやマルチプロセスとかの問題は言われてるけど、使い分けじゃないの？
有用なときは使い 、効率悪いときは別のやり方
完璧なものなんてないだろうし

なぜ流行らなかったとか別スレあるという事は、皆あんまテストしないのか？
しても後から曖昧にとか？
2014/02/02(日) 07:00:16.31
>>302
TDDはテストじゃねーよ。

テストのフリした違うものを使って開発する方法。
作ったテストもどきはテストとしては使わない。
使い捨てのコード。

やっぱりお前はわかっていない。
2014/02/02(日) 08:56:36.07
> 作ったテストもどきはテストとしては使わない。
> 使い捨てのコード。

は？
2014/02/02(日) 13:36:26.27
>>303
じゃぁお前は、また、お前の会社はどうやってテストだけでなく、開発をしてるんだ？
開発のプロセスを聞いてみたい
2014/02/02(日) 17:35:46.13
>>304,305
俺は303じゃないけど
たぶんお前らはTDDを理解してない
もしくは一部を見て言ってる
2014/02/02(日) 18:00:48.70
ああ、こりゃ「じゃあTDDって何だよ」って問うてもまともに答えられない展開ですわ
2014/02/02(日) 18:54:00.78
【TDD】テスト駆動開発【TestFirst】
2014/02/02(日) 19:03:43.35
TDDの良い所は、コーディングがキチっとなることだと思う
テストがどうとかじゃなく、ブレがないというか

DBがどうとか言うけど、スタブ、モックオブジェクト、なんやらあるだろ
2014/02/02(日) 20:02:31.60
俺こそがTDDの神祖
おまいらは邪教徒じゃ
2014/02/02(日) 20:48:15.81
BDDって使ったことないけど、どう違うの？
TestMethod()とかがUnittestだけど、
BDDの場合はshouldBeEmpty()とかになるんだろ?
2014/02/03(月) 14:30:29.47
>>307
> 「じゃあTDDって何だよ」って問うてもまともに答えられない

その質問は、ググればすぐにわかるから誰も答えないんじゃないの？
ちなみに、Googleの第一位はWikipediaですごくまとまってる。
http://ja.wikipedia.org/wiki/%E3%83%86%E3%82%B9%E3%83%88%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA
2014/02/03(月) 14:33:11.18
>>304,305
>>303の文章は酷いが、Wikipediaを読めば理解できると思う。

> テスト駆動開発で用いられるテストは、品質のためのテストではない。コード本体とは独立に
> あらゆるケースを網羅するような、テスト自体で価値を持つようなものは目指していない。
> コード本体を合わせて検討することで、開発者が、その正しさに確信を得るものである。
> 開発者の確信に少しも寄与しないテスト（かつ、ドキュメントとしてテストの読者に何かを
> 伝えるために書かれたものではないもの）は、むしろ積極的に削除を検討する。
2014/02/03(月) 17:06:00.43
俺は、TDDで作ったテストメソッドの大部分は、「品質のためのテスト」でも使えるよう修正してくよ。
2014/02/03(月) 18:38:14.74
>>313
そういうことだよな。

393 名前：デフォルトの名無しさん[sage] 投稿日：2014/02/02(日) 08:52:46.17
TDDでコーディングより先に書くテストっていうのは
ちゃんとしたテストじゃないんだ。
本番用のテストとして使えるものもあるが、使い捨てのテストも多い。
だから本番用のテストは別にちゃんと書かないといけない。

つまりこういうことなんだ。

「仮テスト→コーディング→本テスト」 VS 「コーディング→本テスト」
2014/02/03(月) 19:40:04.51
これよかったよ。
http://japan.renesas.com/company_info/lsi_design/
2014/02/05(水) 08:51:07.35
テストをTDDで開発してるのか
2014/02/05(水) 18:24:02.84
t_wadaさんによるスライド
「TDD のこころ @ OSH2014」
http://www.slideshare.net/t_wada/osh2014-sprit-of-tdd

『テスト駆動開発入門』も
『リファクタリング』も
『達人プログラマー』も
絶版になってたなんて……。
2014/02/07(金) 16:30:20.46
>>318
「達人プログラマー」ってなんか東亜プランの中の人かとｵﾓﾀ
2014/02/07(金) 21:50:41.56
TDDの最大のメリットはテストしやすいソースになる事
2014/02/08(土) 13:05:21.69
昔社内の文書でテスト騒動って書いている奴がいて笑った
そりゃ、テストで騒動が起きるのは困るよね
2014/02/08(土) 13:09:53.56
テストで騒動とかプロジェクト毎に起きてるぜ
2014/02/08(土) 17:19:52.71
>>321を素で駆動と読んでｲﾐﾌだったが>>322で読み直してすっきりさっぱりだよ。
2014/02/09(日) 23:04:23.44
まぁ、バグが発生するのはテスト中だからな
2014/02/12(水) 03:55:25.26
完成してなくてもいいから、コンパイルの通らないコードをリポジトリに登録するな、
でないと全体のコンパイルに支障が出る、というのと似たような感じで、
テストを通していないモジュールを登録するな、暫定的でもそれなりに動作するようなモジュールができていないと、
他のモジュールの開発に支障が出るから、ってことかね。
2014/02/12(水) 11:29:02.29
>>325
> テストを通していないモジュールを登録するな、暫定的でもそれなりに動作するようなモジュールができていないと、
これは別にTDDに限った話じゃないだろ
2014/02/12(水) 13:59:27.22
テストを“いちばん重要な財産”と考えると見えるもの
http://gihyo.jp/dev/serial/01/tdd_supremacy
タイトルと概要しか見てないけど、短かい文章でテストの重要性を言い表わしてるなと思ったんでコピっとく
2014/02/12(水) 14:39:26.47
>>327
コードのインデントやレイアウトがキモ過ぎるし、newしたオブジェクトを=&で代入したり、
もう全く信用できないので、本文も読む価値無いね。
2014/02/12(水) 15:34:30.78
>>328
いい加減、ちゃんと問題点を指摘できるようになろうぜｗ
2014/02/12(水) 15:38:44.80
>>329
・コードのインデントがキモイ => 最近のコーディング標準知らないんじゃないの
・レイアウトがキモイ => 最近のコーディング標準知らないんじゃないの？静的解析したことないんじゃないの？
・newしたオブジェクトを=&で代入したり => お前いつの時代のPHPerだよ
2014/02/12(水) 15:41:04.76
>>330
いや、そんなことどうでもいいからｗ
インデントの幅がどうとか言ってるだけじゃん。
2014/02/12(水) 16:00:01.69
>>331
PHPのことあまり知らないんだろうけど、最近はPSR-1/PSR-2/Zend/PEARのコーディング規約に
沿って書くのが普通。
まぁそれを知らないド素人でも、人のコードを見慣れてればあんな酷いコードは書かないだろう。

それに、今時varとかfunction &hoge()とか$fuga =& new Fuga()とかありえないから。

第2回もちょろっと見たけど、あり得ない酷いコードだわ。
2014/02/12(水) 16:04:05.29
>>332
本文読んでないからわかってないんだろう？

> 前回，「これまでの記事で取り上げたコードを，テスト駆動ベースに移行していく」と書きました

これは「これまでの記事で取り上げたコード」だ
昔のコードだって書いてあるだろ。
2014/02/12(水) 16:21:46.58
>>333
へー、第1回と第2回に載ってるコード全てが昔のコードだって言うの？
いくらなんでも古すぎだわ。
2014/02/12(水) 16:32:05.04
PHP のことあまり知らないから他の言語の利用者にもわかるように
説明してくれると嬉しいところなんだけどな
コードレイアウトは技評の Web 記事編集が手を入れないのが悪い
2014/02/12(水) 16:47:05.39
ここにたれ込めばいいと思うよ
http://gihyo.jp/dev/serial/01/php-programming-examination-room
2014/02/12(水) 20:31:31.24
> プログラミングにおいていちばん重要な財産はテストであり，
> 万一コードをすべて失ってしまったとしても，
> テストが無事なら元と同じ品質のコードをもう一度書くことができる。
> －この考えを立証すべく，テストとコードの関係を考えます。

この時点で、オレオレテスト駆動
別の名前付ければいいのに
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。