テスト駆動開発 (test-driven development; TDD) について ﾏﾀｰﾘ 語りましょう
ツールについては別スレで
テストツールについて語るスレ 2
http://hibari.2ch.net/test/read.cgi/tech/1208013693/
【TDD】テスト駆動開発【TestFirst】
■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
2010/09/19(日) 21:26:12152デフォルトの名無しさん
2011/08/16(火) 11:45:59.77153デフォルトの名無しさん
2011/08/16(火) 13:29:16.49 >>152
とん、これ参考にお盆中にゴニョゴニョがんばってみる。
とん、これ参考にお盆中にゴニョゴニョがんばってみる。
156デフォルトの名無しさん
2011/09/14(水) 22:59:28.96 自動化テストに対するテストはどうやって…とかグダグダ言う奴って基本的に信頼できん。
じゃあ、お前は手動で行うテスト仕様書に対してテスト仕様書書いて実施してんのかと。
どっちも最終的にはレビューして担保するしかねーんだよ。
じゃあ、お前は手動で行うテスト仕様書に対してテスト仕様書書いて実施してんのかと。
どっちも最終的にはレビューして担保するしかねーんだよ。
158デフォルトの名無しさん
2011/09/15(木) 13:38:38.82 でも気持ちはわからなくはないかな。
テスト対象を書いた自分が信用できないからテストを書くわけだけど、
そのテストを自分で書いたらやっぱり信用できるテストなのかとうたがいたくなるよね。
まあ実際はそんなことやてたらきりがないわけだけど。
せめてテスト内容のレビューはしたいよね。
少人数プロジェクトはテストすらかかねえからなあ。
テスト対象を書いた自分が信用できないからテストを書くわけだけど、
そのテストを自分で書いたらやっぱり信用できるテストなのかとうたがいたくなるよね。
まあ実際はそんなことやてたらきりがないわけだけど。
せめてテスト内容のレビューはしたいよね。
少人数プロジェクトはテストすらかかねえからなあ。
159デフォルトの名無しさん
2011/09/15(木) 13:43:03.78 普通は「手動で行うテスト仕様書」のレビューは行われるが、
自動化テストのコードレビューは、レビューに耐えうる品質になってないのがほとんどだろうがな。
自動化テストのコードレビューは、レビューに耐えうる品質になってないのがほとんどだろうがな。
160デフォルトの名無しさん
2011/09/15(木) 14:58:42.17 テストを通すためのプログラミングをしてもだめだろ
161デフォルトの名無しさん
2011/09/15(木) 15:06:24.69 テストを通すためにプログラミング、それがTDD
162デフォルトの名無しさん
2011/09/15(木) 15:39:05.50 テストさえ通ればあとは知りまへん、それがTDD
165デフォルトの名無しさん
2011/09/17(土) 16:44:34.63 だからTDDでのテストは、本来の意味のテストじゃねぇってばw
まぁ例えるならlintの強化って感じだ
本来の意味のテストは別途行うべし
まぁ例えるならlintの強化って感じだ
本来の意味のテストは別途行うべし
166デフォルトの名無しさん
2011/09/18(日) 18:28:33.11 だからその辺りの勘違いを嫌って
BDDって言い換えようとした流れも有ったんだが
流行んなかったなあ
BDDって言い換えようとした流れも有ったんだが
流行んなかったなあ
167デフォルトの名無しさん
2011/09/30(金) 00:14:01.08 >>165
本来の意味でのテストってどんなテスト？
本来の意味でのテストってどんなテスト？
168デフォルトの名無しさん
2011/09/30(金) 08:15:58.99 実際に手動でシステムを動作させて、結果を目視確認で期待する結果と相違ないかを確認する作業。
俺も昔は自動化テストですべてまかなえると信じたくちだが、最近はやっぱり手動でもやらないとなと痛感している次第。
俺も昔は自動化テストですべてまかなえると信じたくちだが、最近はやっぱり手動でもやらないとなと痛感している次第。
169デフォルトの名無しさん
2011/10/01(土) 20:10:15.37 目視確認か自動化かは悩ましい所だけど、GUI関連はコスパと変更可能性とかを考えると目視確認が妥当なんだろうな
170デフォルトの名無しさん
2011/10/02(日) 11:33:28.50 使い勝手のテストにもなるしねぇ
171デフォルトの名無しさん
2011/10/03(月) 08:18:11.42 自動化さろたテストの環境はだいぶ整備されてきてるのにそっちの方のテストはいまだにエクセル管理が多いよなぁ。
172デフォルトの名無しさん
2011/10/08(土) 16:23:55.58 継続リリースなら自動化のコストも回収できるだろうけど、単発納品が多いからなぁ
173デフォルトの名無しさん
2011/11/10(木) 23:25:22.26 過疎ってんなあ
174デフォルトの名無しさん
2011/11/14(月) 00:42:33.46 てめぇが日記でも書いていけや
175デフォルトの名無しさん
2012/01/23(月) 03:37:03.56 ユニットテストとは：
想定した入力や操作に対して
プログラマーが想定した結果が返ってくることを確認する工程。
本来のテストとは：
乱数入力やきまぐれ操作によって
プログラマーが想定してなかった欠陥を探す工程。
想定した入力や操作に対して
プログラマーが想定した結果が返ってくることを確認する工程。
本来のテストとは：
乱数入力やきまぐれ操作によって
プログラマーが想定してなかった欠陥を探す工程。
176デフォルトの名無しさん
2012/01/23(月) 21:11:03.75 添削
誤：本来のテストとは ....
正：俺様のテストの定義では ....
誤：本来のテストとは ....
正：俺様のテストの定義では ....
177デフォルトの名無しさん
2012/01/24(火) 06:25:19.24 >>175
ユニットテストというのはあくまでユニット(関数、クラス、モジュール等)に対するテストという意味だよ。
対比されるべきは結合テスト(複数のユニットに渡るテスト)とか。
プログラマーの想定の範囲内でテストするか、想定の範囲外をテストするかで分類するなら
もう少し別の分類の言葉があると思う。
TDDBCの人が言ってるような、Developer testing、Customer testing、QA testingという
分類がそれに当たるのかもしれない。
ユニットテストというのはあくまでユニット(関数、クラス、モジュール等)に対するテストという意味だよ。
対比されるべきは結合テスト(複数のユニットに渡るテスト)とか。
プログラマーの想定の範囲内でテストするか、想定の範囲外をテストするかで分類するなら
もう少し別の分類の言葉があると思う。
TDDBCの人が言ってるような、Developer testing、Customer testing、QA testingという
分類がそれに当たるのかもしれない。
178デフォルトの名無しさん
2012/01/24(火) 23:29:13.81 >>176
「真の」とか「本当の」とかも同類だねw
「真の」とか「本当の」とかも同類だねw
179デフォルトの名無しさん
2012/02/07(火) 00:06:45.40 >ユニットテストと対比されるべきは結合テスト
結合テストも広義のユニットテストだと思うけど、違うの？
>想定の範囲内でテストするか、想定の範囲外をテストするか
プログラムわからん人に説明するなら分かりやすくていいと思う
仕様の定義漏れテスト
結合テストも広義のユニットテストだと思うけど、違うの？
>想定の範囲内でテストするか、想定の範囲外をテストするか
プログラムわからん人に説明するなら分かりやすくていいと思う
仕様の定義漏れテスト
180デフォルトの名無しさん
2012/02/07(火) 14:06:58.57 >>179
> 結合テストも広義のユニットテストだと思うけど、違うの？
違う。
> >想定の範囲内でテストするか、想定の範囲外をテストするか
> プログラムわからん人に説明するなら分かりやすくていいと思う
> 仕様の定義漏れテスト
一体何に対する説明なのか良くわからんが、説明する必要がある人（ステークホルダーとか）への
説明なら全然駄目。
> 結合テストも広義のユニットテストだと思うけど、違うの？
違う。
> >想定の範囲内でテストするか、想定の範囲外をテストするか
> プログラムわからん人に説明するなら分かりやすくていいと思う
> 仕様の定義漏れテスト
一体何に対する説明なのか良くわからんが、説明する必要がある人（ステークホルダーとか）への
説明なら全然駄目。
181デフォルトの名無しさん
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
というふうに、クラス単位・メソッド単位でテストを自然に記述できる。
（つづく）
たとえば
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
というふうに、クラス単位・メソッド単位でテストを自然に記述できる。
（つづく）
182デフォルトの名無しさん
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
で、みんなどうしてるんだろうか。
しかし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
で、みんなどうしてるんだろうか。
183デフォルトの名無しさん
2012/02/10(金) 11:41:52.71 そんな開発者全体で見ると、使用者の割合が0.1%のRubyの話題出されても困ります。
184デフォルトの名無しさん
2012/02/11(土) 08:41:31.64185デフォルトの名無しさん
2012/02/11(土) 09:07:55.35 Ruby以外の言語だと、XML等でテスト仕様を記述して
そこからテストコードを自動生成するんじゃまいかと思う
いわゆる外部DSLだね
あと、利用者の割合あれこれというより、
Rubyの柔軟性をフル活用した内部DSLであるRSpecをここで持ち出されても、
他の言語利用者には気の毒というか、変態的だと気味悪がられるだけw
そこからテストコードを自動生成するんじゃまいかと思う
いわゆる外部DSLだね
あと、利用者の割合あれこれというより、
Rubyの柔軟性をフル活用した内部DSLであるRSpecをここで持ち出されても、
他の言語利用者には気の毒というか、変態的だと気味悪がられるだけw
186デフォルトの名無しさん
2012/02/11(土) 11:10:38.08 PythonやHaskellだとコメントにテストを書くdoctestも定番ですよ
187デフォルトの名無しさん
2012/02/12(日) 05:37:05.23 >>181
>TestCaseクラスを、どの単位で作ればいいか迷う。
と書いてあるんだから、別にどの言語であろうと、自分はこういう単位で作ってると教えてあげればいい。
RubyだのRSpecだのにとらわれてるやつは読解力なさすぎ。
自分の場合、Fooクラスに対してFooTestクラスを作り、Fooクラスの機能や仕様ごとに
テストメソッドを書いている。
Fooクラスのメソッド単位での分類はしてない（したいときもあるけど、今はしてない）。
>TestCaseクラスを、どの単位で作ればいいか迷う。
と書いてあるんだから、別にどの言語であろうと、自分はこういう単位で作ってると教えてあげればいい。
RubyだのRSpecだのにとらわれてるやつは読解力なさすぎ。
自分の場合、Fooクラスに対してFooTestクラスを作り、Fooクラスの機能や仕様ごとに
テストメソッドを書いている。
Fooクラスのメソッド単位での分類はしてない（したいときもあるけど、今はしてない）。
188デフォルトの名無しさん
2012/02/13(月) 15:45:37.60189デフォルトの名無しさん
2012/02/13(月) 15:47:13.64 >>187
あのー、スレタイ読んで出直してくれます？
あのー、スレタイ読んで出直してくれます？
190デフォルトの名無しさん
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()の内容が大幅に異なる場合に限り、一つのテスト対象
クラスに対して、複数のテストクラスに分割するということもありえる。
ただし、そのようにせざるを得ないというのはごくまれで、そうしたいと思う時は大抵
テスト対象クラスの責務が大きすぎる。
テスト対象クラス単位の方が良い。
そうしないと、class FooTestにclass Barとclass Bazのテスト用が入っている場合、
Bar/Bazのどちらを変更するときも、関係無いクラスのテストを実行しなければならなくなる。
一方、TDDで実行するテストはUnit Testであるという側面を考えた場合、各テストメソッドは
独立している必要がある（テストメソッドが相互に他のテストメソッドに影響を与えてはならない）。
そうすると、最も親和性の高いものはxUnitである。
xUnitはsetUp()->testMethod()->tearDown()という流れでテストが実行される。
上記でテストクラスはテスト対象クラス単位が良いと書いたが、このxUnitの仕組みにより、
テスト対象クラスが同じでもsetUp()の内容が大幅に異なる場合に限り、一つのテスト対象
クラスに対して、複数のテストクラスに分割するということもありえる。
ただし、そのようにせざるを得ないというのはごくまれで、そうしたいと思う時は大抵
テスト対象クラスの責務が大きすぎる。
191デフォルトの名無しさん
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がうらやましい。
>テストクラスは
>テスト対象クラス単位の方が良い。
これに同意するんだけど、その場合、「メソッド」という単位をどう扱ったらいいの？
ちょうど>>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がうらやましい。
192デフォルトの名無しさん
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テストケースの為のものであるべきというのが結論。
> やっぱりテストを入れ子で書けるRSpecがうらやましい。
個人的には、入れ子で書けたとしても、見た目がすっきりする以外のメリットはあまり感じない。
基本的に、class Foo編集時は、class FooTest全体を実行するから。
入れ子をすることが、テストメソッド群をグルーピングすることだけが目的なのであれば、そのような
機能を持つUnit Testing Frameworkもある。（アノテーションを使ったりする）
>>182の後半の書き方（クラスを分ける）のは感心しない。
何度も言うようだが、class Foo編集時は、そのクラス全体が壊れていないのを確認しながら編集するので、
class Fooに対するテスト全部を実行しながら編集を行う。
そのため、class Fooに対するテストが複数テストクラスに分かれていると、テスト実行が面倒になる。
テストメソッドの粒度の話であれば、1テストメソッドは1テストケースの為のものであるべきというのが結論。
193デフォルトの名無しさん
2012/02/15(水) 09:02:08.58 >>192
>個人的には、入れ子で書けたとしても、見た目がすっきりする以外のメリットはあまり感じない。
それがすごく大事なんじゃないか。
>そのため、class Fooに対するテストが複数テストクラスに分かれていると、テスト実行が面倒になる。
それは複数のテストクラスを実行するのが面倒なテストツールが悪いのであって、
テストを複数のクラスに分割すること自体は悪くはないと思う。
なんか話の節々からJavaerっぽい感じを受けるけど、Javaでもpublicなinnerクラスを作って、
ひとつのファイルに複数のテストクラスを入れるってことはしないのかな。
>個人的には、入れ子で書けたとしても、見た目がすっきりする以外のメリットはあまり感じない。
それがすごく大事なんじゃないか。
>そのため、class Fooに対するテストが複数テストクラスに分かれていると、テスト実行が面倒になる。
それは複数のテストクラスを実行するのが面倒なテストツールが悪いのであって、
テストを複数のクラスに分割すること自体は悪くはないと思う。
なんか話の節々からJavaerっぽい感じを受けるけど、Javaでもpublicなinnerクラスを作って、
ひとつのファイルに複数のテストクラスを入れるってことはしないのかな。
194デフォルトの名無しさん
2012/02/15(水) 11:44:29.23 >>193
> >個人的には、入れ子で書けたとしても、見た目がすっきりする以外のメリットはあまり感じない。
> それがすごく大事なんじゃないか。
見た目だけが大事なのであれば、コメントで区切るとかすればいいんじゃない？
> >そのため、class Fooに対するテストが複数テストクラスに分かれていると、テスト実行が面倒になる。
> それは複数のテストクラスを実行するのが面倒なテストツールが悪いのであって、
> テストを複数のクラスに分割すること自体は悪くはないと思う。
複数のテストクラスを実行するのが簡単なテストツールが存在するということと、
テストクラスを複数に分割することの是非は分けて考えなければならない。
自分の場合は、FooTestを実行する場合、コマンドラインで「xunitスペースFo[Tab][Return]」で実行する。
TDDの場合、1分に複数回テストを実行する場合もあるので、起動が面倒だと地味にストレスがたまる。
また、第三者がメンテナンスを引き継ぐ場合、1クラス1テストクラスの原則に沿ってない場合、
どのテストクラスがどのクラスのテストなのかを把握するのが大変になる。
> なんか話の節々からJavaerっぽい感じを受けるけど、Javaでもpublicなinnerクラスを作って、
> ひとつのファイルに複数のテストクラスを入れるってことはしないのかな。
Javaは使ってない。
また、前述したとおり、一つのファイルに複数のテストクラスを入れることもしない。
> >個人的には、入れ子で書けたとしても、見た目がすっきりする以外のメリットはあまり感じない。
> それがすごく大事なんじゃないか。
見た目だけが大事なのであれば、コメントで区切るとかすればいいんじゃない？
> >そのため、class Fooに対するテストが複数テストクラスに分かれていると、テスト実行が面倒になる。
> それは複数のテストクラスを実行するのが面倒なテストツールが悪いのであって、
> テストを複数のクラスに分割すること自体は悪くはないと思う。
複数のテストクラスを実行するのが簡単なテストツールが存在するということと、
テストクラスを複数に分割することの是非は分けて考えなければならない。
自分の場合は、FooTestを実行する場合、コマンドラインで「xunitスペースFo[Tab][Return]」で実行する。
TDDの場合、1分に複数回テストを実行する場合もあるので、起動が面倒だと地味にストレスがたまる。
また、第三者がメンテナンスを引き継ぐ場合、1クラス1テストクラスの原則に沿ってない場合、
どのテストクラスがどのクラスのテストなのかを把握するのが大変になる。
> なんか話の節々からJavaerっぽい感じを受けるけど、Javaでもpublicなinnerクラスを作って、
> ひとつのファイルに複数のテストクラスを入れるってことはしないのかな。
Javaは使ってない。
また、前述したとおり、一つのファイルに複数のテストクラスを入れることもしない。
195デフォルトの名無しさん
2012/02/15(水) 11:53:55.66 テストを複数のクラスに分割することのデメリットをまとめておく。
1. class Fooのテストがどのテストクラスにあるのか一目でわからない
2. 起動が面倒になる（テストツールもある）
3. （これまで言わなかったが）複数のテストクラスで共通の処理が必要な場合に、
テストクラスが一つであった場合よりもコーディングが面倒になる。
コーディングが面倒になるということは、積極的なテストクラスのリファクタリングの妨げにもなる。
逆に、1クラス1テストクラスの原則を守るとした場合のデメリットは何だろう？
個人的には、特に見当たらないのだが……。
1. class Fooのテストがどのテストクラスにあるのか一目でわからない
2. 起動が面倒になる（テストツールもある）
3. （これまで言わなかったが）複数のテストクラスで共通の処理が必要な場合に、
テストクラスが一つであった場合よりもコーディングが面倒になる。
コーディングが面倒になるということは、積極的なテストクラスのリファクタリングの妨げにもなる。
逆に、1クラス1テストクラスの原則を守るとした場合のデメリットは何だろう？
個人的には、特に見当たらないのだが……。
196デフォルトの名無しさん
2012/02/15(水) 13:25:20.41 一ファイル一クラスが前提なのか、一ファイル複数クラスなのかがごっちゃになってる気がする
197デフォルトの名無しさん
2012/02/15(水) 20:39:13.34 テスト駆動なのに、駆動する前にどんなクラスを作るか決めちゃうの？
198デフォルトの名無しさん
2012/02/15(水) 20:45:13.85 どんなクラスを作るか決める
↓
テストを作る
↓
クラスを実装する
どんなクラスを作るか決めなきゃテストは作れねーよ
↓
テストを作る
↓
クラスを実装する
どんなクラスを作るか決めなきゃテストは作れねーよ
正確には「クラスのインタフェースだけはキッチリ決める、実装は決めない」。当然ブラックボックスで。
200デフォルトの名無しさん
2012/02/16(木) 10:33:22.15 >>197
クラスとテストクラスを成長させてく過程で、テストクラスをどいう風に作ってけばいいかって話でしょ
クラスとテストクラスを成長させてく過程で、テストクラスをどいう風に作ってけばいいかって話でしょ
201デフォルトの名無しさん
2012/02/16(木) 10:33:56.30 >>194
>見た目だけが大事なのであれば、コメントで区切るとかすればいいんじゃない？
入れ子にして階層的に表示できるから見やすくなる。コメントで区切るのは見やすくならない。
>> >そのため、class Fooに対するテストが複数テストクラスに分かれていると、テスト実行が面倒になる。
>> それは複数のテストクラスを実行するのが面倒なテストツールが悪いのであって、
>> テストを複数のクラスに分割すること自体は悪くはないと思う。
>
>複数のテストクラスを実行するのが簡単なテストツールが存在するということと、
>テストクラスを複数に分割することの是非は分けて考えなければならない。
うん、その通り。
そして「テストが複数テストクラスに分かれていると、テスト実行が面倒になる」と言い出したのはそっちなんだけどね。
>自分の場合は、FooTestを実行する場合、コマンドラインで「xunitスペースFo[Tab][Return]」で実行する。
>TDDの場合、1分に複数回テストを実行する場合もあるので、起動が面倒だと地味にストレスがたまる。
うん、だからそれは「複数のテストクラスを実行するのが面倒なテストツールが悪い」のであって、
テストを複数のクラスに分割することの是非とは関係ないよね。
>また、第三者がメンテナンスを引き継ぐ場合、1クラス1テストクラスの原則に沿ってない場合、
>どのテストクラスがどのクラスのテストなのかを把握するのが大変になる。
だから、それは「どのテストクラスがどのクラスのテストなのかを把握するのが大変になる」ようなコードを書いているのが悪いのであって、
テストを複数のクラスに分割することの是非とはあんまり関係ないよね。
>見た目だけが大事なのであれば、コメントで区切るとかすればいいんじゃない？
入れ子にして階層的に表示できるから見やすくなる。コメントで区切るのは見やすくならない。
>> >そのため、class Fooに対するテストが複数テストクラスに分かれていると、テスト実行が面倒になる。
>> それは複数のテストクラスを実行するのが面倒なテストツールが悪いのであって、
>> テストを複数のクラスに分割すること自体は悪くはないと思う。
>
>複数のテストクラスを実行するのが簡単なテストツールが存在するということと、
>テストクラスを複数に分割することの是非は分けて考えなければならない。
うん、その通り。
そして「テストが複数テストクラスに分かれていると、テスト実行が面倒になる」と言い出したのはそっちなんだけどね。
>自分の場合は、FooTestを実行する場合、コマンドラインで「xunitスペースFo[Tab][Return]」で実行する。
>TDDの場合、1分に複数回テストを実行する場合もあるので、起動が面倒だと地味にストレスがたまる。
うん、だからそれは「複数のテストクラスを実行するのが面倒なテストツールが悪い」のであって、
テストを複数のクラスに分割することの是非とは関係ないよね。
>また、第三者がメンテナンスを引き継ぐ場合、1クラス1テストクラスの原則に沿ってない場合、
>どのテストクラスがどのクラスのテストなのかを把握するのが大変になる。
だから、それは「どのテストクラスがどのクラスのテストなのかを把握するのが大変になる」ようなコードを書いているのが悪いのであって、
テストを複数のクラスに分割することの是非とはあんまり関係ないよね。
202デフォルトの名無しさん
2012/02/16(木) 10:40:08.70 >>195
>テストを複数のクラスに分割することのデメリットをまとめておく。
>
>1. class Fooのテストがどのテストクラスにあるのか一目でわからない
わかるようなコードの書き方は可能。そう書かないのが悪い。
>2. 起動が面倒になる（テストツールもある）
そんなテストツールを使うのが悪い。
>3. （これまで言わなかったが）複数のテストクラスで共通の処理が必要な場合に、
> テストクラスが一つであった場合よりもコーディングが面倒になる。
> コーディングが面倒になるということは、積極的なテストクラスのリファクタリングの妨げにもなる。
はい？共通の親クラスを作る、委譲を使う等、いくらでも手はあるけど。
>逆に、1クラス1テストクラスの原則を守るとした場合のデメリットは何だろう？
>個人的には、特に見当たらないのだが……。
もともとは、>>182や>>190に書いてあるように、メソッドという単位をどう扱うかの話だよ。
それに、今のxUnit系ツールはsetUpとtearDownがクラスごとにひとつだから、
違うsetUpとtearDownを使いたい場合はテストクラスを分けざるを得ない。
つまり1クラス1テストクラスだとfixtureが1種類に固定される。
>テストを複数のクラスに分割することのデメリットをまとめておく。
>
>1. class Fooのテストがどのテストクラスにあるのか一目でわからない
わかるようなコードの書き方は可能。そう書かないのが悪い。
>2. 起動が面倒になる（テストツールもある）
そんなテストツールを使うのが悪い。
>3. （これまで言わなかったが）複数のテストクラスで共通の処理が必要な場合に、
> テストクラスが一つであった場合よりもコーディングが面倒になる。
> コーディングが面倒になるということは、積極的なテストクラスのリファクタリングの妨げにもなる。
はい？共通の親クラスを作る、委譲を使う等、いくらでも手はあるけど。
>逆に、1クラス1テストクラスの原則を守るとした場合のデメリットは何だろう？
>個人的には、特に見当たらないのだが……。
もともとは、>>182や>>190に書いてあるように、メソッドという単位をどう扱うかの話だよ。
それに、今のxUnit系ツールはsetUpとtearDownがクラスごとにひとつだから、
違うsetUpとtearDownを使いたい場合はテストクラスを分けざるを得ない。
つまり1クラス1テストクラスだとfixtureが1種類に固定される。
203デフォルトの名無しさん
2012/02/16(木) 11:13:49.50 >>201
> テストを複数のクラスに分割することの是非とはあんまり関係ないよね。
テストを複数のクラスに分割すると、50個のクラスのテストが200個のテストクラスになったりする。
さて、class Fooに対するテストはどのファイルにあるのか簡単にわかるだろうか。
そして、class Barにメソッドを追加したくなったとき、どのファイルにテストを追加すればいいか、簡単にわかるだろうか。
これはテストコードの書き方が良いとか悪いとかの話では無くて、テストクラスの管理の話だね。
自分はこううまく管理するから問題ない、こううまくテストコードを書くから問題ないという特殊化を
するんじゃなくて、一般的に「1クラス1テストクラス」という原則を採用する/しない場合のメリットと
デメリットを話すので無ければ、あまりこの議論に価値を見いだせない。
> はい？共通の親クラスを作る、委譲を使う等、いくらでも手はあるけど。
プロダクトコードをどう実装するかの話と、DevelopmentをDrivenするTestコードなんだから、
素早く、シンプルに、なおかつ重複コードなどないテストコードを書けるようにしておいた方が良くない？
「1クラス1テストクラス」なら、共通の親クラスを作る必要も、委譲を使う必要も無く、ただ単に
private methodを一つ追加すればいいだけだよね。
> もともとは、>>182や>>190に書いてあるように、メソッドという単位をどう扱うかの話だよ。
そう。そして>>190は俺のコメント。
そうせざるを得ない場合をのぞいて、テストを複数のクラスに分割することのメリットを話してよ。
> テストを複数のクラスに分割することの是非とはあんまり関係ないよね。
テストを複数のクラスに分割すると、50個のクラスのテストが200個のテストクラスになったりする。
さて、class Fooに対するテストはどのファイルにあるのか簡単にわかるだろうか。
そして、class Barにメソッドを追加したくなったとき、どのファイルにテストを追加すればいいか、簡単にわかるだろうか。
これはテストコードの書き方が良いとか悪いとかの話では無くて、テストクラスの管理の話だね。
自分はこううまく管理するから問題ない、こううまくテストコードを書くから問題ないという特殊化を
するんじゃなくて、一般的に「1クラス1テストクラス」という原則を採用する/しない場合のメリットと
デメリットを話すので無ければ、あまりこの議論に価値を見いだせない。
> はい？共通の親クラスを作る、委譲を使う等、いくらでも手はあるけど。
プロダクトコードをどう実装するかの話と、DevelopmentをDrivenするTestコードなんだから、
素早く、シンプルに、なおかつ重複コードなどないテストコードを書けるようにしておいた方が良くない？
「1クラス1テストクラス」なら、共通の親クラスを作る必要も、委譲を使う必要も無く、ただ単に
private methodを一つ追加すればいいだけだよね。
> もともとは、>>182や>>190に書いてあるように、メソッドという単位をどう扱うかの話だよ。
そう。そして>>190は俺のコメント。
そうせざるを得ない場合をのぞいて、テストを複数のクラスに分割することのメリットを話してよ。
204デフォルトの名無しさん
2012/02/16(木) 11:14:46.80 s/プロダクトコードをどう実装するかの話と/プロダクトコードをどう実装するかの話ではなくて/
205デフォルトの名無しさん
2012/02/16(木) 11:33:16.62 例えば、
-----------------
class XmlOutputter
-----------------
+addHook()
+removeHook()
+write()
+setStyleSheet()
+setRootNode()
+addFailedTest()
+addSuccessfulTest()
+addStatistics()
みたいなクラスを実装しようとしているとき、各メソッド用のテストが5個できるとすると、
テストメソッドは合計40個できることになるけど、これってclass XmlOutputterTestに全部入ってれば、
自分も含めて誰もがどこに何のテストがあるかすぐにわかるし、どんなツールでも簡単に
class XmlOutputterのテストを全部実行できる。
分かり易くない？
-----------------
class XmlOutputter
-----------------
+addHook()
+removeHook()
+write()
+setStyleSheet()
+setRootNode()
+addFailedTest()
+addSuccessfulTest()
+addStatistics()
みたいなクラスを実装しようとしているとき、各メソッド用のテストが5個できるとすると、
テストメソッドは合計40個できることになるけど、これってclass XmlOutputterTestに全部入ってれば、
自分も含めて誰もがどこに何のテストがあるかすぐにわかるし、どんなツールでも簡単に
class XmlOutputterのテストを全部実行できる。
分かり易くない？
206デフォルトの名無しさん
2012/02/16(木) 11:55:55.23 そもそも>>182の上のコードを不自然と感じる感性がわからんわ
207デフォルトの名無しさん
2012/02/16(木) 12:33:32.95 見づらい見づらいって、コード折りたたみ機能があるIDEかエディター使えよ
208デフォルトの名無しさん
2012/02/16(木) 19:40:28.42 ケントベックの本だと、
いきなり最初からテストクラスとそこから作ったクラスが違う
あとの方でクラスを抽象化してテストクラスの名前と同じようにしてるけど
結果論なのか始めから見通しを立ててたからか
あんなのTDDじゃないとかいう人もいるけど
いきなり最初からテストクラスとそこから作ったクラスが違う
あとの方でクラスを抽象化してテストクラスの名前と同じようにしてるけど
結果論なのか始めから見通しを立ててたからか
あんなのTDDじゃないとかいう人もいるけど
209デフォルトの名無しさん
2012/02/16(木) 20:00:14.54 ケントベック式TDDならTODO駆動なのだから
TODOの分類とフィクスチャでテストクラスを割り当てていくんだろうなぁ
TODOの分類とフィクスチャでテストクラスを割り当てていくんだろうなぁ
210デフォルトの名無しさん
2012/02/17(金) 10:36:38.68 ケントベック本の例は、今考えると自動受け入れテスト用コードっぽい気がする
211デフォルトの名無しさん
2012/02/17(金) 10:53:12.35 >>208
TDDBCなんかだと、Stackクラスを作るからStackTestね、てな感じで誰も疑問を覚えずスルーだよ
TDDBCなんかだと、Stackクラスを作るからStackTestね、てな感じで誰も疑問を覚えずスルーだよ
212デフォルトの名無しさん
2012/02/17(金) 11:11:51.43 lヽ ﾉ l ｌ l ｌ ヽ ヽ
)'ｰーノ( | | | ､ / l｜ ｌ ハヽ |ｰ‐''"ｌ
/ Ｔ | | |／| ﾊ / / ,/ /|ﾉ /l / ｌ l ｌ| ｌ Ｔ ヽ
l ･ i´ | ヽ､| |ｒ|| | //--‐'" ｀'メ､_ｌﾉ| / ・ /
| Ｄ l トー-トヽ| |ノ ''"´｀ ｒｰ-/// | Ｄ ｜
| ･ |／ | l ||､ ''""" j ""''/ | |ヽｌ ・ ｜
| Ｄ | | l | ヽ, ― ／ | | ｌ Ｄ |
| !! | / | | | ` ｰ-‐ ' ´|| ,ﾉ| | | !! ｜
ノｰ‐---､,| / │ｌ､l |ﾚ' ,ﾉﾉ ﾉハ､_ノヽ
/ ／ ノ⌒ヾ､ ヽ ノハ, |
,/ ,イーｆ'´ /´ ＼ | ,／´ ｜ヽl |
／-ト、| ┼―- ､_ヽﾒr' , -=ｌ''"ハ | ｌ
,／ | ヽ ＼ _,ノｰｆ' ´ ﾉノ ヽ ｜ |
､_ _ ‐''ｌ `ー‐―''" ⌒'ｰ--‐'´｀ヽ､_ _,ノ ノ
￣￣ | ／ ￣
)'ｰーノ( | | | ､ / l｜ ｌ ハヽ |ｰ‐''"ｌ
/ Ｔ | | |／| ﾊ / / ,/ /|ﾉ /l / ｌ l ｌ| ｌ Ｔ ヽ
l ･ i´ | ヽ､| |ｒ|| | //--‐'" ｀'メ､_ｌﾉ| / ・ /
| Ｄ l トー-トヽ| |ノ ''"´｀ ｒｰ-/// | Ｄ ｜
| ･ |／ | l ||､ ''""" j ""''/ | |ヽｌ ・ ｜
| Ｄ | | l | ヽ, ― ／ | | ｌ Ｄ |
| !! | / | | | ` ｰ-‐ ' ´|| ,ﾉ| | | !! ｜
ノｰ‐---､,| / │ｌ､l |ﾚ' ,ﾉﾉ ﾉハ､_ノヽ
/ ／ ノ⌒ヾ､ ヽ ノハ, |
,/ ,イーｆ'´ /´ ＼ | ,／´ ｜ヽl |
／-ト、| ┼―- ､_ヽﾒr' , -=ｌ''"ハ | ｌ
,／ | ヽ ＼ _,ノｰｆ' ´ ﾉノ ヽ ｜ |
､_ _ ‐''ｌ `ー‐―''" ⌒'ｰ--‐'´｀ヽ､_ _,ノ ノ
￣￣ | ／ ￣
213デフォルトの名無しさん
2012/02/19(日) 12:47:19.61 > もともとは、>>182や>>190に書いてあるように、メソッドという単位をどう扱うかの話だよ。
クラスを単位とするテストは、複数のメソッドにまたがることもあるから、
メソッド単位で分けられない場合もあるよ。
関数型プログラミング的な、メソッドの返す結果がそのメソッドの引数のみによって
決まる場合は、純粋にメソッドを単位としたテストができるけど、
オブジェクト指向プログラミングにありがちな、更新系のメソッドと参照系のメソッドがあって、
それらを順次呼び出すようなテストをする場合は、メソッド単位に分けにくい。
だから、テストを対象のメソッドによって分類するとか、それをテストコードでどう表現するか
という普遍的な方針は立てにくい。
はっきりした方針が立てられないのであれば、始めから分けない方が考えなくていい分楽だし、
分けるにしてもあまり分け方に拘らず依存せずゆるくやっていった方がいいと思う。
クラスを単位とするテストは、複数のメソッドにまたがることもあるから、
メソッド単位で分けられない場合もあるよ。
関数型プログラミング的な、メソッドの返す結果がそのメソッドの引数のみによって
決まる場合は、純粋にメソッドを単位としたテストができるけど、
オブジェクト指向プログラミングにありがちな、更新系のメソッドと参照系のメソッドがあって、
それらを順次呼び出すようなテストをする場合は、メソッド単位に分けにくい。
だから、テストを対象のメソッドによって分類するとか、それをテストコードでどう表現するか
という普遍的な方針は立てにくい。
はっきりした方針が立てられないのであれば、始めから分けない方が考えなくていい分楽だし、
分けるにしてもあまり分け方に拘らず依存せずゆるくやっていった方がいいと思う。
214デフォルトの名無しさん
2012/02/20(月) 10:12:32.84 >>213
このスレ、TDDスレなんだけど
このスレ、TDDスレなんだけど
215デフォルトの名無しさん
2012/02/20(月) 15:47:45.19 どんな言語・開発環境でも、一つのクラス対一つのテスト用クラスに勝るものはないと思う。
ただ、一つのテスト用クラスに何百ものテストメソッドがあって、実行するのに5秒とかかかるのなら
わけたくなると思うけど、そんなでかいテスト用クラス作ったこと無い。
ただ、一つのテスト用クラスに何百ものテストメソッドがあって、実行するのに5秒とかかかるのなら
わけたくなると思うけど、そんなでかいテスト用クラス作ったこと無い。
216デフォルトの名無しさん
2012/02/28(火) 14:45:23.66 1クラス-1テストクラスじゃない構成でやってる奴がいるのに驚いた。
217デフォルトの名無しさん
2012/04/21(土) 21:51:02.83 これ一番の敵は自分の意識だな
ついつい先にコード書きたくなってモヤモヤしちゃう
ついつい先にコード書きたくなってモヤモヤしちゃう
218デフォルトの名無しさん
2012/04/21(土) 22:56:13.23 全くだ
自制心が試されるよクソっ
自制心が試されるよクソっ
219デフォルトの名無しさん
2012/04/25(水) 00:12:32.14 JavaのServerSocket#accept()みたいなブロッキングメソッドを使うメソッドって
どうテストすればいいんだろう
どうテストすればいいんだろう
220デフォルトの名無しさん
2012/04/25(水) 11:49:37.34 「自分は頭が良くて詳しいです」的な自己満足レスの典型だぞ。
相手は超初心者なんだからもう少し優しく教えてあげないと。
さもなくばスルーでOK
相手は超初心者なんだからもう少し優しく教えてあげないと。
さもなくばスルーでOK
221デフォルトの名無しさん
2012/05/10(木) 22:50:42.22 eclipse+java でオススメのテストプラグインおしえてくだしゃあ
222デフォルトの名無しさん
2012/06/22(金) 10:47:09.07 「Rational テスト仮想化／自動化ソリューション」
テスト期間10日が10分に！日本IBMが仮想テスト環境ツール 2012年06月22日 06時00分更新
ttp://ascii.jp/elem/000/000/703/703943/
6月21日、日本IBMは仮想的なテスト環境を自動構築するソリューション
「Rational テスト仮想化／自動化ソリューション」を発表した。
Rational テスト仮想化／自動化ソリューションは、テスト対象となるシステムへの入出力を
仮想的かつ自動的に再現する機能を持つ。これにより、テスト対象システムと接続するシステムの
完成を待ったり、稼働を停止する必要がなくなり、テスト環境を実際に構築することなく接続テストを
実施できる。結果として、テスト時間の短縮やテスト環境構築への投資と手間の削減が実現する。
また、仮想化環境での接続テストが可能になることで、システム開発工程の早い段階で
不具合の修正ができるため、開発の最終段階での大幅な変更や品質問題発覚による開発遅延の
低減が可能となり、顧客へのサービス開始の遅れや追加コストの発生を防ぐとしている。
たとえば、海外の金融機関では、テストの大部分を自動化できたことで、手作業による
テスト期間を10日から10分に削減したという。また、ある製造企業は、従来6カ月かかっていた
システム構築を2カ月短縮し、4カ月で完成させたとしている。
IBM Rational テスト仮想化／自動化ソリューションの使用料金は、4000万円（100PVU）から。
テスト期間10日が10分に！日本IBMが仮想テスト環境ツール 2012年06月22日 06時00分更新
ttp://ascii.jp/elem/000/000/703/703943/
6月21日、日本IBMは仮想的なテスト環境を自動構築するソリューション
「Rational テスト仮想化／自動化ソリューション」を発表した。
Rational テスト仮想化／自動化ソリューションは、テスト対象となるシステムへの入出力を
仮想的かつ自動的に再現する機能を持つ。これにより、テスト対象システムと接続するシステムの
完成を待ったり、稼働を停止する必要がなくなり、テスト環境を実際に構築することなく接続テストを
実施できる。結果として、テスト時間の短縮やテスト環境構築への投資と手間の削減が実現する。
また、仮想化環境での接続テストが可能になることで、システム開発工程の早い段階で
不具合の修正ができるため、開発の最終段階での大幅な変更や品質問題発覚による開発遅延の
低減が可能となり、顧客へのサービス開始の遅れや追加コストの発生を防ぐとしている。
たとえば、海外の金融機関では、テストの大部分を自動化できたことで、手作業による
テスト期間を10日から10分に削減したという。また、ある製造企業は、従来6カ月かかっていた
システム構築を2カ月短縮し、4カ月で完成させたとしている。
IBM Rational テスト仮想化／自動化ソリューションの使用料金は、4000万円（100PVU）から。
223デフォルトの名無しさん
2012/06/22(金) 11:44:41.54 10日を10分で実行できる環境を整えるのに、20日かかるとか
224デフォルトの名無しさん
2012/10/09(火) 17:59:06.08225デフォルトの名無しさん
2012/10/14(日) 17:07:49.10 仕様書が先にできているときに限って
テスト駆動開発は出来る。
つまり、現実的には無理
テスト駆動開発は出来る。
つまり、現実的には無理
226デフォルトの名無しさん
2012/10/14(日) 17:17:10.03 >>225
アジャイルと組合せるんじゃねの？
アジャイルと組合せるんじゃねの？
227デフォルトの名無しさん
2012/10/14(日) 17:37:55.63 仕様なしでどうやって書くんだ
228デフォルトの名無しさん
2012/10/15(月) 03:15:49.84 どこの世界線の現実なんだ
229デフォルトの名無しさん
2012/10/21(日) 11:00:46.22230デフォルトの名無しさん
2012/10/22(月) 16:02:45.79231デフォルトの名無しさん
2013/01/06(日) 22:49:09.88 Windows で、googletest ライブラリを MinGW gcc 使ってコンパイルしたんだけど、
テストプログラムの実行ファイルのサイズがわりとデカイような気がするんだが。
http://www.atmarkit.co.jp/fdotnet/cpptest/cpptest02/cpptest02_02.html
これは CppUnit でテストしてる例だけど、
同じ例を googletest でテストする実行ファイルを作ると、
googletest を静的にリンクするように作った場合は7MBくらい。
動的リンクするように作った場合でも6MB後半くらい。
こんなもの？
テスト対象が小さすぎるから、ファイルがでかく感じるだけ？
テストプログラムの実行ファイルのサイズがわりとデカイような気がするんだが。
http://www.atmarkit.co.jp/fdotnet/cpptest/cpptest02/cpptest02_02.html
これは CppUnit でテストしてる例だけど、
同じ例を googletest でテストする実行ファイルを作ると、
googletest を静的にリンクするように作った場合は7MBくらい。
動的リンクするように作った場合でも6MB後半くらい。
こんなもの？
テスト対象が小さすぎるから、ファイルがでかく感じるだけ？
232デフォルトの名無しさん
2013/01/11(金) 22:15:15.06 試してないけど、strip コマンドでデバッグシンボル削って小さく出来ないかな？
233デフォルトの名無しさん
2013/01/19(土) 19:00:11.13234デフォルトの名無しさん
2013/01/20(日) 14:26:02.13 ゲーム製作において、自動化できる受け入れテストはあるか？
235デフォルトの名無しさん
2013/01/29(火) 21:14:09.89 テスト駆動のテストは単体テストあるよ
236デフォルトの名無しさん
2013/01/29(火) 21:52:26.88237デフォルトの名無しさん
2013/03/07(木) 22:25:23.26 配列の値を個々テストしたい
配列の中身の型も要素数も決まってる。要素数は10。
というか、単に配列の添字が違うだけで、それらの要素について行う処理やテスト項目は同じ。
だからテストもループで回したくなってしまう。
でもテストコードでループ使ってassertを繰り返すのっていいの？
それとも記載が冗長になるのを我慢してテストコードをコピペしては添字を変えていくのがいいの？
その辺についてスタンダードや、あるいは解説した文書などありましたらお教えください
配列の中身の型も要素数も決まってる。要素数は10。
というか、単に配列の添字が違うだけで、それらの要素について行う処理やテスト項目は同じ。
だからテストもループで回したくなってしまう。
でもテストコードでループ使ってassertを繰り返すのっていいの？
それとも記載が冗長になるのを我慢してテストコードをコピペしては添字を変えていくのがいいの？
その辺についてスタンダードや、あるいは解説した文書などありましたらお教えください
238デフォルトの名無しさん
2013/03/07(木) 23:02:09.96 >>237
> だからテストもループで回したくなってしまう。
それが正解。
> でもテストコードでループ使ってassertを繰り返すのっていいの？
ループで回す先の要素の失敗によって
後続のテストに信頼性が失われるのなら、
assertを使うべき。
各要素がそれぞれ他の要素から独立しており、
個々のテストの成否が他のテストに影響を与えないのなら、
テストの成否に関わらず後続のテストを続けるタイプの
テスト関数（マクロ）を使うべき。
（例えば gtest なら EXPECT_* マクロ）
> だからテストもループで回したくなってしまう。
それが正解。
> でもテストコードでループ使ってassertを繰り返すのっていいの？
ループで回す先の要素の失敗によって
後続のテストに信頼性が失われるのなら、
assertを使うべき。
各要素がそれぞれ他の要素から独立しており、
個々のテストの成否が他のテストに影響を与えないのなら、
テストの成否に関わらず後続のテストを続けるタイプの
テスト関数（マクロ）を使うべき。
（例えば gtest なら EXPECT_* マクロ）
239デフォルトの名無しさん
2013/03/07(木) 23:55:12.86240デフォルトの名無しさん
2013/03/08(金) 07:02:25.85 ちなみに、後続のテストの信頼性が失われるかどうかの判断は、
意外に難しかったりするから注意。
理論上は依存しない仕様のプログラムが、
本当に依存していないかどうかを調べるのも
テストする動機のひとつであることを忘れずに。
意外に難しかったりするから注意。
理論上は依存しない仕様のプログラムが、
本当に依存していないかどうかを調べるのも
テストする動機のひとつであることを忘れずに。
241デフォルトの名無しさん
2013/03/08(金) 11:53:10.03 TDDなんだから、失敗したらそこで終了で良いのでは？
何で続けたいのかしら。
何で続けたいのかしら。
242デフォルトの名無しさん
2013/03/08(金) 12:36:28.56 >>241
独立したテストなら、結果を一覧できた方が作業効率が良い
独立したテストなら、結果を一覧できた方が作業効率が良い
243デフォルトの名無しさん
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なんだから。
ちょっと言ってることが良くわからない。
ひょっとして「後続のテスト」と言ってるのは、
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なんだから。
244デフォルトの名無しさん
2013/03/08(金) 14:38:22.75 というか、
>>238
> テストの成否に関わらず後続のテストを続けるタイプの
> テスト関数（マクロ）を使うべき。
> （例えば gtest なら EXPECT_* マクロ）
これも良くわからない。
普通のテストツールって、テストが失敗しても後続のテストは続けるんじゃないの？
gtestは知らないけど、gtestってテストが失敗したらそこで終わっちゃうの？
「後続のテスト」というのが、あるテストメソッド内の複数のassertionのことなら前述した通り。
>>238
> テストの成否に関わらず後続のテストを続けるタイプの
> テスト関数（マクロ）を使うべき。
> （例えば gtest なら EXPECT_* マクロ）
これも良くわからない。
普通のテストツールって、テストが失敗しても後続のテストは続けるんじゃないの？
gtestは知らないけど、gtestってテストが失敗したらそこで終わっちゃうの？
「後続のテスト」というのが、あるテストメソッド内の複数のassertionのことなら前述した通り。
245デフォルトの名無しさん
2013/03/08(金) 14:53:32.40 質問者が回答者にレスするスレはここですか？
246デフォルトの名無しさん
2013/03/08(金) 17:01:39.12247デフォルトの名無しさん
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 などの独立したテストの結果は一望できた方が良いと私は思う。
例えば、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 などの独立したテストの結果は一望できた方が良いと私は思う。
248デフォルトの名無しさん
2013/03/08(金) 22:21:28.50249デフォルトの名無しさん
2013/03/08(金) 23:47:04.07 それもそうか
250デフォルトの名無しさん
2013/04/28(日) 19:09:53.06 これから本買って読もうと思いますが、TDDにxUnit的ツールは必須なんでしょうか
コンソールに結果出力するだけでもいいのでしょうか
コンソールに結果出力するだけでもいいのでしょうか
251デフォルトの名無しさん
2013/04/28(日) 19:34:15.22 あった方が断然楽しい
252デフォルトの名無しさん
2013/04/28(日) 20:08:05.56 あった方がいいのは分かりますが、必須ではなさそうですね
HEW+ルネサスコンパイラで、ツール買う予算も取れないので、assertとprintfで凌ぎます
HEW+ルネサスコンパイラで、ツール買う予算も取れないので、assertとprintfで凌ぎます
■ このスレッドは過去ログ倉庫に格納されています
