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

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

ツールについては別スレで
テストツールについて語るスレ 2
http://hibari.2ch.net/test/read.cgi/tech/1208013693/
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
誰？
どこに何を発言したの？
見たこと無いけど。
147デフォルトの名無しさん
垢版 |
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
とん、これ参考にお盆中にゴニョゴニョがんばってみる。
2011/09/13(火) 04:36:12.81
test
2011/09/14(水) 08:40:20.36
test
2011/09/14(水) 22:59:28.96
自動化テストに対するテストはどうやって…とかグダグダ言う奴って基本的に信頼できん。
じゃあ、お前は手動で行うテスト仕様書に対してテスト仕様書書いて実施してんのかと。
どっちも最終的にはレビューして担保するしかねーんだよ。
2011/09/15(木) 00:22:15.84
test
158デフォルトの名無しさん
垢版 |
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
2011/09/16(金) 01:45:17.33
test
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
どんなクラスを作るか決める
↓
テストを作る
↓
クラスを実装する

どんなクラスを作るか決めなきゃテストは作れねーよ
NGNG?PLT(12101)
正確には「クラスのインタフェースだけはキッチリ決める、実装は決めない」。当然ブラックボックスで。
2012/02/16(木) 10:33:22.15
>>197
クラスとテストクラスを成長させてく過程で、テストクラスをどいう風に作ってけばいいかって話でしょ
2012/02/16(木) 10:33:56.30
>>194
>見た目だけが大事なのであれば、コメントで区切るとかすればいいんじゃない？
入れ子にして階層的に表示できるから見やすくなる。コメントで区切るのは見やすくならない。

>> >そのため、class Fooに対するテストが複数テストクラスに分かれていると、テスト実行が面倒になる。
>> それは複数のテストクラスを実行するのが面倒なテストツールが悪いのであって、
>> テストを複数のクラスに分割すること自体は悪くはないと思う。
>
>複数のテストクラスを実行するのが簡単なテストツールが存在するということと、
>テストクラスを複数に分割することの是非は分けて考えなければならない。
うん、その通り。
そして「テストが複数テストクラスに分かれていると、テスト実行が面倒になる」と言い出したのはそっちなんだけどね。

>自分の場合は、FooTestを実行する場合、コマンドラインで「xunitスペースFo[Tab][Return]」で実行する。
>TDDの場合、1分に複数回テストを実行する場合もあるので、起動が面倒だと地味にストレスがたまる。
うん、だからそれは「複数のテストクラスを実行するのが面倒なテストツールが悪い」のであって、
テストを複数のクラスに分割することの是非とは関係ないよね。

>また、第三者がメンテナンスを引き継ぐ場合、1クラス1テストクラスの原則に沿ってない場合、
>どのテストクラスがどのクラスのテストなのかを把握するのが大変になる。
だから、それは「どのテストクラスがどのクラスのテストなのかを把握するのが大変になる」ようなコードを書いているのが悪いのであって、
テストを複数のクラスに分割することの是非とはあんまり関係ないよね。

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種類に固定される。
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は俺のコメント。

そうせざるを得ない場合をのぞいて、テストを複数のクラスに分割することのメリットを話してよ。
2012/02/16(木) 11:14:46.80
s/プロダクトコードをどう実装するかの話と/プロダクトコードをどう実装するかの話ではなくて/
2012/02/16(木) 11:33:16.62
例えば、
-----------------
class XmlOutputter
-----------------
+addHook()
+removeHook()
+write()
+setStyleSheet()
+setRootNode()
+addFailedTest()
+addSuccessfulTest()
+addStatistics()

みたいなクラスを実装しようとしているとき、各メソッド用のテストが5個できるとすると、
テストメソッドは合計40個できることになるけど、これってclass XmlOutputterTestに全部入ってれば、
自分も含めて誰もがどこに何のテストがあるかすぐにわかるし、どんなツールでも簡単に
class XmlOutputterのテストを全部実行できる。
分かり易くない？
2012/02/16(木) 11:55:55.23
そもそも>>182の上のコードを不自然と感じる感性がわからんわ
2012/02/16(木) 12:33:32.95
見づらい見づらいって、コード折りたたみ機能があるIDEかエディター使えよ
2012/02/16(木) 19:40:28.42
ケントベックの本だと、
いきなり最初からテストクラスとそこから作ったクラスが違う
あとの方でクラスを抽象化してテストクラスの名前と同じようにしてるけど
結果論なのか始めから見通しを立ててたからか

