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

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

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

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

**デフォルトの名無しさん** · 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
クラスとテストクラスを成長させてく過程で、テストクラスをどいう風に作ってけばいいかって話でしょ

**デフォルトの名無しさん** · 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日かかるとか

**デフォルトの名無しさん** · 2012/10/09(火) 17:59:06.08

**デフォルトの名無しさん** · 2012/10/14(日) 17:07:49.10

仕様書が先にできているときに限って
テスト駆動開発は出来る。

つまり、現実的には無理

**デフォルトの名無しさん** · 2012/10/14(日) 17:17:10.03

>>225
アジャイルと組合せるんじゃねの？

**デフォルトの名無しさん** · 2012/10/14(日) 17:37:55.63

仕様なしでどうやって書くんだ

**デフォルトの名無しさん** · 2012/10/15(月) 03:15:49.84

どこの世界線の現実なんだ

**デフォルトの名無しさん** · 2012/10/21(日) 11:00:46.22

>>225
開発手法だからアジャイルとウォーターフォールをごちゃ混ぜにしているだろ。

施工方法を根幹から変えて、仕事を受ける方法も根幹から変えないとテスト駆動開発は無理。

**デフォルトの名無しさん** · 2012/10/22(月) 16:02:45.79

>>225
関数やクラスメソッドを実装するとき、
そのれらをテストするコード先に書くのがテストファーストだっけ？

テスト駆動はどんなんだっけ？

**デフォルトの名無しさん** · 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後半くらい。

こんなもの？
テスト対象が小さすぎるから、ファイルがでかく感じるだけ？

**デフォルトの名無しさん** · 2013/01/11(金) 22:15:15.06

試してないけど、strip コマンドでデバッグシンボル削って小さく出来ないかな？

**デフォルトの名無しさん** · 2013/01/19(土) 19:00:11.13

>>232
ありがと、確かに小さくなった。

数個のユニットテストを作るだけでも
こんなに大きくなるのかという思いは拭えんが、
まぁそういうものだと思う事にするよ。

**デフォルトの名無しさん** · 2013/01/20(日) 14:26:02.13

ゲーム製作において、自動化できる受け入れテストはあるか？

**デフォルトの名無しさん** · 2013/01/29(火) 21:14:09.89

テスト駆動のテストは単体テストあるよ

**デフォルトの名無しさん** · 2013/01/29(火) 21:52:26.88

>>235
実践テスト駆動開発（http://www.amazon.co.jp/dp/4798124583）

これには受け入れテストもあるが

このスレでは単体テスト限定という意味？

**デフォルトの名無しさん** · 2013/03/07(木) 22:25:23.26

配列の値を個々テストしたい
配列の中身の型も要素数も決まってる。要素数は10。

というか、単に配列の添字が違うだけで、それらの要素について行う処理やテスト項目は同じ。

だからテストもループで回したくなってしまう。
でもテストコードでループ使ってassertを繰り返すのっていいの？

それとも記載が冗長になるのを我慢してテストコードをコピペしては添字を変えていくのがいいの？

その辺についてスタンダードや、あるいは解説した文書などありましたらお教えください

**デフォルトの名無しさん** · 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も使えるだろうが

アホ · 2013/05/01(水) 05:26:40.17

CUnitとかCppUnit etcって、makeする時に実行されるもんじゃないの?
バイナリ実行すればコンソールに表示されるようなもんなの?

アホ · 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を自分で定義できなきゃやりようがないわな

**デフォルトの名無しさん** · 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/

**デフォルトの名無しさん** · 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相当のライブラリがあるのでは？

**278** · 2014/01/13(月) 11:42:00.72

なるほど、確かに。
自分の得意なスクリプト言語で作ればいいんですよね。

頭が堅すぎたようです。

ありがとうございました。

**デフォルトの名無しさん** · 2014/01/14(火) 08:16:34.22

TAPを出すシェルスクリプトを書いて
proveでテスト実行とかかな

**デフォルトの名無しさん** · 2014/01/26(日) 12:33:01.79

テスト駆動流行りだけど、誰がどこを勝手に直すかわからないOSSみたいな
開発形態では意図せぬデグレートが起きないように抑止する効果はあっても、
きちんと統制が取れた企業内開発じゃさして意味ないよなあ。
最初から通るテストを書いているわけで、結局コードを書いているのと同じ
レベルになって、バグは入り込むわけだし。

**デフォルトの名無しさん** · 2014/01/26(日) 12:34:16.46

テストせやかて工藤

**デフォルトの名無しさん** · 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サイト上のいろいろある解説ではびっくりするくらい完全に無視されている