【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/06(水) 20:26:40.58
>>91
そんな事実みたことねーよ。
2011/07/06(水) 20:36:51.52
ぶっちゃけ他社のソース見ることはないな
うち元請けじゃないし
2011/07/13(水) 00:20:56.20
t-wadaは真心。
t_wadaは下心。
Twitterで流れていたネタｗ
2011/07/13(水) 17:00:39.07
>>94
古いね。
2011/07/14(木) 08:02:22.70
こんなしょーもないネタを事情通っぽく「古いね」とか言われてもなぁ。
2011/07/14(木) 09:49:55.26
おまえらTDDについて話せよ。

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

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

定番どころだとボーリングなのかもしれんが、サンプルとしてあまり良い気がしないんだよな。
2011/07/14(木) 11:22:03.40
別に構えてお題を用意する必要ないだろ
今までやってた業務のやつやらしゃいいじゃん
2011/07/14(木) 22:29:28.39
だよなあ
2011/07/15(金) 04:17:44.07
ここにいる人ってTDDBCとか出たり、テスト駆動開発入門の本を読んだりしないで
適当に実業務の中でTDDを覚えたり2chやWebの記事やblogなどで勉強した感じですかね？
少なくともTDDBCとかには出ていない雰囲気がする。。。
2011/07/15(金) 12:53:11.73
ヒント：今までのTDDBCの参加のべ人数を推定してみよう
2011/07/16(土) 00:39:49.48
あんなイベント出てるやつは「TDDBCに参加することでTDDをなんとなく理解をしている自分に酔ってる」と思う。
まあ、2chの練習も程度が低いので五十歩百歩だなｗｗｗ
2011/07/16(土) 00:40:56.78
ああいう、オフのイベントに参加できるだけリア充だと思う。
俺には考えられない。。。
2011/07/16(土) 04:16:36.95
reviewで充分だよな
2011/07/17(日) 22:35:19.81
>>102
入り口はそれでもいいんだよ
2011/07/19(火) 17:32:31.53
bootcampに参加する奴って、人脈を広げたい奴か、自分で書籍を読み通すことができない奴か、
暇人かのどれかでしょ。
2011/07/19(火) 18:57:09.08
どうした、bootcampで小馬鹿にでもされたか？
2011/07/19(火) 19:23:10.60
TDDBCを叩いてる奴は和田さんに相手にしてもらえなくて悲しい思いでもしたのか？
2011/07/19(火) 20:35:24.16
これは酷い
2011/07/19(火) 21:19:32.09
TDDBC参加すらしたことのない小者が2chでTDD？ﾌﾟｹﾞﾗ。

とかいいながらそれは無いわ…。引くわ…。
2011/07/20(水) 11:50:04.76
なんつーか、マ板でやれお前ら
2011/07/20(水) 21:38:39.32
まずは、外に出て人に会うことから始めろよｗｗｗ
2011/07/20(水) 21:54:26.24
堪忍して
2011/07/28(木) 18:40:18.43
テストに関するオススメの良書教えて
115デフォルトの名無しさん
垢版 |
2011/07/28(木) 18:46:36.80
あげ
2011/07/28(木) 21:01:34.98
良書はまだ無い、
原点のテスト駆動開発入門を写経するが吉


117デフォルトの名無しさん
垢版 |
2011/07/28(木) 21:21:52.42
テスト駆動開発入門は訳がひどいと書いてあるのが不安になるな
英語の勉強もかねて原著を読むか・・・

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

基本から学ぶソフトウェアテスト―テストの「プロ」を目指す人のために
ソフトウェアテスト技法―自動化、品質保証、そしてバグの未然防止のために
ソフトウェアテスト293の鉄則
2011/07/28(木) 21:47:37.60
本読んでTDDできると思ってるやつらおめでたすぎ。
TDDBCに参加しないと真のTDDは実践できない。
2011/07/28(木) 22:09:02.48
釣りにすらなんねーだろ…ｗ
2011/07/28(木) 22:09:20.82
宗教的で気持ち悪いな
2011/07/28(木) 22:16:19.16
>117
テスト駆動開発入門は確かに読みにくいけど、コードを写経する分には問題ない
1回写経してみると読みにくさも気にならないと思う

ソフトウェア技法とかの本はどっちかというと、品質保証系のテストの本。
そっちはそっちで役に立つし、TDDに応用できないかと言えば色々できるけど、別の分野と考えた方がいいかも。
良書ではあると思うよ
2011/07/28(木) 23:24:00.87
TDDは慣れるものじゃなくて、理解して実践する類のもの
写経なんかすんなよ　ケントベック泣いちゃうぞ

写経している奴は、ケントベックが
「他のTODOをやってみたが上手く行かないことが分かったので、先にこっちのTODOをやる」
などとさらっと書いてある部分はどうしてんだろう
123デフォルトの名無しさん
垢版 |
2011/07/29(金) 00:52:42.66
右も左も解らない状態でどうやって慣れるのさｗ
2011/07/29(金) 20:43:51.15
テストって二つの意味があるんだよな。
設計をプログラムに落とすテスト駆動開発と。
品質を保証するテスト。

どっちもテストって名前ついているけど、
全くの別物だよ。
2011/07/29(金) 22:55:13.75
そういうデベロッパーテスティングの意味を理解するだけでもTDDBCにいく意味はあると思うぞ。
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がうらやましい。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。