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

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

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

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

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

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

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

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

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

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

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

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

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

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

RDDのことか

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

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

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

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

○基本

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

○実践

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

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

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

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

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

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

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

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

え、、、、


ダメなの？

おまwww

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

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

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

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

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

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

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

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

なんて

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

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

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

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

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

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

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

でしょ？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ネタがないね

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

Fit: Framework for Integrated Test

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

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

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

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

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

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

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

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

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

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

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

>>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を置き換えればいいんじゃないかな。

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

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

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

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

えっ

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

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

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

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

それでもわけるだろ

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

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

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

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

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

大抵はreaderとhandlerにわける

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

これで充分わかるだろ

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

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

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

>>78
ちがうよ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>94
古いね。

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

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

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

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

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

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

だよなあ

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

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

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

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

reviewで充分だよな

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

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

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

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

これは酷い

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

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

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

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

堪忍して

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

あげ

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

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

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

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

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

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

宗教的で気持ち悪いな

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

うむ

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

滝への回帰としか思えん

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

test

test

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

test

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

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

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

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

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

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

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

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

test

test

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

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

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

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

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

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

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

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

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

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

過疎ってんなあ

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

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

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

添削

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

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

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

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

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

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

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

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

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
というふうに、クラス単位・メソッド単位でテストを自然に記述できる。
（つづく）

（つづき）
しかし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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>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がうらやましい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>194
>見た目だけが大事なのであれば、コメントで区切るとかすればいいんじゃない？
入れ子にして階層的に表示できるから見やすくなる。コメントで区切るのは見やすくならない。

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

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

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

>>195
>テストを複数のクラスに分割することのデメリットをまとめておく。
>
>1. class Fooのテストがどのテストクラスにあるのか一目でわからない
わかるようなコードの書き方は可能。そう書かないのが悪い。

>2. 起動が面倒になる（テストツールもある）
そんなテストツールを使うのが悪い。

>3. （これまで言わなかったが）複数のテストクラスで共通の処理が必要な場合に、
>　　テストクラスが一つであった場合よりもコーディングが面倒になる。
>　　コーディングが面倒になるということは、積極的なテストクラスのリファクタリングの妨げにもなる。
はい？共通の親クラスを作る、委譲を使う等、いくらでも手はあるけど。

>逆に、1クラス1テストクラスの原則を守るとした場合のデメリットは何だろう？
>個人的には、特に見当たらないのだが……。
もともとは、>>182や>>190に書いてあるように、メソッドという単位をどう扱うかの話だよ。
それに、今のxUnit系ツールはsetUpとtearDownがクラスごとにひとつだから、
違うsetUpとtearDownを使いたい場合はテストクラスを分けざるを得ない。
つまり1クラス1テストクラスだとfixtureが1種類に固定される。

>>201
> テストを複数のクラスに分割することの是非とはあんまり関係ないよね。

テストを複数のクラスに分割すると、50個のクラスのテストが200個のテストクラスになったりする。
さて、class Fooに対するテストはどのファイルにあるのか簡単にわかるだろうか。
そして、class Barにメソッドを追加したくなったとき、どのファイルにテストを追加すればいいか、簡単にわかるだろうか。

これはテストコードの書き方が良いとか悪いとかの話では無くて、テストクラスの管理の話だね。
自分はこううまく管理するから問題ない、こううまくテストコードを書くから問題ないという特殊化を
するんじゃなくて、一般的に「1クラス1テストクラス」という原則を採用する/しない場合のメリットと
デメリットを話すので無ければ、あまりこの議論に価値を見いだせない。

> はい？共通の親クラスを作る、委譲を使う等、いくらでも手はあるけど。

プロダクトコードをどう実装するかの話と、DevelopmentをDrivenするTestコードなんだから、
素早く、シンプルに、なおかつ重複コードなどないテストコードを書けるようにしておいた方が良くない？
「1クラス1テストクラス」なら、共通の親クラスを作る必要も、委譲を使う必要も無く、ただ単に
private methodを一つ追加すればいいだけだよね。

> もともとは、>>182や>>190に書いてあるように、メソッドという単位をどう扱うかの話だよ。

そう。そして>>190は俺のコメント。

そうせざるを得ない場合をのぞいて、テストを複数のクラスに分割することのメリットを話してよ。

s/プロダクトコードをどう実装するかの話と/プロダクトコードをどう実装するかの話ではなくて/

例えば、
-----------------
class XmlOutputter
-----------------
+addHook()
+removeHook()
+write()
+setStyleSheet()
+setRootNode()
+addFailedTest()
+addSuccessfulTest()
+addStatistics()

みたいなクラスを実装しようとしているとき、各メソッド用のテストが5個できるとすると、
テストメソッドは合計40個できることになるけど、これってclass XmlOutputterTestに全部入ってれば、
自分も含めて誰もがどこに何のテストがあるかすぐにわかるし、どんなツールでも簡単に
class XmlOutputterのテストを全部実行できる。
分かり易くない？

そもそも>>182の上のコードを不自然と感じる感性がわからんわ

見づらい見づらいって、コード折りたたみ機能があるIDEかエディター使えよ

ケントベックの本だと、
いきなり最初からテストクラスとそこから作ったクラスが違う
あとの方でクラスを抽象化してテストクラスの名前と同じようにしてるけど
結果論なのか始めから見通しを立ててたからか

あんなのTDDじゃないとかいう人もいるけど

ケントベック式TDDならTODO駆動なのだから
TODOの分類とフィクスチャでテストクラスを割り当てていくんだろうなぁ

ケントベック本の例は、今考えると自動受け入れテスト用コードっぽい気がする

>>208
TDDBCなんかだと、Stackクラスを作るからStackTestね、てな感じで誰も疑問を覚えずスルーだよ