あんなのTDDじゃないとかいう人もいるけど
2012/02/16(木) 20:00:14.54
ケントベック式TDDならTODO駆動なのだから
TODOの分類とフィクスチャでテストクラスを割り当てていくんだろうなぁ
2012/02/17(金) 10:36:38.68
ケントベック本の例は、今考えると自動受け入れテスト用コードっぽい気がする
2012/02/17(金) 10:53:12.35
>>208
TDDBCなんかだと、Stackクラスを作るからStackTestね、てな感じで誰も疑問を覚えずスルーだよ
2012/02/17(金) 11:11:51.43
　　　　　　　 lヽ ﾉ l　　　　　　　　ｌ l　ｌ ヽ　　 ヽ
　 )'ｰーノ(　 |　|　 | ､　　　　　 / l｜ ｌ　ハヽ　　|ｰ‐''"ｌ
　/　Ｔ　　|　|　|／| ﾊ　　/ / ,/ /|ﾉ /l /　ｌ l ｌ|　ｌ　 Ｔ ヽ
　l 　 ･　　i´ |　ヽ､| |ｒ|| |　//--‐'" 　 ｀'メ､_ｌﾉ| /　 ・　 /
　|　 Ｄ　　l　 トー-トヽ| |ノ　''"´｀　　　ｒｰ-/// |　 Ｄ　｜
　|　 ･　　 |／　　 　 | l ||､　''"""　 j　""''/ | |ヽｌ 　・　｜
　|　 Ｄ 　 |　　 　 　 | l |　ヽ,　 　― 　 ／　| |　ｌ　 Ｄ　 |
　| 　 !!　 |　　 　 /　| | |　　 ` ｰ-‐ ' ´||　,ﾉ| |　|　　!!　｜
ノｰ‐---､,|　 　 /　│ｌ､l　　　　　　 　 |ﾚ' ,ﾉﾉ　ﾉハ､_ノヽ
　/ 　　 　 　 ／　ノ⌒ヾ､　 ヽ　　　 ノハ,　　　 　 |
,/ 　 　　　,イーｆ'´ /´　　＼　| ,／´ ｜ヽl　　　 　 |
　　　　 ／-ト、|　┼―- ､_ヽﾒr'　, -=ｌ''"ハ　　　　|　 ｌ
　　 ,／　 　|　ヽ 　＼　　_,ノｰｆ' ´　　ﾉノ　 ヽ　 　｜　|
､_　　　 _ ‐''ｌ　　`ー‐―''" ⌒'ｰ--‐'´｀ヽ､_ 　　_,ノ　ノ
　 ￣￣　　 |　　　　　　　　　　 ／　 　　　　￣
2012/02/19(日) 12:47:19.61
> もともとは、>>182や>>190に書いてあるように、メソッドという単位をどう扱うかの話だよ。

クラスを単位とするテストは、複数のメソッドにまたがることもあるから、
メソッド単位で分けられない場合もあるよ。

関数型プログラミング的な、メソッドの返す結果がそのメソッドの引数のみによって
決まる場合は、純粋にメソッドを単位としたテストができるけど、
オブジェクト指向プログラミングにありがちな、更新系のメソッドと参照系のメソッドがあって、
それらを順次呼び出すようなテストをする場合は、メソッド単位に分けにくい。

だから、テストを対象のメソッドによって分類するとか、それをテストコードでどう表現するか
という普遍的な方針は立てにくい。
はっきりした方針が立てられないのであれば、始めから分けない方が考えなくていい分楽だし、
分けるにしてもあまり分け方に拘らず依存せずゆるくやっていった方がいいと思う。
2012/02/20(月) 10:12:32.84
>>213
このスレ、TDDスレなんだけど
2012/02/20(月) 15:47:45.19
どんな言語・開発環境でも、一つのクラス対一つのテスト用クラスに勝るものはないと思う。
ただ、一つのテスト用クラスに何百ものテストメソッドがあって、実行するのに5秒とかかかるのなら
わけたくなると思うけど、そんなでかいテスト用クラス作ったこと無い。
2012/02/28(火) 14:45:23.66
1クラス-1テストクラスじゃない構成でやってる奴がいるのに驚いた。
2012/04/21(土) 21:51:02.83
これ一番の敵は自分の意識だな
ついつい先にコード書きたくなってモヤモヤしちゃう
2012/04/21(土) 22:56:13.23
全くだ
自制心が試されるよクソっ
2012/04/25(水) 00:12:32.14
JavaのServerSocket#accept()みたいなブロッキングメソッドを使うメソッドって
どうテストすればいいんだろう
2012/04/25(水) 11:49:37.34
「自分は頭が良くて詳しいです」的な自己満足レスの典型だぞ。
相手は超初心者なんだからもう少し優しく教えてあげないと。
さもなくばスルーでOK
2012/05/10(木) 22:50:42.22
eclipse+java でオススメのテストプラグインおしえてくだしゃあ
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）から。
2012/06/22(金) 11:44:41.54
10日を10分で実行できる環境を整えるのに、20日かかるとか
224デフォルトの名無しさん
垢版 |
2012/10/09(火) 17:59:06.08
225デフォルトの名無しさん
垢版 |
2012/10/14(日) 17:07:49.10
仕様書が先にできているときに限って
テスト駆動開発は出来る。

つまり、現実的には無理
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。