　　　　　　　 lヽ ﾉ l　　　　　　　　ｌ l　ｌ ヽ　　 ヽ
　 )'ｰーノ(　 |　|　 | ､　　　　　 / l｜ ｌ　ハヽ　　|ｰ‐''"ｌ
　/　Ｔ　　|　|　|／| ﾊ　　/ / ,/ /|ﾉ /l /　ｌ l ｌ|　ｌ　 Ｔ ヽ
　l 　 ･　　i´ |　ヽ､| |ｒ|| |　//--‐'" 　 ｀'メ､_ｌﾉ| /　 ・　 /
　|　 Ｄ　　l　 トー-トヽ| |ノ　''"´｀　　　ｒｰ-/// |　 Ｄ　｜
　|　 ･　　 |／　　 　 | l ||､　''"""　 j　""''/ | |ヽｌ 　・　｜
　|　 Ｄ 　 |　　 　 　 | l |　ヽ,　 　― 　 ／　| |　ｌ　 Ｄ　 |
　| 　 !!　 |　　 　 /　| | |　　 ` ｰ-‐ ' ´||　,ﾉ| |　|　　!!　｜
ノｰ‐---､,|　 　 /　│ｌ､l　　　　　　 　 |ﾚ' ,ﾉﾉ　ﾉハ､_ノヽ
　/ 　　 　 　 ／　ノ⌒ヾ､　 ヽ　　　 ノハ,　　　 　 |
,/ 　 　　　,イーｆ'´ /´　　＼　| ,／´ ｜ヽl　　　 　 |
　　　　 ／-ト、|　┼―- ､_ヽﾒr'　, -=ｌ''"ハ　　　　|　 ｌ
　　 ,／　 　|　ヽ 　＼　　_,ノｰｆ' ´　　ﾉノ　 ヽ　 　｜　|
､_　　　 _ ‐''ｌ　　`ー‐―''" ⌒'ｰ--‐'´｀ヽ､_ 　　_,ノ　ノ
　 ￣￣　　 |　　　　　　　　　　 ／　 　　　　￣

> もともとは、>>182や>>190に書いてあるように、メソッドという単位をどう扱うかの話だよ。

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

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

だから、テストを対象のメソッドによって分類するとか、それをテストコードでどう表現するか
という普遍的な方針は立てにくい。
はっきりした方針が立てられないのであれば、始めから分けない方が考えなくていい分楽だし、
分けるにしてもあまり分け方に拘らず依存せずゆるくやっていった方がいいと思う。

>>213
このスレ、TDDスレなんだけど

どんな言語・開発環境でも、一つのクラス対一つのテスト用クラスに勝るものはないと思う。
ただ、一つのテスト用クラスに何百ものテストメソッドがあって、実行するのに5秒とかかかるのなら
わけたくなると思うけど、そんなでかいテスト用クラス作ったこと無い。

1クラス-1テストクラスじゃない構成でやってる奴がいるのに驚いた。

これ一番の敵は自分の意識だな
ついつい先にコード書きたくなってモヤモヤしちゃう

全くだ
自制心が試されるよクソっ

JavaのServerSocket#accept()みたいなブロッキングメソッドを使うメソッドって
どうテストすればいいんだろう

「自分は頭が良くて詳しいです」的な自己満足レスの典型だぞ。
相手は超初心者なんだからもう少し優しく教えてあげないと。
さもなくばスルーでOK

eclipse+java でオススメのテストプラグインおしえてくだしゃあ

「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分で実行できる環境を整えるのに、20日かかるとか

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

つまり、現実的には無理

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

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

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

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

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

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

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

Windows で、googletest ライブラリを MinGW gcc 使ってコンパイルしたんだけど、
テストプログラムの実行ファイルのサイズがわりとデカイような気がするんだが。

http://www.atmarkit.co.jp/fdotnet/cpptest/cpptest02/cpptest02_02.html

これは CppUnit でテストしてる例だけど、
同じ例を googletest でテストする実行ファイルを作ると、
googletest を静的にリンクするように作った場合は7MBくらい。
動的リンクするように作った場合でも6MB後半くらい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>237
> だからテストもループで回したくなってしまう。

それが正解。

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

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

各要素がそれぞれ他の要素から独立しており、
個々のテストの成否が他のテストに影響を与えないのなら、
テストの成否に関わらず後続のテストを続けるタイプの
テスト関数（マクロ）を使うべき。
（例えば gtest なら EXPECT_* マクロ）

>>238
ありがとうございます。

各要素は独立していたので、テストを継続するタイプのマクロを使用することに、
ループで繰り返すことにしました。

ちなみに、後続のテストの信頼性が失われるかどうかの判断は、
意外に難しかったりするから注意。

理論上は依存しない仕様のプログラムが、
本当に依存していないかどうかを調べるのも
テストする動機のひとつであることを忘れずに。

TDDなんだから、失敗したらそこで終了で良いのでは？
何で続けたいのかしら。

>>241
独立したテストなら、結果を一覧できた方が作業効率が良い

>>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なんだから。

というか、

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

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

「後続のテスト」というのが、あるテストメソッド内の複数のassertionのことなら前述した通り。

質問者が回答者にレスするスレはここですか？

質問者が回答者にレスしても何も問題ないと思うが、それはともかく、>>243,244は俺なんだが質問者ではない。

なんだか良くわからん質問>>237に対して、さらに良くわからん>>238という回答がついてたのでコメントした。

>>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 などの独立したテストの結果は一望できた方が良いと私は思う。

>>247
アホなの？
aのテストがパスするまで実装とテストを繰り返してからbの実装をするか、stubやmock使えよ。

それもそうか

これから本買って読もうと思いますが、TDDにxUnit的ツールは必須なんでしょうか
コンソールに結果出力するだけでもいいのでしょうか

あった方が断然楽しい

あった方がいいのは分かりますが、必須ではなさそうですね
HEW+ルネサスコンパイラで、ツール買う予算も取れないので、assertとprintfで凌ぎます

組込みやってるやつは可哀想だ
しかもルネとはw

>>252はアホ

コンソールがあって、さらにはprintfとassertが使えるなら、xUnitも使えるだろうが

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

CUnit入れてコンパイルまでは通したけど、全部FAILEDになるぜドチクショウ
スレ汚し失礼しました

>>247
stubあんのにそんな長文、恥ずかしくないの？

TDD始めてみたんだが、暗号化するメソッドと複合化するメソッドがあって、あるデータを暗号化して複合したらもとのデータ戻るってテストはどうやって書くのがいいの？

既知の平文と暗号文の対を用意して
「平文→暗号化メソッド→暗号文」 というテストと
「暗号文→復号メソッド→平文」 というテストをすればいいと思うよ

>>260
既知の暗号文無いから暗号文を求めようとしても、手で計算するのがものすごく大変。
計算機で計算しようとしても、その数式がコードそのものだから本末転倒なんだよね。

知らんがな(´・ω・｀)
いかに大変でも期待通りの暗号化処理が正しくなされてるか確認するためには最低1回は答え合わせをせざるを得なかろうよ

>>261はTDD以前に自分が何をテストしなければならないのかすら
分かってない気がする

>>263
もしかしてこういうのってテストしなくてもいいの？

TDDのテストは開発者が設計実装を駆動するためのホワイトボックステストで、
開発者がテストとコードを両方見て主観的にコードが正しいことに確信を持てる程度のものにする。

暗号化とか神経質にならざるを得ないかもしれないが
その品質用テストを用意するのはTDDの範疇外というだけで
要らないものではないと思われ

仕様書に入出力（平文と暗号文）のサンプルくらい記載されているもんじゃないのか
それコピペすれば最低限のテストはできる思うけど

入出力が分からないんじゃTDD以前の問題だわ

>>265
そうなのだろうが、暗号化するコードなのに肝心の「暗号化できているか」をまったく調べることができないと、コードの正しさに確信が持てないんだよなあ。
というかTDDのテストってブラックボックスじゃないの？

>>266
やっぱり出力を先に手計算しといたほうがいいのかな？
add(1,1) == 2 になることを調べるテストだって、右辺の2は前もって人間が計算してるわけだし。

ただ今回の場合は簡単な解が無くて、暗号化計算してわけのわからん値になったもの同士を比較するテストをして通っても、そのメソッドが正しいという確信が得られるような気がしないんだよなあ。
そんなテストよりは、暗号文の特性、複合すると元に戻ることとかを調べたほうが直感的な気がしたんだが…なんかもやもやする。

>>268
たとえば解の候補が３パターンあるとして
�@顧客の解（要望）…AESで作ってほしい
�A設計者の解（仕様書）…Twofishを採用しよう
�B>>268の解(実装)…分けわからんが0xABCDでビットマスクで実装すればいいんだよな？

で、>>268がやろうとしているのは「�B」をパスするテストコードを書くってことだ
それをパスすることに意味はあるのか？　「�@＝�A＝�B」なら問題ないが

>>269
どういうこと？
すまん、さっき「解」っていったのは、メソッドの返す値って意味で。
複合すると元に戻るっていうのを調べるテストは、それをパスする他のアルゴリズムがあるから、仕様をテストが表現できていないって感じの意味か？確かに、そう考えるとやばそう…。

だが手計算で計算するのが大変で、プログラムのテストというより、自分の計算のテストになりそうなんだけど。結構時間もかかるだろうし。

そもそも単体テストってassert(expression)だから、expressionを自分で定義できなきゃやりようがないわな

マジでどうしたらいいかわからん助けて

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)が一致しなければ自作例外を投げる仕様。

お前らならどうテストすんの？

レスに書いてあることそのままテストすりゃいいんじゃないの

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);
}

http://the-little-book-of-busterjs.readthedocs.org/en/latest/doc/column/TravisCI/

TDD Advent Calendar 2013
http://qiita.com/advent-calendar/2013/tddadventjp

メソッドの名前をリファクタリングで変更するだけで
テスト毎ぶっこわれる動的言語ではTDDは辛すぎる

CUI のアプリを作っているのですが、ユーザーからの入力や、
それに対する出力などをテストしたいです。

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

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


[環境]
Linux

>>278
シェルスクリプト書けばいいだけでは？

追加。入力周りは昔はexpectというtclの拡張コマンドがよく使われてたけど、今はtclなんて流行らないよね…。
たぶん、perlとか、他のスクリプト言語にもexpect相当のライブラリがあるのでは？

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

頭が堅すぎたようです。

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

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

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

テストせやかて工藤

>>283
根本的にOSSというのを勘違いしているから
その後に発言が無意味になってる。

> 最初から通るテストを書いているわけで、結局コードを書いているのと同じ
> レベルになって、バグは入り込むわけだし。

それはテストコードと言えないだろうね
テストが通れば確実にバグってない事が保証出来るコードでないと意味ないよね
ようするに単純なテストを積み重ねていく感じか

仕様に明記されていないことはやらない（コードに落とさない）
仕様に明記されている内容はまずテストコードに落とし、次にコードを書き、テストを通す

コードをテストに合わせるからバグが減る
テストをコードに合わせてはいけない

TDDで後から実行可能なテストも手に入るのはオマケやで
出来てしまったテストを捨てることもないだろうが
あくまで開発を前に進ませる手段や

> 仕様に明記されていないことはやらない（コードに落とさない）
> 仕様に明記されている内容はまずテストコードに落とし、次にコードを書き、テストを通す

仕様等の出発点からどのように粒度を落としていくか（設計していくか）の方向性として
テストするという観点を掲げているのがケントベックが本で語ったTDDなのだが
この開発の最初に必要とされるであろうステップが
日本語のWebサイト上のいろいろある解説ではびっくりするくらい完全に無視されている

何見て解説してるのかわからんな

>>290
TDDのそもそもの意味/意図である「テスト駆動」の「駆動」を忘れてるのか知らないのか無視してる奴が多いね。
なんとなくのイメージで「xUnitを使って自動テストをしながらコードを書く」くらいの理解の奴が多い感じ。

Test First と Test Driven はどう違う？

>>293
ざっくり言えば、TDD = Design First + Test First + Refactoring

>「駆動」を忘れてるのか知らないのか無視してる奴が多い

スレタイのせいかもな

BDDと形式手法の違いって？

>>296
形式手法って何？

テストを書くときの気持ちのこと

ぐぐればすぐ出てくるものを即座に質問する
これを脊髄駆動レスと呼びます

>>299
>>296のことなのか、>>297のことなのか

ぐぐれ

こんなスレあったのか
しかもだいぶ前からあるとは

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

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

なぜ流行らなかったとか別スレあるという事は、皆あんまテストしないのか？
しても後から曖昧にとか？

>>302
TDDはテストじゃねーよ。

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

やっぱりお前はわかっていない。

> 作ったテストもどきはテストとしては使わない。
> 使い捨てのコード。

は？

>>303
じゃぁお前は、また、お前の会社はどうやってテストだけでなく、開発をしてるんだ？
開発のプロセスを聞いてみたい

>>304,305
俺は303じゃないけど
たぶんお前らはTDDを理解してない
もしくは一部を見て言ってる

ああ、こりゃ「じゃあTDDって何だよ」って問うてもまともに答えられない展開ですわ

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

TDDの良い所は、コーディングがキチっとなることだと思う
テストがどうとかじゃなく、ブレがないというか

DBがどうとか言うけど、スタブ、モックオブジェクト、なんやらあるだろ

俺こそがTDDの神祖
おまいらは邪教徒じゃ

BDDって使ったことないけど、どう違うの？
TestMethod()とかがUnittestだけど、
BDDの場合はshouldBeEmpty()とかになるんだろ?

>>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

>>304,305
>>303の文章は酷いが、Wikipediaを読めば理解できると思う。

> テスト駆動開発で用いられるテストは、品質のためのテストではない。コード本体とは独立に
> あらゆるケースを網羅するような、テスト自体で価値を持つようなものは目指していない。
> コード本体を合わせて検討することで、開発者が、その正しさに確信を得るものである。
> 開発者の確信に少しも寄与しないテスト（かつ、ドキュメントとしてテストの読者に何かを
> 伝えるために書かれたものではないもの）は、むしろ積極的に削除を検討する。

俺は、TDDで作ったテストメソッドの大部分は、「品質のためのテスト」でも使えるよう修正してくよ。

>>313
そういうことだよな。

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

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

「仮テスト→コーディング→本テスト」 VS 「コーディング→本テスト」

これよかったよ。
http://japan.renesas.com/company_info/lsi_design/

テストをTDDで開発してるのか

t_wadaさんによるスライド
「TDD のこころ @ OSH2014」
http://www.slideshare.net/t_wada/osh2014-sprit-of-tdd

『テスト駆動開発入門』も
『リファクタリング』も
『達人プログラマー』も
絶版になってたなんて……。

>>318
「達人プログラマー」ってなんか東亜プランの中の人かとｵﾓﾀ

TDDの最大のメリットはテストしやすいソースになる事

昔社内の文書でテスト騒動って書いている奴がいて笑った
そりゃ、テストで騒動が起きるのは困るよね

テストで騒動とかプロジェクト毎に起きてるぜ

>>321を素で駆動と読んでｲﾐﾌだったが>>322で読み直してすっきりさっぱりだよ。

まぁ、バグが発生するのはテスト中だからな

完成してなくてもいいから、コンパイルの通らないコードをリポジトリに登録するな、
でないと全体のコンパイルに支障が出る、というのと似たような感じで、
テストを通していないモジュールを登録するな、暫定的でもそれなりに動作するようなモジュールができていないと、
他のモジュールの開発に支障が出るから、ってことかね。

>>325
> テストを通していないモジュールを登録するな、暫定的でもそれなりに動作するようなモジュールができていないと、
これは別にTDDに限った話じゃないだろ

テストを“いちばん重要な財産”と考えると見えるもの
http://gihyo.jp/dev/serial/01/tdd_supremacy
タイトルと概要しか見てないけど、短かい文章でテストの重要性を言い表わしてるなと思ったんでコピっとく

>>327
コードのインデントやレイアウトがキモ過ぎるし、newしたオブジェクトを=&で代入したり、
もう全く信用できないので、本文も読む価値無いね。

>>328
いい加減、ちゃんと問題点を指摘できるようになろうぜｗ

>>329
・コードのインデントがキモイ => 最近のコーディング標準知らないんじゃないの
・レイアウトがキモイ => 最近のコーディング標準知らないんじゃないの？静的解析したことないんじゃないの？
・newしたオブジェクトを=&で代入したり => お前いつの時代のPHPerだよ

>>330
いや、そんなことどうでもいいからｗ
インデントの幅がどうとか言ってるだけじゃん。

>>331
PHPのことあまり知らないんだろうけど、最近はPSR-1/PSR-2/Zend/PEARのコーディング規約に
沿って書くのが普通。
まぁそれを知らないド素人でも、人のコードを見慣れてればあんな酷いコードは書かないだろう。

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

第2回もちょろっと見たけど、あり得ない酷いコードだわ。

>>332
本文読んでないからわかってないんだろう？

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

これは「これまでの記事で取り上げたコード」だ
昔のコードだって書いてあるだろ。

>>333
へー、第1回と第2回に載ってるコード全てが昔のコードだって言うの？
いくらなんでも古すぎだわ。

PHP のことあまり知らないから他の言語の利用者にもわかるように
説明してくれると嬉しいところなんだけどな
コードレイアウトは技評の Web 記事編集が手を入れないのが悪い

ここにたれ込めばいいと思うよ
http://gihyo.jp/dev/serial/01/php-programming-examination-room

> プログラミングにおいていちばん重要な財産はテストであり，
> 万一コードをすべて失ってしまったとしても，
> テストが無事なら元と同じ品質のコードをもう一度書くことができる。
> −この考えを立証すべく，テストとコードの関係を考えます。

この時点で、オレオレテスト駆動
別の名前付ければいいのに

>>337
> プログラミングにおいていちばん重要な財産はテストであり，
これは嘘ｗ
あたりまえだけどテストよりも動くコードの方が重要。

テストコードはあっても今すぐには価値を生み出さない。
今すぐアプリとしては動かないのだから。価値を生み出すのはアプリのコードの方。
テストコードはなくても動くが、アプリのコードはなかったら動かない。

アプリコードからテストコードを生み出すことはできるが、
テストコードがあってもアプリコードは生み出せない。
仮にテストコードからアプリコードを作り出すことが可能だとして
それにかかる時間はどれくらいかかるか。その間テストコードに価値はない。

そしてテストコードからアプリコードを書くのは不可能
なぜなら全てのコードをテストしているわけじゃないから
その主な例がユーザーインターフェースデザイン、
分かりやすく言えばHTMLで作られた入力画面等。
テストコードがあっても使いやすい（同じ品質の）入力画面は復活不可能。

また現実的な問題としてテストコードが全て書かれているという証明はできない。
アプリコードがあるなら当然そこにすべての動作が記述されているが
テストコードは全てあるとは限らない。

あたりまえだけどアプリのコードのほうが重要。

>>338
アプリコードの方が重要って考えは視点が違うだけだからなんとも

そもそもTDDスレとしての突っ込みどころはオレオレテスト駆動であって
そんなアプリコードとテストコードどっちが重要かってところに
そこまでの長文を書いてまで反応する意味が分からない

>>339
反応する意味がわからない？
ただ書いただけだろ？
何か問題が？

それを言ったら、お前がレスする意味がわからない ← どう答える？

プロレスで相手の手の内を出させないままキックだけで勝って俺TUEEEみたいな

おまえら勘違いすんな
> テストが無事なら元と同じ品質のコードをもう一度書くことができる。
同じ*品質*のコードといってるんだ
テストが保証するのはコードの品質であってアプリの価値ではない
ましてや同じ入力画面を復活させる事では全くない

ゴミページを擁護してる奴は何が目的なんだ

TDDどうこうよりも、テスト対象のクラスを継承したテストクラスを作って、テスト結果の確認をテスト対象クラスのメンバに設定された値でアサートするというやり方がセンスないわ。

アプリのソースだけ残った場合と
テストコードだけが残った場合

どっちが安価に元の状況に戻せるの？

>>345
リファクタリングしまくる人の場合は、残ったソースをいずれ破棄したり書き直したりしてしまうので、
テストコードだけ残った方が安価なときもある。

TDDはそういう人向けの手法でしょ。

TDDはアプリのソースとかテストコードがどっちが残ると〜とかそういうことを
語るもんではないんだが

おおよそ、テストをどうやって書くかを考えるのが設計になり、
テストをどのように満たすかを考えるのが実装になる。

テストとコードを共に成長させていって開発を進めるのだから、
片方だけ残して、これがテスト駆動開発だ！とか言われると
ゲフンゲフンとなる。

品質との関連性は微妙

＞テストとコードを共に成長させていって開発を進めるのだから、
成長が順調に進むのであればテストファーストもコードファーストも大差なく
テストとコードのどちらを先に書くかの順番の違いしかないが、

成長が逆戻りした（コードに修正を加える必要が出てきた）ときに
テストを優先して（テストの中に設計を含めて）コードを大胆に修正できるようにするか、
コードを優先して（コードの中の設計を維持するように）コードの修正量をなるべく少なくするか、

という所に違いがある、という感じか。

＞品質との関連性は微妙
実装フェーズが完了した段階ではコードもテストも固まっているから
テストファーストでもコードファーストでも同等の成果物が作成されて
同等の品質が得られているはず、ということなんだろうか、

それとも、実装フェーズではそれなりに動くモノができていればいい、
品質はその後の試験フェーズで高めていく、という考え方なんだろうか。

>>348
> テストとコードを共に成長させていって開発を進めるのだから、
> 片方だけ残して、これがテスト駆動開発だ！とか言われると
> ゲフンゲフンとなる。

誰も本当に片方捨てろなんて言ってない

> テストが無事なら元と同じ品質のコードをもう一度書くことができる。−この考えを立証すべく

って考え方を言ってるんだよ
お前は抽象的な話しが出来ない奴か？

>>351
> > テストが無事なら元と同じ品質のコードをもう一度書くことができる。−この考えを立証すべく
>
> って考え方を言ってるんだよ
> お前は抽象的な話しが出来ない奴か？

これのどこが抽象的な話なんだ？

「テストが無事でも元と同じ品質のコードをもう一度書くことができないときがある」
で、論破。

後付けのC1カバレッジ100%で全ての副作用に対するassertionが記述されている
テスト一式があれば、元コードと同等のものを翔かもしれないが、このこととTDDは
一切関係無いね。

>>352
> 「テストが無事でも元と同じ品質のコードをもう一度書くことができないときがある」
> で、論破。

論破って…単なる仮説を立てただけだろ。立証してから言ってくれ
そういう分かりやすい最終的な結論だけで話しを進めるたがる事を
抽象的な話しが出来ないっていうんだよ

>>354
> 論破って…単なる仮説を立てただけだろ。立証してから言ってくれ

は？どうみても
「テストが無事でも元と同じ品質のコードをもう一度書くことができないときがある」
は明らかだろ。

> 抽象的な話しが出来ないっていうんだよ

抽象的を辞書で引け、アホ。

>>351
なんであの糞記事を擁護するの？

>>355
> 「テストが無事でも元と同じ品質のコードをもう一度書くことができないときがある」
> は明らかだろ。

明らか言われても論破された気にはなれないよ

ちなみに「できないときがある」の反対は「常にできる」だから該当記事の「〜ことができる」を
反論している事にはならないよ
むしろ同じ事を言っている

> 抽象的を辞書で引け、アホ。

辞書で引いてみたよ
１ いくつかの事物に共通なものを抜き出して、それを一般化して考えるさま。「本質を―にとらえる」
で、だから何？

>>357
言葉遊びして楽しい？
それより、なんであの糞記事を擁護するのか教えてよ。

>>367
ごく限られた条件下(*)においては、テストが無事なら同じ品質のコードを書くことができる
こともあるだろうが、それはテストの大切さとは直接関係ないし、ましてやTDDとは何の
関係もない。

(*)後付けのC1カバレッジ100%で全ての副作用に対するassertionが記述されているテスト
一式がある場合。

TDDスレなんだから、このスレの住人は、TDDにおけるテストの大切さはみんな重要だと
思っているだろうし、その他のテストの重要性もわかってるだろう。

その上で、>>327は駄目記事だと言ってるんだが。

>>357
そもそも
＞テストが無事なら元と同じ品質のコードをもう一度書くことができる。
なんてことが必要になる状況はめったにない、で論破じゃないかと。

>>359
TDDにおけるテストの重要性は、「同じ品質」ではなく「同じ動作」を求めるため、
しかもカバレッジ100%の完成したコードではなく実装途中のコードに対して、
でよいよね？

>>360
> TDDにおけるテストの重要性は、「同じ品質」ではなく「同じ動作」を求めるため、
> しかもカバレッジ100%の完成したコードではなく実装途中のコードに対して、
> でよいよね？

そんなかんじ。
カバレッジに関しては、C0カバレッジですら100%に満たないよね。
TDDのテストは、その人が十分だと思う分しか書かれない。
そして、そのテストコードをいわゆる「単体テスト」では使わないという人もいる（extremeな人は全捨てするらしい。マジか）。
俺は使うけど。

>>353
そうだな。誰もそこまでのテストは求めていないし、そんなことする気にもなれない。

テストとソースって
たまごとにわとりの関係なの？

たまごが成長すれば、ニワトリになり
そのニワトリが複数個のたまごを生む。
そのたまごがそれぞれ成長し
それぞれがたまごを複数個生む。


テストとソースはこういう関係です。

カバレッジは、ISOとかで必要なところもあるんだろう
あれも結局は認証されたxUnitでテストするらしいが

カバレッジのスレないのでここで。

テストするまでもないコードというのがある。
たとえば変数の初期化関数とか。
こういうのをテストしたってしょうがない。
だけど実行しないとカバレッジは上がらない。

カバレッジ100%を目指しているわけじゃないが
それはカバレッジを上げるために時間がかかりすぎるなら
コストとメリットを天秤にかけてやらなくていいという話なはず。
だから関数呼び出しだけで簡単にカバレッジがあがるならやってもいいではないか？

テストを行わないが関数実行だけはする。これに意味が無いかといえば
そうではなく。それはコードが確実に動くということを証明できる。
スクリプト言語系はスペルミスなど実行しなければエラーを検出できないことがある。

つまりだ。テストを行わないで関数を実行するだけ。というのは気持ち悪いがありなのだろうか？
テストはしていないが、あえて言うなら関数が動くことをテストしているということ。

それは、なしです

実は関数読んでなかったり別の関数呼んでたらどうするわけ？

>367
理由は何ですか？

処理を実行してコンパイルエラーを
実際に見つけられているのです。

>>366はガバレッジとテストの関係について何か壮大に勘違いしてると思う

なにがしかでも作業効率が改善できてるならいいんじゃないの

カバレッジ○○％達成できました！とか言って持ってきたら殴るけど

>>370 >>371
話ちゃんと聞いてね。

テストもカバレッジも目的じゃない。

実行することでコードが確実に動くことが保証される。
たとえば古いバージョンや新しいバージョンで動かないコードを検出できる。

だから実行だけさせることにも、意味はあるよね。

話を聞いてないように見えるのはお前が基本を理解してないか
もしくは説明が下手だからだ

あぁ、わかった。

例外が発生するテストの反対。
つまり例外が起きないテストと考えればいいわけだ。
ということはコードの最後に必ず成功するテストを入れた方がよさそうだ。

>>366
テストは、実際どのように使うのかというドキュメント性があり、また、テストを書くことによって設計が洗練されるということもあるので、ただ実行するだけのメソッドも意味は無くないと思うよ。

書いたら保守せなあかん
簡単に書けるからと書くと、負の遺産になりかねないかも

変数の初期化関数とかは必要だからやってるのであって
それがないと困る箇所が本当は別にあるのではないだろうか
と妄想

てｓ

２つ質問です。
テストを作ってから同じテストを別のオブジェクトにするとき
別のテストをつくりますか？
リファクタリングをするときソースを書き換えてもとに戻せなくならないように
リファクタリングをする前のファイルを保存しておきますか？

>>378
たいていのテスト環境にテストコードの再利用の仕組みはあると思うけど。

バージョン管理しろよ。

DHH(Ruby on Railsの作者)の"TDD is dead. Long live testing." （の訳）
http://d.hatena.ne.jp/yach/20140424#p1

彼らは自分のエゴを満たすためにコードを書いてるんだから、
金色の牛を殺したりしたらダメだよね?(´・ω・｀)

>>380
一行目から引いた

Unit Test Frameworks
よんだけど、CPPUNITのことが全然書いてないので
CPPUNITの高度な使い方ってどうやってわかりますか？

>>383
> Unit Test Frameworks
これ何

UnitTestFrameworks.pdf?

つか、CppUnitの高度な使い方って何よ？

>>385
> UnitTestFrameworks.pdf?
何それ？何かの海賊版か？

抽象クラスのテストを作って派生クラスのテストでテストしたいクラスを初期化する方法とか。

UnitTestFrameworks.pdf
で検索すると出てくる著作権フリーの書籍。

>>388
ちゃんとわかる文章書け。
つか、ほんとにそれ「CppUnitの高度な使い方」に関する疑問なのか？

>>389
> UnitTestFrameworks.pdf
> で検索すると出てくる著作権フリーの書籍。
なんでずばっとURL書かないの？
俺が検索したら、O'REILLYの奴しか見つからなかったが。
これ、フリーじゃないだろ。

>>391
Ｏ'ＲＥＩＬＬＹはフリー

>>392
まさか、DRMフリーの意味がわからんのか？

PDF の各ページのフッタ見ればわかるけどフリーで配布されてるわけじゃないね

なんかの記事で見たけど、無断配布を禁止するより
しない方が本が売れるからわざとそうしてるらしい。

>>395
> なんかの記事で見たけど、無断配布を禁止するより
> しない方が本が売れるからわざとそうしてるらしい。
どこの記事だよ？
O'reillyはDRMはフリーにしたけど、無断配布は禁止だろ。

なんだ釣りか

別にDRMフリーって無料配布を禁止してないわけじゃないんだけどなw

A. オライリー・ジャパンが販売する書籍（Ebookも書籍だと考えています）は、
コピー・フリーではありますがコピーライト・フリーではありません。
日本国の著作権法による保護を受けており、
著作権法で定められた範囲を超えた複製、頒布、
送信などは、
著作権法に抵触する恐れがありますのでご注意ください。

著作権フリーだの無断配布だの意味不明な俺用語でかたるのがおかしい

> なんか誤解してるっぽく見えるからそれをときたいだけなのに原理主義だの教条主義だの
> テスト厨だのって言われるのは心外っすね。。こちらだって別に銀の弾丸だと思ってないし、
> ただ誤った理解を訂正したいだけなのに。。

正しい理解が為されればTDDがdisられないという考えがすでに宗教。
だから原理主義言われるんだよ。

そうだな
TDDという概念自体が完全に誤ったもの
動いてるコードに手を触れないことこそが真理

>>402
君、概念以前にTDDが何なのかすらよく分かってないでしょ

うんこ

オウンコ

マンコ

テスト鳥文

とりぶん？

なぜ流行らなかったスレが死滅したな

あのスレのカオスっぷりを見れば
なぜ流行らなかったのか良く分かる

2ちゃんねらーの脳みそではテストなんて書けるわけがなかったってことだ

TDDはともかくユニットテストまで否定かよ
恐れ入る

TDDやユニットテストを否定する奴って、経験ゼロなのに経験豊富な奴の知見や実感なんかを否定するよね。
あと、自分の嫌いなスクリプト言語をわざわざdisりに行く奴とメンタルが似てる気がする。

自己紹介ですね
わかります

>>413
>>380

>>415
http://blog.fieldnotes.jp/entry/2014/05/07/225129

> DHH氏のTDD is dead. Long live testing. (DHH)のエントリは、国内でもさまざまな議論を
> 呼び起こしました。ですが、そのセンセーショナルな見出しの影響もあり、「(TDDと同一視
> した上での)ユニットテストは不要」などの、ミスリードされた論調も見られます。

あとこれも追加。

【翻訳】TDD is Fun
http://diskogs.hatenablog.com/entry/2014/04/25/085112

>>416
そのリンクを出して何を言いたいのか分からない
もう一回>>413と>>380を嫁

>>418
えっとね、>>380も>>413も書いたの俺なんだわ。
逆にお前が何を言いたいのかわからんわ。

>>419

>>413
> TDDやユニットテストを否定する奴って、経験ゼロなのに経験豊富な奴の知見や実感なんかを否定するよね。

>>380
> http://d.hatena.ne.jp/yach/20140424#p1
> TDDには感謝しているが、設計の教義としてはとっくに使わなくなっている。

とっくに使わなくなっている＝現場で使えない＝否定　だよね

>>420
アスペなの？
俺が言ったのは傾向だよ。

TDDは慣習

組み込みなんだが

実機とＴＤＤの解析環境でコンパイラが別になる

こういう場合は何をもってテストしたといえるんだ？

気になるのはコンパイラが別になるってことだけ？
それなら解析環境（？）でテストがパスすればテストしたと言えるだろう

コンパイラの差異については結合テストとシステムテストをパスすれば
問題ないと考えていいんじゃないの

最適化のバグでひどい目に遭ってからそのへんの互換性は信用出来ないと思い知ったわけだが
それでもテストしないよりはマシ

>>424
他にも色々ある

というか俺の職場の装置のソースがクソなんだろうけど
パラメータが多すぎて全部網羅するのは無理

ＴＤＤでいうテストってのはどういうイメージなのか
ネットや本を見てもピンとこない

ｘ＋１の関数に１をいれて２になりましたとか
そんな説明は求めてないのだが

>>426
TDDがどんなものか、何の略かまでは分かる？
クソなソースになっているのならどうしようもないだろう

それにパラメータ多すぎて全部網羅するのは無理っていうけどさ
TDD以前にカバレッジはどうすんのよ

組み込みでC0すらパスしないような状況になってたらかなりマズイ気がするが

>>426
TDDで目指すのは小さなフィードバックループを作ること
開発者が安心を得つつコーディングできること
安心というのは、ここでいうと例えば「実機で確認されていないコード・機能をベースに、それに依存したコードをさらに積み上げていくこと＝不安な状態」的な

何をもってTDDでいうテストとなるか、って定義は割とどうでもいい気がする
>>423の環境で何をどうすれば開発者が安心できるか、作業のループを小さくしてフィードバックを得られるか、が大事
「これが動けばこのコードは正しい」っていう一般的なテストがあって
それが自動化できてさらにフレームワークで成否確認までできるなら十分
そうでないなら何か妥協したテストでやるしかない

・実機と検証(解析？)環境がどの程度異なっていて、開発者は検証環境をどの程度信頼できるのか
・どの程度の頻度で実機テストができるのか
とかが重要なのでは？
ここらへんは現場を見てないので多分他人には分からない所。

仮に検証環境があまり信頼できないのであれば、そこだけでどれだけ完璧な開発プロセスをこなしてもムダになる危険性が残るだろうから
実機での確認をいかに頻繁に行ってフィードバックを得られるか、が重要になる
そうすると一般的なTDDは実践しづらくなると思う。
けど実機でのテストを自動化できるのであれば多少は導入できるかも？

組み込みとか知らんのでとんちんかんなこと言ってたらすまん

>>428
ありがとう

指摘はとても現実を捉えていて救われた思いがした

現実は顧客の装置の一部のデバイスを作ってるのだけど
検証環境が貧弱（または無い）ので
仕様変更箇所のみを検査するみたいな対応になってしまってる
ここ数年リストラで人減りまくったのと
士気の低下なのかテスト不足と思われる市場不良が多発


「安心」と言う意味では
徹底的な回帰テストをすることが大事だとおもう

問題はどうやってそれをやるかなのだけど

>>428
> 実機での確認をいかに頻繁に行ってフィードバックを得られるか、が重要になる
> そうすると一般的なTDDは実践しづらくなると思う。
組み込みの種類にもよるだろうけど、対象物をmock（あるいは、シミュレータ）で作って
実機なしに開発・テストできるようにするのが、自動テストをやる派の中では一般的だと思う。

まあ、中には「現地に行かないと、プログラムの起動すらできないのでテストできません」とか
言う奴もいるんだが。

UARTなりＣＡＮなりイーサネットなり
この部分は完璧に通信できるものとして実装するでおｋ？

エラーのシミュレーションはするべき

異常系の仕様が定義されていればそれに対応する
それ以外は単体テストの範囲ですらない

>>433
定義あるいは明示されていない異常が発生して鼻から悪魔が出ても、それは俺のせいじゃないから
問題ないという主義ですか？

まるで公務員の主張だな

一緒に仕事したくねーな

縦割りはそういうもの

担当者が設計と開発で分かれているなら>>433が正しい

開発の見積もりは「この仕様（設計書）通りに作ったら○○人月」で算出してるわけで
「異常系に漏れがないかチェックしろ、漏れてたら仕様に書いてなくても対応しろ」は
見積もり範囲外の作業だよ

予算が潤沢に貰えるなら「サービス」で対応するかもしれないが
そんなに潤ってるプロジェクトは滅多にないだろう

>>438
設計する人は、たとえばファイルに保存するときに起こり得るエラー原因ごとにどう対処すべきかを
網羅したりするんですか？

printf() の戻り値見ろと言っているに等しい

>>439
必要なら処理中の突然の電源断やディスクやメモリの破損なんかも網羅するよ
必要か（現実味があるか）どうかを切り分けるのが仕事だよ

>>441
ちょっと議論するのめんどくさいんだけど、開発者の裁量内で判断する異常処理ってないのという疑問なんだけど。
そういう判断を一切する必要がない開発者は、エンジニアやプログラマとは呼ばずに、コーダーやパンチャーって呼ばれると思うんだけど。

>>442
たとえ一人でやっている場合でも、アーキテクチャ（何が起きるか）と、
インプリメンテーション（どう起こすか）は明確に分けるべき。
ましてや複数人でやるんなら、アーキテクチャが明示されることが必要。

少なくともユーザに仕様として提示されるものは、全てアーキテクチャなんで、
必要なファイルが無かったり、外部装置や EAI の接続先が故障していた場合
に"何が起きるか" は、アーキテクチャとして定義されなければならない。

どちらが、より創造的かということには意味はなくて、単に別の仕事。

TDD (BDD) には、インプリメンテーションをやるまえに
テストケースを作ってアーキテクチャを確認しようぜ
という意味も有る。

そりゃプログラマだってアホじゃないんだから要件漏れ気づくこともあるよ
テストを作成していて漏れに気づくことだって多いしね

ただしそれを見つけたり直したりするのはプログラマの役目ではないし責任もない
優秀なプログラマなら「○○処理が漏れてますよ」と指摘だけして
どうしますか？対応するなら再見積もりしますね？で予算をふんだくる

なるほど

>>445
あんた公務員か

たぶんプログラマって言葉の定義が違うんじゃね
SE/PG世界のプログラマは普通のプログラマと別の概念

>>439
Javaの例外は3種類あって、
プログラマが主に想定する例外は、Exception

Error
メモリ不足やハードウェアの故障など、
プログラムではどうにもならないもので、catchする必要がない

Exception
ファイルが読み書きできない、ネットワークがつながらないなど、
プログラムで想定できるもので、catchすべき

RuntimeException
NullPointerのチェックなど、
一々想定していると切りがないもので、catchしなくてもよい

アーキテクチャをそんな意味で使うの初めて見た

>>440
> printf() の戻り値見ろと言っているに等しい

例外がない言語はそうなるから大変なんだよね。

例外がある言語ならすべての行でエラーが起きる可能性がある
という前提でプログラムしても全然負担にならないのに。

>>443
> たとえ一人でやっている場合でも、アーキテクチャ（何が起きるか）と、
> インプリメンテーション（どう起こすか）は明確に分けるべき。
> ましてや複数人でやるんなら、アーキテクチャが明示されることが必要。
ちょっと俺とは「アーキテクチャ」の使い方が違うようだ。

> 少なくともユーザに仕様として提示されるものは、全てアーキテクチャなんで、
ユーザに仕様として提示すべきものは「外部仕様」。
そして、その中には内部で使用するアーキテクチャは明示されるかもしれないし、明示されないかもしれない。

> 必要なファイルが無かったり、外部装置や EAI の接続先が故障していた場合
> に"何が起きるか" は、アーキテクチャとして定義されなければならない。
内部設計では、何が起きえて何をすべきかを網羅することは必要だが、外部仕様としてはそれらをすべて
含む必要はない。

コードを書かない？設計者が、最終的に使用するミドルウェア・ライブラリ・APIに精通してる奴多すぎ。
んで、if (エラー条件)となる部分を全部設計書に明記するだって？
どんだけ分厚い設計書なんだよ。

>>451
> 例外がある言語ならすべての行でエラーが起きる可能性がある
例外がありゃあったで、別に考えないといけないことも増えるんだけどね。

>>453
冗談と思うかもしれないが、開発を海外に投げるときは
それくらいしないと酷いことになる

>>455
オフショアの話なんて誰もしてないと思うが

>>455-456
わかるわ
日本人同士で日本語で会話しててもこうだもんな

>>457
何を言いたいのかさっぱりわからん
確かに日本人同士でも話が通じることはまれかもな

>>444

既に存在するスパゲティなＣのプログラムがあるんだけど

これをテストしようとおもうんだが
どうしたらいいとおもう？

ちなみに全てのｃファイルが
そのほかのｃファイルのヘッダを全部インクルードしてて
隠蔽もクソもない。外部参照の鬼状態で
スタブを作るだけで気が遠くなりそうな状態

テストの使い方を間違ってる

レガシーコード改善ガイド

>>459
> そのほかのｃファイルのヘッダを全部インクルードしてて
まずここから改善していけば？

よくよく見てみたら相互参照や循環が２〜３箇所で
それを除いて解きほぐしたら案外単純…ってことが多いんじゃないかな

実装済みならE2Eテスト書けば

スパゲティ

パスタ

テスト駆動ってC0カバレッジの確認しづらくない

最後に確認して足りなきゃ足したら良いんじゃないの？

お前はなんにもわかってない

まさかC0を通すためにテストを書き直すとかやってるんじゃないだろうな・・・

>>470

TDDは開発手法だよ。
TDDと品質テストは、別物として考えるべき。これって、教科書の2,3ページくらい目に書かれている。

ただ、TDDのテストも品質テストに流用は可能だ。なので >468は良くわかっている人間だ。

>>471
なんで俺にレス付けたのか知らんがそんなの知っとるがな

>>462
職場の製品プログラムなんで
末端の俺ごときがインクルードをいじると鬼のように罵倒される


なのにカバレッジテストの業務ルールを作れといわれたんだが
正直テストケースを書くだけで眩暈がする
境界値テストとかもはや不可能

罵倒されるような人間にルール作りを任せる？　ありえんわ
出来ても誰も守らねーだろう
適当に作っとけよ

一応フォローしておくと>>473が悪いわけじゃない
依頼した上司が無能ってことだ

TDDに限ったことじゃないがルールは運用に乗せてこそ意味がある
権限の無いヤツにルール作らせたって回せるわけがない

473-475は無能

476がスゲー解決策を提示してくれるようです

>>459
> そのほかのｃファイルのヘッダを全部インクルードしてて
というのが、「その他の.cファイルがインクルードしてるファイルを、全部インクルードしている」という
意味なら、不要なインクルードファイルを削るのは何も問題がない（問題があればビルドできない）し、
メンテナンスコストが下がるという大きなメリットがある。

>>473
> 末端の俺ごときがインクルードをいじると鬼のように罵倒される
というような理由付けで上長（？）を説得できないほどの低レベルな職場なら、辞めてしまったほうが
いいんじゃないか。

使ってないincludeをコメントアウトしただけで動かなくなることもあるからなぁ
末端のPGが勝手にいじるのもどうかと思うよ

組み込みとか古いプログラムだとよくあるんだよね
メモリ周りにバグがあって偶然動いているようなプログラムは
参照を外しただけでアドレスが狂って動かなくなる

組み込み系のひとが書くCなんてめちゃくちゃだよ

>>480
それ単にその人がレベルが低かっただけじゃないか。
組み込み系の組織では、MISRA-Cを意識してるとこ多数だよ。

組み込み系が酷くなかったいう話は聞いたことがない
自分たちはちゃんとやってるつもりだったのか

組み込み系が酷いということなら、業務系も酷いぞ
ゴミの寄せ集めだし

酷い方向が違うんだよな。
どっちも酷いのは多い

組み込みや業務系が酷いと言われるのはライフサイクルが長いからだよ

それ以外のプロジェクトも実際はゴミばっかり
だけどそれが顕在化する前に淘汰されてサービスの終了を迎えてるってだけ

組み込みが酷いのはハードやコンパイラの制約によるもの
業務系が酷いのは要員のレベルのばらつきの大きさによるもの

組み込みも要員のレベルとさせてくれ
環境があるのに頑なに適応せずに昔のままをやりたがる

>>487
ハード完成してなくてI/F仕様書もレビュー通ってないけどこれで実装お願い！
開発環境？　ベストなものをお願いします！
って言われたことある？

>>488
ある、キーボードぶん投げた希有な事例だった。
割とマジで開発馬鹿にすんなゴルァって部長ですらぶち切れてた

ソフト屋さんが仕様決めて！その通り作るからってのはあったな
おまえ回路図で線繋ぐだけかよって…
ハードのデバッグもソフト屋まかせな奴だったのでキレました

亀レスだけど

>>481 組み込み系の組織では、MISRA-Cを意識してるとこ多数だよ。
MISRA-C て本当にまともなルール仕様か？

下を見て、こりゃ阿呆だと思っている。
20.7 R setjmpマクロ及びlongjmp関数は、用いてはならない。

下手な使い方して落とし穴掘られるリスクより
ハングさせてハードリセットする方がマシというケースも多い

でテスト駆動ってどうなのよ

終わった

テストなんて書くだけ無駄
コードとテストで仕事が2倍になるだけ
どうせ一回通ったら用済みなんだから書く必要ない

TDD by example 再出発

>>495
じゃあテスト仕様を先に作るだけなら問題ないの？

yes

一回通ったら用済みとか言ってる時点でまともな開発やったことない奴だってわかる

そんな香具師と判ってて相手するとか
どんだけ親切なんだ

むしろテストが一度でも行われていたらラッキー

どっかのSEを自称するひとがW字開発とか意気込んでたけど
これもテスト駆動ってやつ？

違うんじゃね

w字開発は悲劇の開発

W字って初めて聞いた
仕様変更や手戻りが発生したら大変そうなんだけどどうなの

仕様変更の度に試験仕様書の修正が発生します

仕様変更という言葉の意味を知った上で言ってるのか

メタテストですね

>>507
何か変か？
仕様決める→テスト仕様書作成→プログラム設計→コーティング
なんだから仕様が変わる度にテスト項目見直しだろ

>>509
変だろ
なんでそんな当たり前のことを述べる必要があるんだ
それとも>>506には何か深い意味があるのか？