2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

テストしにくいコードをテストする方法 その2 [無断転載禁止]©2ch.net

1 :デフォルトの名無しさん:2017/01/03(火) 14:50:44.83 ID:f6cee8Pv
ここで言うテストっていうのは
ユニットテストみたいなものね。

人間がぽちぽち操作してやるテストじゃありません。


前スレ テストしにくいコードをテストする方法教えて下さい
http://echo.2ch.net/test/read.cgi/tech/1334408391/

2 :デフォルトの名無しさん:2017/01/03(火) 18:00:08.97 ID:f6cee8Pv
例で考えよう。
private function numberOfFeet(動物) returns 脚の数
{
 if (動物 == 人) { return 2 }
 if (動物 == 犬) { return 4 }
 if (動物 == 猫) { return 4 }
 raise exception 知らない動物
}
っていう関数が既にあるとする。

3 :デフォルトの名無しさん:2017/01/03(火) 18:00:28.68 ID:f6cee8Pv
その関数で対応する動物がもっと増えたとしよう。

private function numberOfFeet(動物) returns 脚の数
{
 if (動物 == 人) { return 2 }
 if (動物 == 犬) { return 4 }
 if (動物 == 猿) { return 4 }
 if (動物 == キジ) { return 2 }
 if (動物 == 猫) { return 4 }
  :
  :
 raise exception 知らない動物
}

いよいよ複雑になってきた。privateなnumberOfFeetをテストしたい。
となってきたら、設計が悪いって話なんだよ。

そもそもこの関数のテストはどうするか? ↓このようにやるか?
assert( numberOfFeet(人) == 2 )
assert( numberOfFeet(犬) == 4 )
assert( numberOfFeet(猿) == 4 )
 :

あほらしい。これは実行コードの内容を単純に変換してテストコードに転記したにすぎん。
新たに対応する動物が増えたら、それに対応するコードを追加するだけの単純作業
いったいなんの意味があるというのか。
そこ(実行コード)にそう書いてあるんだから関数の実行結果はあきらかではないか。

カバレッジを100%にするためには必要?
それは "設計が悪いから" こうするしかなくなってしまってるんだよ

4 :デフォルトの名無しさん:2017/01/03(火) 18:00:58.15 ID:f6cee8Pv
private関数がテストしたいと思ってきたら設計が悪いという話だったね。
この場合は、このprivate function numberOfFeetを
publicにしてテストするのではなくて設計を変えるってことだよ。

もちろんやり方はいくつもある。もっともシンプルな解決方法ではないが
今回はヘルパークラスを作る方法で解決してみようか。

LookupTableクラスというものを作る。
このクラスは特定のキーを元に特定の値を返すクラスだ。
newの引数で対応するキーと値の組み合わせを渡すことができる。

lookup_table = new LookupTable({a: 1, b: 2, c: 3})

さて、このLookupTable・・・のテストを書くとき、
動物が増えたら?などということを考える必要はない。
LookupTableは汎用的なクラスなのだからそこに動物は出てこないからだ。
では使う側はどうなるか?

data = {人: 2, 犬: 4, 猿: 4, キジ: 2, 猫: 4}
numberOfFeet = new LookupTable(data)

こういうコードを書くだろう。
テストはどうする? ・・・答えは "不要" だ。

なぜならばLookupTableのテストはすでに書いているからだ。
おそらくこのコードは別のテストコード時に最低1回は通るだろう。
それでカバレッジは100%になる。いくら動物が増えたとしても
そのdataというデータ定義の行は通るのでカバレッジは100%のままだ。

5 :デフォルトの名無しさん:2017/01/03(火) 18:01:14.98 ID:f6cee8Pv
これを手抜きやずるいやり方だと思うか?

元の設計のテストというのはデータが増えれば対応するテストを
増やすだけという単純作業だっただろう?

こんなのそもそもやる意味がない
データが変われば、それに応じて答えは変わる。
それだけのことだろう。

こういうのは、そもそもやらなくていいんだよ。

変数aに1を入れました。これ対応する変数aは1であるか?という
テストコードを書く意味はない。
テストすべき対象は実行するコードであってデータ定義はテストしない。

LookupTableという汎用的なクラスを作ることで実行するコードの中から
データ定義を分離させることで、少ないテストパターンでカバレッジ100%にしながら
テストコードを書くことができる。それが可能な設計に変更したからだ。

ということで、 テストしたくなってしまった
private function numberOfFeetは
悪い設計を正すことで存在が消えました。

ということでおしまい。

6 :デフォルトの名無しさん:2017/01/03(火) 18:01:31.58 ID:f6cee8Pv
プログラム設計の善し悪しとテスト技法は密接に関係している。

というかprivate関数をテストする言語特有の裏技的テクニックは
テスト技法ではないんだがな。

プログラム設計が悪いと、テストが難しくなったりできなくなったりする。
private関数のテストもその一つで、private関数がテストしたいほど
複雑になったら、それは設計が悪いということだよ。

こういうのはprivateのまま頑張ってテストするんじゃなくて、
単純にpublicに変えるのでもなくて、
汎用的な処理をヘルパークラスや親クラスとして抽出する

テストしづらい → 設計が悪い → 設計を直す → テストを書く
こういう流れでなくてはいけない。



話は少し変わるが、設計を直すその途中で作成するリファクタリングを
するためだけに用いる一時的なテストコードに名前をつけたいね。

本来であればテストしづらいコードであってもテストコードは
あってしかるべきなんだが、多くの場合悪い設計のコードにテストコードはない。
だから新たにテストコードを追加する。しかしこのテストコードは
リファクタリング後にすぐにメンテナンスして、違う形になる。

だから一時的なテストコードになるんだよね。

7 :デフォルトの名無しさん:2017/01/03(火) 18:01:50.63 ID:f6cee8Pv
あ、そうそう

リファクタリングを行うための一時的なテストコードであれば
単純にprivateをpublicに変えたり
private関数のテストコードを書くのもありだから。

このprivate関数へのテストはリファクタリングをしたあとの
テストコードのメンテナンスでなくなるという前提であれば
一時的にprivate関数へのテストコードを書くのはあり。

8 :デフォルトの名無しさん:2017/01/03(火) 18:02:53.02 ID:f6cee8Pv
https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.md#testing-private-code

Testing Private Code

If you change your software's internal implementation,
your tests should not break as long as the change is not observable by users.
Therefore, per the black-box testing principle, most of the time you should test your code through its public interfaces.

If you still find yourself needing to test internal implementation code, consider
if there's a better design that wouldn't require you to do so. If you absolutely
have to test non-public interface code though, you can.

プライベートコードのテスト

あなたのソフトウェアの内部実装を変更した場合、変更がユーザによって観察されない限り、
テストは中断されるべきではありません。 したがって、ブラックボックスのテストの原則に従って、
ほとんどの場合、パブリックインターフェイスを使用してコードをテストする必要があります。

依然として内部実装コードをテストする必要がある場合は、そうする必要のない
優れた設計があるかどうかを検討してください。 しかし、非公開のインターフェイスコードを
絶対にテストしなければならない場合は、できます。

9 :デフォルトの名無しさん:2017/01/03(火) 18:03:14.28 ID:f6cee8Pv
「privateだからテストしてはいけない」という意見はそもそも的外れで
テストすべきものがprivateという状態ができたら
それは設計がおかしいと気づかないといけない。

「privateだからテストしてはいけない」は単なる思考停止で
privateをテストしたいのは設計がまずいからだね、設計をなおそう。
という流れにならなければいけない。

10 :デフォルトの名無しさん:2017/01/03(火) 18:03:37.53 ID:f6cee8Pv
http://higelog.brassworks.jp/1941

テストコードにもリファクタリングが必要

・昔はテストコードがメンテ対象であるという意識が薄かった
・見てすぐ分かるテストコードがよいという考えからコピペコードが非常に多かった
・テストコードがたくさんあることによって動きが取りづらくなり、変更コストも上がる
・素早く動きたいがためにTDDしているのにそんな皮肉な結果になってしまう
・たくさん書くのではなく必要十分書くことが大切
・書き散らすと「テストケース爆発」を起こす
・テストコードもメンテし続けるためにリファクタリングして行く必要がある

11 :デフォルトの名無しさん:2017/01/03(火) 18:04:15.86 ID:f6cee8Pv
http://dev.classmethod.jp/testing/10_errors_about_unit_testing/
> 3.テスト対象が完璧な設計であるという勘違い
>
> ユニットテストを実践することによりプロダクションコードが
> 適切に修正されていく状態でなければなりません。
>
> ユニットテストの重要な目的のひとつに「テスト対象クラスやメソッドの
> 使用感を把握する」ことがあります。机上の設計やフィーリングだけで
> 書いたコードは、使ってみての違和感や使いにくさに気付き難いものです。
> それらの使用感は、実際に利用してみてはじめて気付きます。
> だから、テストコードを書くことで実際に利用してみます。これはサンプルコードを書く事に他なりません。
>
> サンプルコードを書くと、「これは使いにくい」と感じたり、
> 「これはこうした方が使いやすい」と感じたりします。それはユニットテストの
> 大きな効果です。もし、使いにくいと感じたならば、すぐにテスト対象を修正します。
> テスト対象が完璧な設計で変更する余地が全く無い、または変更し

12 :デフォルトの名無しさん:2017/01/03(火) 18:04:36.15 ID:f6cee8Pv
これも関連する話。まずリファクタリング後にテストを変更するのは当然

まず対象のクラスに対してテストを書く。そしてリファクタリングをする。
この時、汎用的な処理をヘルパークラスや親クラスとして抽出する。

ここまででテストを変更することはないが、
次に対象のクラスにあったテストのうち、ヘルパークラスや親クラスに分離したものは、
対象のクラスのテストではなくて、ヘルパークラスや親クラスのテストとして移動する

ヘルパークラスや親クラスでテストしている内容を、
それを使用している対象クラスでもやる必要はない。

具体的に言うと、あるモデル、例えばUserモデルクラスにsaveメソッドを作ったのであれば
そのsaveメソッドのテストを書くのは当然だが、そのsaveメソッドが親クラス
(例えばRailsで言えばActiveRecord::Baseクラス)にあるものならば、
Userモデルクラスでsaveメソッドのテストをする必要はない。


こうやってヘルパークラスや親クラスに処理を移動して、それに対するテストを書くことで
それを使用している部分ではテストが不要という状態を作り上げることが重要

13 :デフォルトの名無しさん:2017/01/03(火) 18:05:03.70 ID:f6cee8Pv
privateメソッドに対してテストをしたくなっったら
それはクラスが肥大化してる証拠だよ。

まず前提としてprivateメソッドなんてものは
ほとんど必要ありません。

長い処理があったとして、その中で汎用的な処理を
抜き出していったら、コードは短くなります。
短いのだからprivateな関数にするまでもありません。

それでもprivateメソッドが残ったとしたら
それはヘルパーメソッドとして別クラスに分離する。
別クラスの関数を呼ぶのだから、必然的にそのメソッドはpublicになる
そうすりゃそのメソッドだけでテストかけるだろう?

privateメソッドをテストしたいっていうのは、作り方が悪いんだよ。

14 :デフォルトの名無しさん:2017/01/03(火) 18:06:10.26 ID:f6cee8Pv
ある程度埋めないと落ちるといわれたので、
前スレのハイライト(笑)をコピペ

15 :デフォルトの名無しさん:2017/01/03(火) 18:45:05.85 ID:mYtDE+67
なめてんの?

16 :デフォルトの名無しさん:2017/01/03(火) 19:23:41.90 ID:Oj8nbLhF
>>13
>privateメソッドをテストしたいっていうのは、作り方が悪いんだよ。

バカ丸出し。
privateメソッドだからといって十分にunit testingしない奴は頭が悪いんだよw
privateメソッドがあるからといって設計のせいにするのは性格が歪んでんだよw
privateメソッドをテストする技術を持たないからといって
出鱈目な ”あるべき論” を捏造する奴は技術者としての道徳が欠如してるんだよw

17 :デフォルトの名無しさん:2017/01/03(火) 22:27:14.69 ID:f6cee8Pv
>>16
お前日本語がわかってないなw

18 :デフォルトの名無しさん:2017/01/04(水) 09:28:49.04 ID:cRY9oGv2
privateメソッドとテストに相関はありません
リファクタリングのスレに移動してください

19 :デフォルトの名無しさん:2017/01/04(水) 14:06:42.84 ID:mEkZwZd0
>>13
馬鹿丸出し
頭固すぎ

20 :デフォルトの名無しさん:2017/01/04(水) 14:10:32.56 ID:mEkZwZd0
>>9
> テストすべきものがprivateという状態ができたら
> それは設計がおかしいと気づかないといけない。
という思考停止にきづかない馬鹿pgr

21 :デフォルトの名無しさん:2017/01/05(木) 04:41:00.85 ID:4wDE4Xcp
当のKentは ID:f6cee8Pv みたいな教条主義とは対極にいるんだがな。

22 :デフォルトの名無しさん:2017/01/05(木) 07:46:32.69 ID:SvuiXrcs
>>21
どこが?
https://twitter.com/kentbeck/status/3579860805

2chのレスだけで知ったかぶってる、まさに半可通
この手のクズは他分野でも同様なのだろうが、
本も読まず、手も動かせない人間なんて、
職人気質なTDD実行側の人間が、一番嫌うタイプだぞ

23 :デフォルトの名無しさん:2017/01/05(木) 07:59:15.46 ID:SvuiXrcs
むしろつまみ食いしかしてないくせに、拡大解釈して腐ったコード撒き散らすな
ケントベックはXPは熟練者が必要とは言ってるだけで、手法は何でも良いなんて言ってない
テストコードも、trivialな物は不要、複雑なprivateメソッドは設計が悪いと一蹴してる
これを教条主義だと言うなら、レッテル張る事しかできない屑だな

24 :デフォルトの名無しさん:2017/01/05(木) 08:26:33.27 ID:rS/TqFdr
前スレでprivateメンバーしか見ずにそれをテストしようとしたり、考え方がおかしい。

あと、Kent Beckはテストは不要だと思ったらやらない、と言うぐらい柔軟な思考の持ち主だぞ

25 :デフォルトの名無しさん:2017/01/05(木) 09:16:09.02 ID:qUpJhZLr
前スレ埋めてからやってくれ。

26 :デフォルトの名無しさん:2017/01/06(金) 14:09:56.36 ID:jUueQ44/
>>23
> 複雑なprivateメソッドは設計が悪いと一蹴してる
ソースは?

>>22のtweetがそれだとしたら、その会話の流れが設計の善し悪しであることを示す他のtweetも示せ

27 :デフォルトの名無しさん:2017/01/06(金) 14:31:04.58 ID:jUueQ44/
Kent BeckはImplementation Patternsの中でこう言ってる

* Inner Class
* Bundle locally useful code in a private class.

* Method Visibility
* Make methods as private as possible.

* Helper Method
* Create small,private methods to express the main computation more succinctly.

別に、private classやprivate methodを否定しているわけではない

28 :デフォルトの名無しさん:2017/01/06(金) 15:00:59.05 ID:ueXke68e
公開する必要のないprivateメンバーをpublicにしてまでテストするなんて真逆の発想なんだよなぁ

29 :デフォルトの名無しさん:2017/01/06(金) 15:23:30.30 ID:jUueQ44/
>>28
まあ、そのprivateメソッドが、所属するクラスと直交していて再利用可能な内容だった場合は
別クラスにpublicメソッドとして切りだすのもいいけど、いつでもそうとは限らないからな

30 :デフォルトの名無しさん:2017/01/06(金) 16:24:11.26 ID:bv2F1pCR


31 :デフォルトの名無しさん:2017/01/06(金) 19:55:59.99 ID:SxMvRiz3
飽きてきたので以降privateの話題禁止

32 :デフォルトの名無しさん:2017/01/06(金) 21:44:03.66 ID:IT5nhYwQ
>>27
レスをよく読め文盲め
言ってもいない事を言ったかのように叩くやつがあるか

33 :デフォルトの名無しさん:2017/01/06(金) 21:44:44.23 ID:IT5nhYwQ
>>26
勝手に追えばいいだろ
くだらない人種だな

34 :デフォルトの名無しさん:2017/01/07(土) 01:43:02.53 ID:jcRWOLCk
結局世界的有名人であるKent Beckが言ってることは
>>1がまとめたとおり。

privateメソッドをテストしようと思った時点で、
そのprivateメソッドは設計が悪いということ。

悪い設計を直す過程でpublicになる。
設計を直さなないで単にpublicに変更するのは間違い。

35 :デフォルトの名無しさん:2017/01/07(土) 07:12:47.19 ID:0cNXAmIk
>>34
まだそんなこと言ってんの?ばかだなあw

36 :デフォルトの名無しさん:2017/01/07(土) 07:22:58.29 ID:55rirhTJ
そこで#define private publicですよ。え?

37 :デフォルトの名無しさん:2017/01/07(土) 08:54:35.16 ID:bP0cwlRr
publicメソッドしかテストできない道具を使ってprivateメソッドをテストすることはできない。
一種のトートロジーだな。

38 :デフォルトの名無しさん:2017/01/07(土) 12:20:08.80 ID:HNCUhS1Q
前スレ埋めてからやれ
こういう奴らが糞コードを放りっぱなしにしていってこっちが掃除しなくちゃならなくなるんだよ
バグ解析依頼されて見てみたら、意識だけ高いけどそのまま放置されたゾンビコードに当たったときの腹立たしさって
まあお前らのおかげでちょっといい飯が食えるんだから感謝しないといけないな

39 :デフォルトの名無しさん:2017/01/07(土) 13:20:41.90 ID:jcRWOLCk
>>35
悔しいなら反論しろよw

40 :デフォルトの名無しさん:2017/01/07(土) 19:21:41.83 ID:adAq7wbq
今現在を占う 2017/1/7 19:21

おみくじ 大吉 →  ♌ 獅子座
.      吉   →  ♈ 牡羊座 ♋ 蟹座   ♓ 魚座 
.      中吉 →  ♏ 蠍座 
.      小吉 →  ♉ 牡牛座 ♍ 乙女座 ♎ 天秤座 ♒ 水瓶座
.      末吉 →  ♊ 双子座
.      凶   →  ♐ 射手座
.      大凶 →  ♑ 山羊座

41 :デフォルトの名無しさん:2017/01/08(日) 09:54:40.93 ID:qkk6ZrX+
吉だぜ、いやっほーい

42 :デフォルトの名無しさん:2017/01/08(日) 09:54:57.91 ID:qkk6ZrX+
あ、昨日か.....

43 :デフォルトの名無しさん:2017/01/09(月) 20:16:25.89 ID:pl8AdjB2
今現在を占う  2017/1/9 20:16  (不定期テスト)

おみくじ 大吉 →  ♍ 乙女座 ♑ 山羊座
.      吉   →  ♉ 牡牛座 ♎ 天秤座 ♒ 水瓶座
.      中吉 →  ♋ 蟹座 
.      小吉 →  ♈ 牡羊座 ♏ 蠍座 
.      末吉 →  ♌ 獅子座
.      凶   →  ♊ 双子座 ♐ 射手座
.      大凶 →  ♓ 魚座 

44 :デフォルトの名無しさん:2017/01/11(水) 00:09:48.89 ID:ha9kcMkV
あんまり可視性でグダグダ言っても揉め事しか起こらん印象は有る。
だからあんまりカプセル化周りの議論は好きではない。
重要なのはテストするコードの粒度じゃないかね。
3 のレベルのコードをテストするのは粒度が細かすぎる。
3のコードを呼んで何かしてるコードのテストコードを書くべきなんだろう。

45 :デフォルトの名無しさん:2017/01/11(水) 23:15:37.40 ID:1SbN3a75
端折って網羅性が確保できなくなるのであればそもそもこのテスト自体イラネーってのあるよ
だからやるなら機械的に全部やるかそもそもやらないかのどっちかになると思う

46 :デフォルトの名無しさん:2017/01/11(水) 23:16:53.94 ID:1SbN3a75
あ、Visual Studioのユニットテスト的な話ね

47 :デフォルトの名無しさん:2017/01/12(木) 00:02:44.60 ID:qhQd7W/g
>>46
2017のlive unit testのことを言ってる?

48 :デフォルトの名無しさん:2017/01/13(金) 06:48:56.80 ID:tNTQooLV
>>44
しょうがないよ、ID:f6cee8Pvの能力ではそこが限界・・・

49 :デフォルトの名無しさん:2017/01/13(金) 23:07:22.63 ID:9L2JHio8
>>48
呼んだか?

何か言いたいことがあるなら言ってみな。

今のところ俺の書き込みに論理的に反論している
文章は存在していない。

50 :デフォルトの名無しさん:2017/01/13(金) 23:40:30.59 ID:2oF12qKz
テスト
○○○●○○○○○○○○●○○○○○○○○●
○○○●○○○○○○○○●○○○○○●●●●●●●
○○○●○○○○○●●●●●●●○○●○○○○○●
○●○●○●○○○○●○○○●○○○○●●●●●○
○●○●○●○○○○●○○○●○○○○○○○●○○
○●○●○○●○○○○●○●○○○○○○○●○○○
○●○●○○●○○○○●○●○○○○●●●●●●●
●○○●○○●○○○○○●○○○○○○○○●
○○○●○○○○○○○●○●○○○○○○○●
○○○●○○○○○○●○○○●○○○○○○●
○○●●○○○○○●○○○○○●○○○○●●

○○○○○○○●○○○○○○○○○○○○○○○○●○○○○○○○○○○○○○○○○●
○○○○○○○●○○○○○○○○○○○○○○○○●○○○○○○○○○○●●●●●●●●●●●●●●
○○○○○○○●○○○○○○○○○●●●●●●●●●●●●●●●●○○●○○○○○○○○○○○○●
○○○○○○○●○○○○○○○○○○○○○●○○○○○○●○○○○○○●○○○○○○○○○○○○●
●●●●●●●●●●●●●●●●○○○○○●○○○○○○●○○○○○○○○●●●●●●●●●●
○○○○○○○●○○○○○○○○○○○○○●●○○○○●●○○○○○○○○○○○○○○○●●
○○○○○○●●●○○○○○○○○○○○○○●○○○○●○○○○○○○○○○○○○○○●●
○○○○○○●○●○○○○○○○○○○○○○●●○○●●○○○○○○○○○○○○○●●
○○○○○○●○●●○○○○○○○○○○○○○●○●●○○○○○○○●●●●●●●●●●●●●●●●
○○○○○●●○○●○○○○○○○○○○○○○○●●○○○○○○○○○○○○○○○●
○○○○○●○○○●●○○○○○○○○○○○○●●●●○○○○○○○○○○○○○○●
○○○○●●○○○○●●○○○○○○○○○○●●○○●●○○○○○○○○○○○○○●
○○○●●○○○○○○●●○○○○○○○○●●○○○○●●○○○○○○○○○○○○●
○○●●○○○○○○○○●●○○○○○●●●○○○○○○●●●○○○○○○○○○○●
●●●○○○○○○○○○○●●●○●●●○○○○○○○○○○●●●○○○○○○●●●

51 :デフォルトの名無しさん:2017/01/16(月) 23:19:44.60 ID:9FmOEppL
>>48
お前ってプログラムに限らずいつも的はずれな難癖しかつけないよな

52 :デフォルトの名無しさん:2017/01/21(土) 00:48:16.31 ID:EhyrNbEj
>>49
>>27に論理的な反証があるだろw
ほんとに頭悪いのな
Kentの書いてる英語のとこだけ読み直してお前自身の矛盾に気がつけないの?

53 :デフォルトの名無しさん:2017/01/21(土) 06:46:40.76 ID:gnjAlXGF
>>52
前スレでもそうだったけど、彼は都合の悪いレスは目に入らない人だから何言っても無駄

54 :デフォルトの名無しさん:2017/01/21(土) 13:01:41.54 ID:sMDuy5hJ
>>52
それのどこが論理的な反証?

今の話はprivateメソッドのテストの話で、
privateメソッドが良いかダメかの話はしてない

Kent Beckのどこにprivateメソッドの話が書いてあるんだ?

55 :デフォルトの名無しさん:2017/01/21(土) 13:28:19.57 ID:zMOHiEOd
くすくす…

56 :デフォルトの名無しさん:2017/01/21(土) 13:47:45.70 ID:EhyrNbEj
残念な頭だな

57 :デフォルトの名無しさん:2017/01/21(土) 13:58:00.26 ID:sMDuy5hJ
反論お待ちしてまーすw

58 :デフォルトの名無しさん:2017/01/21(土) 14:03:40.46 ID:EhyrNbEj
Kentの引用読んでも矛盾に気づけない残念さ
ひとりだけ斜め上

59 :デフォルトの名無しさん:2017/01/21(土) 14:04:25.54 ID:sMDuy5hJ
時間が相手勘違いされかねんから俺の意見を書いておくか

まずprivateメソッドはpublicメソッドを通してテストするもの
(この時点でprivateメソッドの存在は否定してない)

もしprivateメソッド単体でテストしたいと思ったら
それは設計がまずいということ、設計を見直したら自然にpublicになる。
(privateをpublicに変えるだけではない。それは設計変わっていない)

そうすればpublicメソッドをテストすれば良くなる。

60 :デフォルトの名無しさん:2017/01/21(土) 14:04:58.86 ID:sMDuy5hJ
>>58
俺の意見とどう矛盾するのか言ってみな

61 :デフォルトの名無しさん:2017/01/21(土) 14:05:54.01 ID:EhyrNbEj
脳が単純だから単純な考え方に縋っちゃうんだろうね
それがたたって物事を複雑にする

62 :デフォルトの名無しさん:2017/01/21(土) 14:07:22.70 ID:sMDuy5hJ
脳が単純だとprivateメソッドのテストコードの話をしていたのに
privateメソッドを作っていいかどうかの話に
単純化(笑)されるんだろうね。

63 :デフォルトの名無しさん:2017/01/21(土) 17:46:46.32 ID:O/GZ8TN6
クラス自体がウンコ

最近そう思うようになった

64 :デフォルトの名無しさん:2017/01/21(土) 19:28:01.03 ID:ij3ZsOnR
xUnitが定番になる以前はビルトインテストも珍しくなかったわな。
つか、他人の作ったテストフレームワークを使うのが当たり前になる前はビルトインテストの方が多かったくらい。

ID:sMDuy5hJ は「製品コードにテストコードが混在するのは良くない設計だ」とでも言うだろうか。

65 :デフォルトの名無しさん:2017/01/21(土) 20:08:55.14 ID:sMDuy5hJ
>>64
なんか罠張ってますぜって臭いがプンプンするなw
俺からなんて言葉を引き出したいのさ?

> 「製品コードにテストコードが
まず前提として「製品コード」という物の話をしてからだよな。
世の中にはソフトウェアに限らず、不具合がたくさんある不良製品もたくさんある。
テストコードが混在するか否かに関係なく
「(不良)製品コードは良くない設計だ」と言うよ。当然だろう?

それから昔のハードディスクはよく壊れたものだが、今壊れにくくなってるのは
製品を改良したからだ。より良い設計に変えた、逆に言えば昔のやり方は設計が今より悪かった。
これも言うまでもない話だよな。

それとテストコードとはなんぞやの話もしないといけない。
今話しをしてるテストコードとうのは製品で必要ないものであって
故障の場合に障害を調べる調査用端子や自己チェック機能はテストコードではない。
そういう機能をもたせるという仕様があって、その仕様を満たすためにテストコードが存在するだろう。

で、ここまでがお前の罠に引っかからないようにするための話な。

> 「(優れた)製品コードにテストコードが混在するのは良くない設計だ」とでも言うだろうか。
あぁ、そのとおりだ。何か言いたいことがあるならどうぞ

66 :デフォルトの名無しさん:2017/01/21(土) 21:01:47.67 ID:gnjAlXGF
sqliteみたいな例外はあるけど一般的にはそこまで書かない、全てのコードに対してsqlite並みにテストコード書いてたらプロジェクト終わらんよな

67 :デフォルトの名無しさん:2017/01/21(土) 21:22:40.22 ID:ij3ZsOnR
>> 「(優れた)製品コードにテストコードが混在するのは良くない設計だ」とでも言うだろうか。
>あぁ、そのとおりだ。何か言いたいことがあるならどうぞ

俺は、テストコードが混在するかどうかが設計の良し悪しに関係するとは思わんが、
問題はこんな単純なことですら「良い設計」の定義が一致しないということ。

そのへん曖昧なまま「privateメソッドをテストしようとするのは設計が悪い」と主張しても、
証明になってないという突っ込みする奴はいるかもしれないが、それ以上反論は
しようがないわな。

68 :デフォルトの名無しさん:2017/01/21(土) 22:36:34.80 ID:sMDuy5hJ
>>66
> sqliteみたいな例外はあるけど一般的にはそこまで書かない、全てのコードに対してsqlite並みにテストコード書いてたらプロジェクト終わらんよな

だから十分にテストされているライブラリやフレームワークを使い。
なるべくコードを書かないようにするのが良いぞ

自分のプロジェクト専用の処理は、自分でテストするしか無い。
しかし、その中で汎用の処理を見つけ出して、そこを外出することで
自分がテストする量を減らすことができる。

そうやってきたら、俺はpublic関数で10行前後、
private関数なんか更に短くなってしまって。

だから言うんだprivate関数をテストしたいと思ったら
設計が悪いだけだってこと。

69 :デフォルトの名無しさん:2017/01/21(土) 22:37:51.39 ID:gnjAlXGF
>>68
それは汎用ライブラリーを作らない人の立場での話だな。

70 :デフォルトの名無しさん:2017/01/21(土) 22:40:50.50 ID:sMDuy5hJ
>>67
> 問題はこんな単純なことですら「良い設計」の定義が一致しないということ。

俺は良い設計の定義の話なんかしてないんだが?

お前が思い込んでるんじゃないか。
「世の中に出ている製品」=「良い設計」だと
お前はそう言いたいんだろう?

俺が言ったのは「製品コードだからって良い設計ということにはならない」と
言うこととと「悪い設計」の話だけなんだがちゃんと理解できてないのか?
そういやprivate関数をテストしたくなったらそれは「悪い設計」とも言ったな。

71 :デフォルトの名無しさん:2017/01/21(土) 22:41:52.89 ID:sMDuy5hJ
>>69
> それは汎用ライブラリーを作らない人の立場での話だな。

汎用ライブラリを作る人の立場の君に聞きたい。
世の中でよく使われている汎用ライブラリで
sqlite並みにテストコードを書いてないライブラリはどれだ?

72 :デフォルトの名無しさん:2017/01/21(土) 22:55:22.41 ID:gnjAlXGF
>>71
一杯あるとおもうけど、それを聞いてどうすんだ?

73 :デフォルトの名無しさん:2017/01/21(土) 23:08:11.88 ID:sMDuy5hJ
>>72
どうするんだと言われてもね。

よくテストされてる汎用ライブラリを使いましょうという
当たり前のことしか言わないよ。

74 :デフォルトの名無しさん:2017/01/21(土) 23:12:54.46 ID:gnjAlXGF
えっ、話を逸らしただけ?

75 :デフォルトの名無しさん:2017/01/21(土) 23:16:13.67 ID:sMDuy5hJ
>>74
話をそらしたのはお前じゃね?
俺は>>68でちゃんと会話をしている。

それに対するお前のレスは中身が何もない。
中身が何もないお前にこれ以上何をいえと?

俺は話を>>68に戻しただけ。
わからないならここに>>68の内容を
コピペしてやっても良いんだぜ?

76 :デフォルトの名無しさん:2017/01/21(土) 23:21:02.28 ID:gnjAlXGF
>>75
ああ、そういうことか、sqliteがどんなテストコード書いてるか見たらprivateをpublicにするとか言えないと思うんだけど、すまんねその前提で言ってたわ

77 :デフォルトの名無しさん:2017/01/21(土) 23:23:43.91 ID:sMDuy5hJ
みんなsqliteのテストコード見なくていいぞw
どうせこいつが言ってるだけのことだから。

78 :デフォルトの名無しさん:2017/01/21(土) 23:36:56.46 ID:gnjAlXGF
まあ見なくて良いよ。普通のプロジェクトにとっては間違いなく過剰だから。
本体のソースコードの行数が122.9Kのところテストのコードとスクリプト含めて91596.1Kらしいから。
ちなみに内部でassertも大量に書いてる。

79 :デフォルトの名無しさん:2017/01/21(土) 23:41:58.25 ID:sMDuy5hJ
それが今までの話、
privateメソッドをテストしたくなったら
設計が悪いって話と何の関係があるのかな?

80 :デフォルトの名無しさん:2017/01/21(土) 23:43:42.51 ID:ij3ZsOnR
>>70

だから、定義してないから真偽定まらんと言ってるのだが。

>>59の主張を要約するとこうだな。

1. privateメソッドをテストしようと思ったら設計が良くない
2. テストできるようにするには2種類の方法がある
 a. 設計を見直してpublicにする
 b. 設計を見直さずにpublicにする
3. bではなくaにすべき

1.や3.に反論しようと思ったら設計が良い/まずいの定義に踏み込まざるを得ない。

81 :デフォルトの名無しさん:2017/01/21(土) 23:59:42.25 ID:gnjAlXGF
他人に使われるものを作ってるんだったら必要ないものまでpublicにする(外部に公開する)のは良くないよ。
なのでaもbもどっちもダメ

82 :デフォルトの名無しさん:2017/01/22(日) 01:41:32.45 ID:etjPL+qg
>>81
他人ってどういう意味?
その文脈で何故他人が出てくるの?

もしかしてpublicメソッドの話をしているのに、
一般用語のパブリック(大衆の、公共の、公衆の)と間違えちゃった?
だとしたら恥ずかしいね。

83 :デフォルトの名無しさん:2017/01/22(日) 04:45:25.75 ID:77/TNfJH
>>82
何故他人が出てきたらいけないの?
あなたは自分しか使わないものしか作らないの?

84 :デフォルトの名無しさん:2017/01/22(日) 05:34:13.73 ID:etjPL+qg
>>83
もしかして図星だった?
質問にちゃんと答えようね

もしかしてpublicメソッドの話をしているのに、
人間に対して使う用語ののパブリック(大衆の、公共の、公衆の)と間違えちゃった?

85 :デフォルトの名無しさん:2017/01/22(日) 05:37:05.25 ID:bK3k81d3
>>80
publicにしなくてもテストできるやろ

86 :デフォルトの名無しさん:2017/01/22(日) 07:00:17.67 ID:gigvK4EO
>>84
いや、間違えてないけど?

87 :デフォルトの名無しさん:2017/01/22(日) 07:12:24.26 ID:gigvK4EO
逆に聞きたいんだが、使う人を考えてクラス設計するのがそんなに不自然か?
意味不明な解釈してると決め付けるぐらいに

88 :デフォルトの名無しさん:2017/01/22(日) 07:13:16.92 ID:etjPL+qg
じゃあ自分しか使わないものは
全部privateにするわけね。

自分っていうのは人間の話ね。

89 :デフォルトの名無しさん:2017/01/22(日) 07:17:40.52 ID:gigvK4EO
>>88
自分しかつかわないなら好きにすればいいんじゃない?それこそ全部publicでも誰も文句言わない

90 :デフォルトの名無しさん:2017/01/24(火) 12:54:18.38 ID:QA0ZcG3O
自分しか使わないからprivateって、なんてクソな設計なんだろうw

91 :デフォルトの名無しさん:2017/01/24(火) 20:35:15.30 ID:dMWZcDP0
むかしオブジェクト指向システムの設計ってスレで
将棋の例を出して暴れてたやつにそっくりだなw

92 :デフォルトの名無しさん:2017/01/24(火) 21:30:19.03 ID:8U3NWpZ6
むしろ自分しか使わないならpublicでええやん

93 :デフォルトの名無しさん:2017/02/06(月) 23:15:46.42 ID:Z4T16Vvy
設計的な公開/非公開はpublic/privateで分ける
人に対しての公開/非公開はスコープで分ける

94 :デフォルトの名無しさん:2017/02/07(火) 08:52:53.46 ID:SRenyBWg
>>93
それって逆でもいいんじゃね?

95 :デフォルトの名無しさん:2017/02/07(火) 08:59:32.21 ID:ppv+uzEt
開発者が俺とお前の2人ならそれでも良いかもな

96 :デフォルトの名無しさん:2017/02/08(水) 01:47:58.35 ID:oZ8qLhDf
>>4

どれ、宿題を出しといてやるよ

動物が「バカ」だったときには「4」を返す
という仕様を実装漏れしていました。
なぜ漏れていることに気づけなかったんでしょうか?

あなたの実装漏れを知った顧客は、あなたの報告するカバレッジが100%であることに何の意味もないことを知り、あなたの報告に疑いを持つようになりました(ちゃんちゃん)

97 :デフォルトの名無しさん:2017/02/08(水) 03:00:48.24 ID:nBuIwUQ3
>>4じゃないけどさ
カバレッジ100%にしても実装漏れは検出できないって当たり前でしょ…

98 :デフォルトの名無しさん:2017/02/08(水) 03:33:50.20 ID:EqksEKaR
>>96
じゃあお前への宿題な

他の自動車に後ろから追突されたときはエアバッグは意味が無いことを知りました。
エアバッグによる安全性に意味が無いことを知り、あなたは安全装置をすべて外しました
そしてあなたはエアバッグで助かる事故で死にました(ちゃんちゃん)

99 :デフォルトの名無しさん:2017/02/08(水) 03:38:50.66 ID:EqksEKaR
馬鹿・・・カバレッジが100%ということはバグがないということだ
普通・・・カバレッジが100%ということはすべての行を実行する程度のテストはしているということだ。


馬鹿は銀の弾丸があると思っている。
馬鹿はカバレッジを完璧じゃないと言おうとしているつもりが
実は馬鹿のほうこそが過大評価している。

自分の間違った考え(カバレッジ100%は完璧)を自分でそれは間違いだって
ツッコミを入れているだけである。マッチポンプ

100 :デフォルトの名無しさん:2017/02/08(水) 03:39:18.59 ID:nBuIwUQ3
出題しろよ

101 :デフォルトの名無しさん:2017/02/08(水) 04:48:48.06 ID:q7Bk+Pyw
たかがC0のカバレッジ100%を特別なことだと思ってるバカって、>>4のことだよな?

102 :デフォルトの名無しさん:2017/02/08(水) 07:54:35.87 ID:oZ8qLhDf
>>98
>>99

なんだ。答えられないのか。おまえクビなw

103 :デフォルトの名無しさん:2017/02/08(水) 08:23:37.62 ID:J/owSyuZ
>>4の話でLookupTableクラスを分離するというのが「良い設計変更」だとして、じゃあそれを
使用するクラスの内部クラスにしたらその設計は良いままなのか、あるいは悪くなった
ことになるのか、って疑問はあるな。

104 :デフォルトの名無しさん:2017/02/08(水) 09:34:33.51 ID:3ajnzt+4
>>97
動物が増えてもテスト不要と言っちゃってる >>4 に言えよ

105 :デフォルトの名無しさん:2017/02/08(水) 10:58:26.85 ID:WP/XTf2I
>>4
> 動物が増えたら?などということを考える必要はない。
はたして、そうだろうか

> data = {人: 2, 犬: 4, 猿: 4, キジ: 2, 猫: 4}
"馬: 3"の追加が必要なのに、それを忘れていた場合にどうするんでしょうね

> テストはどうする? ・・・答えは "不要" だ。
残念、追加し忘れを見逃しましたね

> 元の設計のテストというのはデータが増えれば対応するテストを
> 増やすだけという単純作業
をやってれば、バグを検出できたのに

> なぜならばLookupTableのテストはすでに書いているからだ。
LootupTableのテストは書いていても、data定義(初期化)行はテストできてないね

106 :デフォルトの名無しさん:2017/02/08(水) 22:49:03.07 ID:EqksEKaR
>>105

> をやってれば、バグを検出できたのに
残念。それを忘れたらバグは検出できませんね

107 :デフォルトの名無しさん:2017/02/08(水) 23:29:11.39 ID:b6dR+iVQ
くだらないこと言ってないでコード書けってよく言われてるんだろうな。

108 :デフォルトの名無しさん:2017/02/09(木) 00:22:21.28 ID:lnTHGhne
>>106
この場合は忘れてもカバレッジが教えてくれるだけマシだったんじゃない?コードの見やすさは知らんけど

109 :デフォルトの名無しさん:2017/02/09(木) 06:51:39.40 ID:IOSaScxB
>>106
テスト設計しないんですか?

110 :デフォルトの名無しさん:2017/02/09(木) 13:02:15.28 ID:dfCX7ZDm
>>106
テストが不要だということの反論に対して、テストを忘れたらバグを検出できないとか言われても困惑するのみ

111 :デフォルトの名無しさん:2017/02/09(木) 17:06:47.27 ID:EPpoXydB
> data = {人: 2, 犬: 4, 猿: 4, キジ: 2, 猫: 4}
こんな増えてくと予想できるリストなんかは外部ファイルにしとけよ
後は必要なら勝手にファイルに追加してねって責任を誰かに丸投げできれば重畳
テストもそいつに丸投げできる

112 :デフォルトの名無しさん:2017/02/09(木) 21:32:56.16 ID:l61bzEJu
テストしにくいコードを書くのがおかしい。

113 :デフォルトの名無しさん:2017/02/09(木) 21:39:55.38 ID:UTxumv29
残念ながら世間ではおかしいことがまかり通っててそれを修正する必要がある。

114 :デフォルトの名無しさん:2017/02/09(木) 22:37:41.43 ID:V+qaSj6I
テストし易い部分のコードなんて誰でも書ける

115 :デフォルトの名無しさん:2017/02/10(金) 00:43:43.40 ID:/WxwB06L
>>114
矛盾

116 :デフォルトの名無しさん:2017/02/10(金) 14:03:12.42 ID:0nwBBEN6
コードを選ぶようなテストフレームワークが悪い

117 :デフォルトの名無しさん:2017/02/10(金) 19:11:46.63 ID:+HewTgrG
じゃあ作ろっか

118 :デフォルトの名無しさん:2017/02/15(水) 20:12:18.71 ID:rWNVJqHz
>>115
矛盾というかジレンマですな。

119 :デフォルトの名無しさん:2017/02/17(金) 01:13:32.33 ID:ZnfoQYBi
要件や設計に書いてあることをただ満たせばいいのに、
何だテストしにくいコードって。

120 :デフォルトの名無しさん:2017/02/17(金) 01:34:44.39 ID:EzDq9nSn
>>119
自動テストができないコード
自動テストをやろうとしたら組合せ爆発を起こして
時間がかかりすぎるコードだよ

121 :デフォルトの名無しさん:2017/02/17(金) 04:11:34.18 ID:cVLy1vhF
>>119
ばーか

122 :デフォルトの名無しさん:2017/02/17(金) 08:05:23.30 ID:LsFaYFdt
>>119みたいなマがいるから困る

後々の工程や運用段階でバグが見つかっても
困るのはオレじゃないから、とか考えてるんだろうな

123 :デフォルトの名無しさん:2017/02/17(金) 10:14:12.44 ID:rxbbpEDv
>>119 はいきなりシステムテストレベルを行う人間なんだろうね。

それだと小さいバグ、作り上の問題に気づかない。

124 :デフォルトの名無しさん:2017/02/22(水) 13:30:52.81 ID:nFPUHBlJ
>>120
組み合わせ爆発は、自動テストが原因じゃないよね。
逆に組み合わせ多数でマニュアルだと時間がかかりすぎて繰り返し実行できないなら、
自動テスト化を考えたほうが良い。

125 :デフォルトの名無しさん:2017/02/22(水) 20:23:22.44 ID:Ameqiwj8
自動テスト使って開発したこと無いだろお前
組み合わせが多過ぎるなら組み合わせが減るようにバラすのが先だわ

126 :デフォルトの名無しさん:2017/02/23(木) 10:38:26.31 ID:5OVH7aZj
>>125
全組み合わせだと1億通りなのを、オールペア法や直交表で100通りくらいまでに減らすのは基本
さらにその100通りをマニュアルで実行すると時間がかかるのなら、自動化すべき
ということだよ

組み合わせ爆発は、自動テストが原因じゃない

とか、こんな説明書くの疲れるわー

127 :デフォルトの名無しさん:2017/02/23(木) 14:42:20.90 ID:iUfvCfTM
やっぱり分かってねえ…
テスト技法の前に設計を何とかしろ

128 :デフォルトの名無しさん:2017/02/23(木) 14:59:39.53 ID:5OVH7aZj
>>127
あのねぇ・・・
俺は>>120の内容が間違ってると言いたいのだよ・・・
糞設計が原因のテスト困難性の話なんかしてないわ・・・

129 :デフォルトの名無しさん:2017/02/23(木) 15:11:55.49 ID:sZtROie8
>>128
ほっとけよ、どうせprivateをpublicにするとか言ってた奴だろ
相手を解ってない事にして見下したいだけのやつだよ

130 :デフォルトの名無しさん:2017/02/23(木) 18:15:47.32 ID:eyTAmQSH
今時、1億通りぐらいで自動化できないとか、どれだけヘッポコなんだろw

131 :デフォルトの名無しさん:2017/02/23(木) 20:44:47.41 ID:4lIYYkyp
ぼこぼこにされた>>119が噛み付いて回るスレをお楽しみください

132 :デフォルトの名無しさん:2017/02/25(土) 11:41:05.47 ID:7KoBIFTE
どうした?力技でテストすればいいんじゃないのか?w

133 :デフォルトの名無しさん:2017/04/01(土) 03:45:16.63 ID:I0+wrTCp
お前らGUIは自動テストしてんの?

134 :デフォルトの名無しさん:2017/04/01(土) 11:09:14.09 ID:tny4BO7D
>>133
最低限

135 :デフォルトの名無しさん:2017/04/01(土) 16:27:50.44 ID:Hg380gii
>>133
現状人の見た目でしか判断できないのは仕方ないとして、(表示されている写真の人物が最盛期の西条秀樹に間違いないとか)
GUI の状態取得関数やプロパティなんかで得られる情報ならその情報を確認できたらそれが表示できているとしてテストを組んでる。
例えばあるテキストボックスの文字色が赤というテストなら文字色プロパティが赤になっているのを確認するとか。

GUI ライブラリ自体はテストされているという前提なのでそのバグに遭遇しない限りは問題ないはず。
(稀によく遭遇するけどテスト過程で原因は判りやすいから GUI ライブラリ側に報告もできるしこちらも回避はできる)

GUI の表示ライブラリそのものを作ってるとしたらまた話は別だけど。頑張って死んでくれ。

ところで、テストコードを自動で書いてくれる便利ツール、おまえらなら何か知ってるんだろ? 教えてくれ。言語や手段は問わない。ヒントになればいい。

136 :デフォルトの名無しさん:2017/04/09(日) 02:20:28.91 ID:BJMv2zza
>>108
テスト不要だ(キリッ 君はこれに答えろよカス

137 :デフォルトの名無しさん:2017/04/09(日) 08:57:33.00 ID:Jztab8MH
実装コードの複雑度の客観的判定のお供に
SonarQube

設計のおすすめ書
組み込みソフトウェア開発のためのオブジェクト志向モデリング

あなたの書いたメソッドはテスト以前に単一機能の原則にマッチしていますか?テストが困難という事は設計が(ry

138 :デフォルトの名無しさん:2017/04/17(月) 08:55:18.58 ID:R62eo4r3
>>136
なんか人違いしてる気がするがテスト不要といってる奴と別人だよ。

>data = {人: 2, 犬: 4, 猿: 4, キジ: 2, 猫: 4}
とする設計より一つずつifで書いた方がテスト忘れてもカバレッジが教えてくれるから(コードの見やすさは別として)マシだったんじゃない?って意味だよ

139 :デフォルトの名無しさん:2017/04/22(土) 15:10:55.24 ID:+6/27O61
自分の管理下にない外部サービスへのログインなどの処理を行うライブラリのテストを行いたいんだけれども, ログインパスワードとかの情報ってどうやって被テスト対象に渡すべき?

140 :デフォルトの名無しさん:2017/04/22(土) 15:11:12.35 ID:+6/27O61
age忘れ

141 :デフォルトの名無しさん:2017/04/22(土) 15:22:45.81 ID:fNu+0xzW
>>138
どちらもカバレッジで教えてくれる。

1つのコード、1つのテストで、カバレッジを100%にするのも
同じ処理を複雑に書いて
100のコード、100のテストでカバレッジを100%にするのも
カバレッジ自体は同じだ。何も違いはない。


ただ、後者は面倒ってだけ。
書くものが増えれば増えるほど、ミスも増えるし
読むものも増える

142 :デフォルトの名無しさん:2017/04/22(土) 15:27:46.13 ID:fNu+0xzW
>>139
外部サービスがログイン機能を正しく実装しているかっていうのは
外部サービスがテストをするべき所で、あんたがテストするところじゃない。

あんたがテストするならば、その外部サービスに対して
想定通りのパラメータを正しく送ったかどうかをテストする。

この時、実際には外部サービスは使わない。外部サービスのふりした
何か(モック)を代わりに使う。

143 :デフォルトの名無しさん:2017/04/22(土) 16:01:54.72 ID:+6/27O61
>>142
やっぱりモックか・・・・・・
ありがとう

144 :デフォルトの名無しさん:2017/04/22(土) 18:03:53.80 ID:NysYFg8M
>>141
だから
>data = {人: 2, 犬: 4, 猿: 4, キジ: 2, 猫: 4}
という設計だと猪:4というのを追加したあとテスト忘れてもカバレッジ変わらないでしょ
ifだったらカバレッジ下がる。それだけの話だよ。

145 :デフォルトの名無しさん:2017/04/22(土) 18:12:37.60 ID:fNu+0xzW
>>144
なんでカバレッジが変わる必要があるのかわからんのだが?

あんたは猪4が追加されたらカバレッジが減ってほしいと思ってるわけだよね?
それは追加した猪4に対するテストコードを書くべきだって考えてるからだよね?

では、このコードの時、追加した猪4に対するテストはどうなるわけさ?
それ以外のテストはすでに書いてあるという前提なので、
追加した猪4だけのテストはどうなるのかを答えて。

そのあとそのテストをやる意味はどれくらいあるかって話をするからさ
テストを書く時間(将来的にはメンテする時間)にだってコストは掛かるんだぜ?

146 :デフォルトの名無しさん:2017/04/22(土) 18:14:57.22 ID:NysYFg8M
>>141
そもそも、一つのテストでカバレッジ100%になったとしても、入力による結果が100種類あるなら100個テスト書かなければテストの意味がないというのは理解してる?

147 :デフォルトの名無しさん:2017/04/22(土) 18:17:51.06 ID:fNu+0xzW
>>146
例えば、atoiの場合、結果は32bitCPUの場合で
4294967296種類(半分だっけ?)あるけど、
その場合のテストの数は?

148 :デフォルトの名無しさん:2017/04/22(土) 18:38:08.34 ID:NysYFg8M
>>147
そういう場合俺なら仕様を読んで、正数、負数、返す値の最小値、最大値付近とオーバーした場合、数字以外を含む、空文字、空白を付けた場合などのパターンを書くね。

心配ならintの最小値から最大値までを変換後、文字列に逆変換して文字列に戻したものが一致するかどうかのテストも書くかもね

149 :デフォルトの名無しさん:2017/04/22(土) 18:38:24.70 ID:+5rvIbLJ
>>147
横からだけど、atoi の場合は基本はそうだよ
でもそんなのやりきれないから境界値とか工夫するのが普通。

猪の件はどういう主張なの?

assert( numberOfFeet(人) == 2 )
assert( numberOfFeet(猿) == 4 )
assert( numberOfFeet(猫) == 4 )
assert( numberOfFeet(猪) == 4 )

みたいに増やす以外に良い方法があるってこと?

150 :デフォルトの名無しさん:2017/04/22(土) 18:44:04.84 ID:fNu+0xzW
>>149
やりきれないとやりきれるの境目はどこ?
100個? 1000個? 1万個?
やれるなら、やれるところまでやるべきだって話なんだよね?


俺はテストする価値が無いなら、テストしない。
テストを減らすために、猪を増やした所で
テストする価値がないコードになるようにする

151 :デフォルトの名無しさん:2017/04/22(土) 18:45:03.59 ID:NysYFg8M
カバレッジ100%を目的にテスト書くんじゃなくて仕様を満たしているかを確認するためにテスト書くんだよ。
そんな考えだからintの数値の範囲のみテストするような発想になるんだ。

152 :デフォルトの名無しさん:2017/04/22(土) 18:45:14.22 ID:fNu+0xzW
>>149
> みたいに増やす以外に良い方法があるってこと?
ある。ずっと上の方に書いたはずだがね

153 :デフォルトの名無しさん:2017/04/22(土) 18:46:19.44 ID:fNu+0xzW
>>151
そんな当たり前のことを言われても・・・

仕様を満たしているかを確認する時の
テストの数を減らせるように
コードを工夫するって話をしてるのに

一歩前にもどるなよw

154 :デフォルトの名無しさん:2017/04/22(土) 18:48:30.81 ID:NysYFg8M
>>153
猪渡したら4を返すという仕様が追加されてもテスト不要って言ってるんじゃ無かったの

155 :デフォルトの名無しさん:2017/04/22(土) 18:51:23.30 ID:IUEn1/Ee
>>153
横からだけどそれはおかしいなぁ
テストって設計書から作成するもんでその数がコードの書き方で増減するのは基本的にはおかしい

156 :デフォルトの名無しさん:2017/04/22(土) 18:53:59.52 ID:fNu+0xzW
>>154
境界値はテストするが、その間は
テストする価値がないからテストを書かないんだろ?

猪渡したら4を返すという仕様であっても、

工夫(仕様や処理を互換性がある別の形に変更)することで
テストを書く価値がないコード(猪を追加する前のテストコードだけで十分)に
することができる。

境界値のような特異なデータである猪を
境界値の間のような無害なデータにすることで
テストする価値がなくなり、テストが不要になる。

157 :デフォルトの名無しさん:2017/04/22(土) 18:58:04.29 ID:fNu+0xzW
>>155
全然おかしくない。

設計書にコードに記述されていることに全てが書かれていれば
その理屈は正しいかもしれないが、実際には設計書には
コードに書かれていることの一部分しか書かれていないから。

つまり設計書に書かれていない部分に対するテストの数は増減する

158 :デフォルトの名無しさん:2017/04/22(土) 18:58:29.29 ID:NysYFg8M
>>156
仕様は猪を渡したら4を返す筈が実装を間違えて1と返ってくるバグ仕込んだ場合テストコードの追加無しに検出出来るの?

159 :デフォルトの名無しさん:2017/04/22(土) 19:09:08.07 ID:fNu+0xzW
>>158
できる。

あとはテストする価値があるかどうかって話になって
俺はテストする価値が無いと思うだろうからテストは書かない。

あんたは境界値の間の値のような、
17を入れたら289が返ってくるはずが実装を間違えて
300と返ってくるバグを仕込んだ場合のテストコードを書くといいさ。

160 :デフォルトの名無しさん:2017/04/22(土) 19:18:21.00 ID:NysYFg8M
>>159
じゃあどうやるんだよってのが皆の疑問だと思うんだが。

猪が境界値の間の値という主張もどうかと思うが、
場合によっては間のテストも書くと >>148 に書いたよ

161 :デフォルトの名無しさん:2017/04/22(土) 19:39:48.14 ID:NysYFg8M
例えば仕様が動物の名前を与えたら足の数を返す
という曖昧なものであれば猪のテストは追加しないかもしれない。
しかし実際にそんな仕様のコードを書くのは不可能なので、仕様が粗雑ならテストコードも粗雑になるのは必然

仕様がとある動物データ内で定義されている足の数が返る
というのであればその動物データを読み込んでデータと関数の返す値が一致するかをテストするだろう。

同様に仕様に猪を与えたら4を返すとあればそういうテストを書くのが当たり前

162 :デフォルトの名無しさん:2017/04/22(土) 19:55:16.77 ID:M051jVFH
>>155
テストの目的によってちげーよばか

163 :デフォルトの名無しさん:2017/04/22(土) 20:09:40.40 ID:fNu+0xzW
>>161
> 同様に仕様に猪を与えたら4を返すとあればそういうテストを書くのが当たり前

お前の提唱するシステム開発では、
仕様書を作る人は、全ての動物の足の数を仕様書として書く間抜けで
その仕様書に則って開発する人は、何の疑いもなく書かれている通りにテストを書くのだろう?
素人が仕様書を書いて、考える頭がないやつが開発する。
コストがかかるのはそのためだ。


境界値の間のテストを書きたいなら書けばいいさ?

var data = {"人": 2, "猿":2, "猫": 4, "猪": 4}
assert(data["猪"] == 4) というテストに価値があると思うならな

164 :デフォルトの名無しさん:2017/04/22(土) 20:11:19.43 ID:fNu+0xzW
訂正w

var data = {"人": 2, "猿":4, "猫": 4, "猪": 4}

165 :デフォルトの名無しさん:2017/04/22(土) 20:19:28.83 ID:NysYFg8M
>>163
全ての動物の足の数が必要とは誰も言ってないんだけど?

166 :デフォルトの名無しさん:2017/04/22(土) 20:30:59.51 ID:2QNaIclJ
さすがにこの粒度でテストするのは意味ないだろw
二重メンテになるだけだわw

167 :デフォルトの名無しさん:2017/04/22(土) 20:33:10.67 ID:MfkHEDxl
君たち何のためにテストしてるの?何を保証したいの?

168 :デフォルトの名無しさん:2017/04/22(土) 20:47:55.86 ID:IUEn1/Ee
>>167
要求仕様書だよね

169 :デフォルトの名無しさん:2017/04/22(土) 21:05:33.81 ID:MfkHEDxl
>>168
君は覚えたての言葉を垂れ流すのをやめなさい

170 :デフォルトの名無しさん:2017/04/22(土) 22:37:37.83 ID:x8LqAlRP
{"人": 2} これを、{"入": 2} 書いてもエラーにならないから、確かめる必要がある。
特にハイフンなどは、何種類もあるから危険。
全角空白・半角空白も

テストせずに、こういうので、ずっと出来ないって言ってる、香具師が多い

171 :デフォルトの名無しさん:2017/04/23(日) 00:17:24.66 ID:CU9TQkMq
カバレッジ100%にする事しか頭にない実装してからテストコード書くようなやつなんだろうね。

172 :デフォルトの名無しさん:2017/04/23(日) 00:34:16.87 ID:CU9TQkMq
>>167
自分が決めたもしくは他人に決められた仕様を満たしている事の確認のためにテストを書いてる。
けっして全てのコードパスを通すためではないよ。
ID:fNu+0xzW がテストでどんなバリデーション書くのか興味あるね。

173 :デフォルトの名無しさん:2017/04/23(日) 05:12:33.31 ID:vNB+3Vut
>>166
そう思う人は産業用ロボットなど高信頼性が求められるソフトウェア開発には参加しないでくださいね。
そういう手抜きで人が死ぬから。

174 :デフォルトの名無しさん:2017/04/23(日) 12:27:10.81 ID:T4INally
>>166
そういうことだよねw

こういうコードがあって
var data = {"人": 2, "猿":2, "猫": 4, "猪": 4}

テストで
var expected = {"人": 2, "猿":2, "猫": 4, "猪": 4}
assertDeep(data, expected)
こういうテストを書くことに、どれだけの意味があるかって話だよ


今までそういう話じゃなかったって?
そうだね。今まではnumberOfFeetの話だった。
しかし、numberOfFeetの部分は他のdataですでにテスト済みとする。

そうすれば残り部分は、dataだけになる。だからdataが変わったのであれば
そのdataの変化分だけをテストすれば良い。それがこのテスト

>>172
> 自分が決めたもしくは他人に決められた仕様を満たしている事の確認のためにテストを書いてる。
他人もしくは自分が、境界値以外のどうでもいい値の仕様を書いたとしたらその値をテストすんの?
「(全ての)数値が二乗される関数であることと」と書いてあったら、
すべての数値をテストすんの?

175 :デフォルトの名無しさん:2017/04/23(日) 12:41:28.59 ID:vNB+3Vut
>>174
コード上の境界値だけテストすれば十分だと思ってるの?
こわいなあ

176 :デフォルトの名無しさん:2017/04/23(日) 12:49:38.51 ID:dTVl8E15
どれだけテストすれば良いかは決まっているものでも、個人の感覚によるものでもありません
ターゲットとするソフトの目的や性質を踏まえて設計するものです
これをテスト仕様設計と言います

177 :デフォルトの名無しさん:2017/04/23(日) 13:00:51.62 ID:HqNmAyPa
でもやっぱり仕様書で猪4が追加されてる以上テストはやりたいね

178 :デフォルトの名無しさん:2017/04/23(日) 13:01:58.16 ID:T4INally
>>177

> こういうコードがあって
> var data = {"人": 2, "猿":2, "猫": 4, "猪": 4}
>
> テストで
> var expected = {"人": 2, "猿":2, "猫": 4, "猪": 4}
> assertDeep(data, expected)
> こういうテストを書くことに、どれだけの意味があるかって話だよ

179 :デフォルトの名無しさん:2017/04/23(日) 13:06:57.77 ID:zjYzndui
テストするならせめてもう一つ外側とかかな。
例えば履物が合計何個必要かとかを計算する関数のテストとかね。

get_sum_feet( animal_list )
のテストとか。

180 :デフォルトの名無しさん:2017/04/23(日) 13:07:29.19 ID:T4INally
>>176
> これをテスト仕様設計と言います

そのテスト仕様設計書に、
「(全ての)数値が二乗される関数であることと」と書いてあったり、
いかにも境界値でも、その前後でも、なんでもない普通の値が書いてあったら
どうするの?って話。

書いた本人は実装がわからない(この時点では実装が存在しない)から、
それが重要な値だって思ってテスト仕様書に書いたかもしれないが、
実装によっては重要でも何でもない値にできるかもしれないだろう?

実装を考えずに無駄のないテスト仕様書を書くのは不可能なんだよ。

181 :デフォルトの名無しさん:2017/04/23(日) 13:10:00.47 ID:HqNmAyPa
単体はともかく結合あたりじゃ
仕様書を満たすテストが主でしょ?

182 :デフォルトの名無しさん:2017/04/23(日) 13:13:22.57 ID:T4INally
>>179
なかなか興味深い例をだすねw

では

numberOfFeet(animal)
get_sum_feet( animal_list )

の2つがあって,numberOfFeetのテストが猪の対応も含めてちゃんと書かれているとする。
この時、get_sum_feetのanimal_listに猪が含まれている場合のテストは必要ですか?不要ですか?
ただし実装の内容は決めません。



(俺がこの例で本当に言いたいことは、これは実装を決めなければ
 テストが必要かどうかがわからない例であるという事ねw)

183 :デフォルトの名無しさん:2017/04/23(日) 13:22:31.14 ID:HqNmAyPa
>>182
だから単体はともかく結合じゃいるよ

184 :デフォルトの名無しさん:2017/04/23(日) 13:25:47.82 ID:T4INally
>>181
つまり仕様書から作るテストは正しく動くためのテストではなく、
単に仕様書から思いついたテスト(足りない物はあるし、意味のないものもある)
って話だよね?

では残りのテストはどこで作成するのか?
そして意味のないテストを、これからもやり続けたいのか?
という話が残る。

185 :デフォルトの名無しさん:2017/04/23(日) 13:26:23.30 ID:T4INally
>>183
それでは、単体で行えるテストを
結合でもやる理由は何?

186 :デフォルトの名無しさん:2017/04/23(日) 13:36:28.74 ID:zjYzndui
なるほど、そもそもテストの目的が違うわけだ。
品質を上げたいというよりかは
SIer から文句を言われないためのテストが必要だと。
それなら言われた通りに頭使わずに、
くだらないコードでもなんでもテストするのが正しいと思うよ。

187 :デフォルトの名無しさん:2017/04/23(日) 14:06:33.31 ID:vNB+3Vut
>>180
せめてブラックボックステストとホワイトボックステストぐらい理解してから出直してきな

188 :デフォルトの名無しさん:2017/04/23(日) 14:09:16.82 ID:HqNmAyPa
>>185
結合はお客さんが出してきた仕様書通りに動いてますよっていう保証だから
(会社によってはシステムテストだったり粒度は異なるが)
猪4って仕様があったならそれがPGにとってくだらんテストであるかどうかなんて関係ない

189 :デフォルトの名無しさん:2017/04/23(日) 14:51:57.18 ID:T4INally
>>187
ブラックボックステストはコストがかかる割に
正確なテストが出来ないという話でOK?

190 :デフォルトの名無しさん:2017/04/23(日) 15:11:21.31 ID:T4INally
ここまでのまとめ

numberOfFeet(animal)
get_sum_feet( animal_list )

は仕様書で決めることで、仕様書も、テスト仕様書もお客さんが決めることである。
当然ながらテスト仕様書の量に応じてお客さんがテスト作業費を支払う義務がある。

ということらしい

191 :デフォルトの名無しさん:2017/04/23(日) 15:12:20.42 ID:T4INally
ちょっと訂正

は仕様書で決めることで、仕様書も、テスト仕様書もお客さんが作成するものである。

192 :デフォルトの名無しさん:2017/04/23(日) 16:02:32.57 ID:CU9TQkMq
>>174
全ての数値が二乗される関数であること の意味が解らんが
リストで渡した数値全てが2乗されて返る関数ってことかな?
テストしない理由がないな

193 :デフォルトの名無しさん:2017/04/23(日) 16:12:02.25 ID:T4INally
うむ、なるほど理解した。

1. 仕様書を満たすテストコード
2. テスト仕様書を満たすテストコード
この2つは別のものなのだ

例えば、仕様書には「すべての数値を二乗する処理」と書くだろう。
2を4に、3を9に、4を16に、・・・・にする処理。と全ての値を書くバカはいない。

そしてテスト仕様書には「2を4にする」などと特定の値のテストを書くだろう
2を4に、3を9に、4を16に、・・・・になることを確認する。と全ての値を書くバカはいないし
すべての値のテストを行うことと書くバカもいない(テストの量に応じてコストが大きく変わるため)

つまり、仕様書の内容とテスト仕様書の内容は一致しないということだ。
仕様を決めたからと言って、それがそのままテスト仕様書に書く内容になるわけではないのだ。
そこが勘違いしている点の一つだな。

テスト仕様書は別途書き起こさないといけない。そのテスト仕様書を書くのは客の仕事だ。
そしてテスト仕様書を満たすテストを行う(テストコードを書く場合もある)のは開発会社だが、
その費用はテスト仕様書の量に応じて客に請求するものとなる。
(俺の会社ではテスト仕様書の量が膨大でも固定の金額でテストするというのならどうぞ勝手にしてくれw)

テスト仕様書に書かれているテストは作業量をもらっている以上やるべきことだが、
テスト仕様書に書いてあるテストをパスしていたとしても、
仕様書の内容を満たしていなければ客は怒るだろう。それが仕様なのだから。

問題はここだな。テスト仕様書を満たすテストコードではなく仕様書を満たすテストコード。
仕様書には書かれているが、テスト仕様書には書かれていない値 に対するテストだ。

テスト仕様書には書かれていないのだから、その部分の仕様を満たすためのテストはどう書いてもよかろう?
話を戻すとこの仕様書のみに書かれている内容に対するテストの量は実装によって変わってくるという話だったわけだ。

194 :デフォルトの名無しさん:2017/04/23(日) 16:14:39.12 ID:T4INally
>>192
「引数で渡した数値が二乗されて帰ってくる関数」って意味だよ。

あとは>>193で書いたとおり。
仕様書の内容が、そのままテスト仕様書になるわけではない。

195 :デフォルトの名無しさん:2017/04/23(日) 16:16:02.47 ID:CU9TQkMq
>>174
あと、せっかく他人が >>149
assert( numberOfFeet(人) == 2 )
assert( numberOfFeet(猿) == 4 )
assert( numberOfFeet(猫) == 4 )
assert( numberOfFeet(猪) == 4 )
とnumberOfFeetの実装方法に依らないテストコードを書いてくれてるのに、
なぜ馬鹿みたいなテストコードを自分で書いて自分で批判してんの?

196 :デフォルトの名無しさん:2017/04/23(日) 16:17:28.41 ID:T4INally
補足

「引数で渡した数値が二乗されて帰ってくる関数」って意味だよ。
だから、テストするしないは別として引数として取りうる数値の数(32bitで2^32乗個)
だけテストケースは存在しうる。
その全てをテストしないでしょ?

だから仕様書に書かれた内容が、テスト仕様書の内容になるわけじゃない。

どっかの誰かは仕様書に猪が追加されたら、
テスト仕様書にも追加すべきだって言っているようだがね。

197 :デフォルトの名無しさん:2017/04/23(日) 16:19:01.35 ID:T4INally
>>195
それは実装方法には依らないが
テストする価値が殆ど無いコストがかかるだけの
テストコードだって話をしてる

198 :デフォルトの名無しさん:2017/04/23(日) 16:29:27.79 ID:CU9TQkMq
>>196
つまりお前は仕様として明示的に追加された”猪”が数値に置き換えると明示的に指定もされていない一つの数と重要度は同等であるという主張なわけな。
まぁ、それはそれでめんどくさいので置いておくとして、
numberOfFeet(猪)
が仕様からはずれた4を返す以外の結果が発生する場合に正しくテストがエラーとなるテストコードはどう書くんだい?仕様が追加されたときにテスト追加しなくても検出出来るって言ったよね?

199 :デフォルトの名無しさん:2017/04/23(日) 16:43:56.84 ID:T4INally
>>198
人の話をちゃんと聞け

まずテストする価値が殆どないコストがかかるだけのテストコードを
書く意味があるのか?って話をしている。

> numberOfFeet(猪)が仕様からはずれた4を返す以外の結果が発生する場合に
> 正しくテストがエラーとなるテストコードはどう書くんだい?

こう書けばいい

 実装コード(の一部)
 var data = {"人": 2, "猿":2, "猫": 4, "猪": 6}

 テストコード
 var expected = {"人": 2, "猿":2, "猫": 4, "猪": 4}
 assertDeep(data, expected)

実装コードが間違ってる場合に正しくエラーになるぞ。

これはdataの内容だけしかテストしてないと言いたくなるかもしれないが、
それ以外の部分はダミーのdataを使って正しくテストしている(という前提)
変わるのはdataの内容だけなのだから、テストコードを書くとしたらdataの内容のみのテストだけでいい。

そして、こんなテストコードを書くのにどれだけの価値があるのか?って話
だってdataのデータを修正して、テストコードのexpectedにそれをコピペするだけだろ?
追加するたびに、二箇所にある同じデータを同じようにメンテするだけの作業

俺はそんなのをやる意味がないと思っているから、dataの内容以外のテストだけで十分
だからdataの内容が変わるだけならば、新たにテストを追加する必要はないと言っている。

200 :デフォルトの名無しさん:2017/04/23(日) 16:55:48.18 ID:CU9TQkMq
>>199
え?テスト追加してるじゃん?追加なしに検出出来るんじゃなかったの?

仕様から導き出される実装がとても簡単だったから仕様を満たしているか確認するテストは面倒なので勝手に省きます! って事か。
お前は何の為にテスト書いてんの?

201 :デフォルトの名無しさん:2017/04/24(月) 03:20:47.13 ID:m96WuHeG
>>199

> テストコード
> var expected = {"人": 2, "猿":2, "猫": 4, "猪": 4}
> assertDeep(data, expected)

テストコード書く能力ひくすぎだろこれ

202 :デフォルトの名無しさん:2017/04/24(月) 03:30:19.46 ID:wWNCwbd3
>>201
しかもそれ、numberOfFeetが仕様を満たしているかかくに

203 :デフォルトの名無しさん:2017/04/24(月) 03:34:16.30 ID:wWNCwbd3
ミスで途中送信

numberOfFeetが仕様通りか確認するテストでは無いんだよなぁ。自分で無意味なテストを書いて無意味だからやらない!とか何のギャグなんだかね。

204 :デフォルトの名無しさん:2017/04/24(月) 10:54:24.52 ID:yA6lKxwP
>> var data = {"人": 2, "猿":2, "猫": 4, "猪": 4}
みたいなハードコーディングするということは、要求される場合の数が非常に限定されている場合で、
その場合は全てテストする必要がある。

要求される場合の数が多い場合は、ハードコーディングなんかはしないわけで、上の議論は不毛な議論と言える。

205 :デフォルトの名無しさん:2017/04/24(月) 19:40:16.07 ID:mp0MXc0B
>>189
ちがうわ、ばーか
おまえテスト語る資格ねえよ

206 :デフォルトの名無しさん:2017/04/24(月) 19:41:54.95 ID:mp0MXc0B
ID:T4INally のバカっぷりに笑った

207 :デフォルトの名無しさん:2017/04/24(月) 20:51:36.29 ID:F9wVgoXI
よく2行のテストコードでこれだけ話を続けられるもんだ

208 :デフォルトの名無しさん:2017/04/24(月) 21:33:08.94 ID:Fbyj+dPJ
基本的に俺らの仕事が要件定義から始まってるってことを忘れたような議論をするやつがいるな

209 :デフォルトの名無しさん:2017/04/24(月) 21:50:46.18 ID:p282pyvh
では要件定義と絡んだテストコードの話でもしたらどう?

210 :デフォルトの名無しさん:2017/04/30(日) 21:35:11.55 ID:97yIE6oD
>>209
業務系のは要件と、要件を満たすための仕様がふらつくんで厳しいかもしんね
できんこたないけどUI層からのぶっ叩き(Selenium/Capybara/UI Automationなど)のほうが楽だと思う

UIの変更がなければ動く(はずだ)し、動かないならバグでそ

211 :デフォルトの名無しさん:2017/04/30(日) 21:43:02.05 ID:97yIE6oD
DHH vs ケント・ベックの対談を見て以降

ユニットテスト =
UI層を迂回して最上位のクラスのメソッドを蹴れるようにしておき
必要な時に簡単な引数を突っ込んでメソッドを流し動作確認を取ること

というやりかたしかしなくなった(境界値とか直行表とかマトリクスとかはやらなくなった)

212 :デフォルトの名無しさん:2017/05/30(火) 07:39:30.24 ID:tcgshfvu
ユニットテストで自動化して工数削減できるぜってインタフェースのブラックボックステストしかしなくなったんだが、そりゃホワイトボックステスト省いてるんだから工数減るわ

213 :デフォルトの名無しさん:2017/05/30(火) 08:29:25.36 ID:gC8biGup
>>212
お前のユニットテストはホワイトボックステストじゃないのかwww

214 :デフォルトの名無しさん:2017/05/30(火) 12:24:46.53 ID:9ZZJz22F
>>213←こういう馬鹿が本当に多い
実にお前ららしいけど

215 :デフォルトの名無しさん:2017/05/30(火) 12:33:01.37 ID:gC8biGup
>>214
どうも日本語に問題があるようだね

216 :デフォルトの名無しさん:2017/05/30(火) 12:48:54.29 ID:8S4zHXFC
>>215
ブラックボックステスト/ホワイトボックステストを勘違いしてる人は多い

217 :デフォルトの名無しさん:2017/05/30(火) 12:51:18.84 ID:k8jJr/2T
>>216
恥ずかしいよね

218 :デフォルトの名無しさん:2017/05/30(火) 15:51:07.38 ID:o/ByAjuM
>>213
「お前のユニットテストはホワイトボックステストじゃないのかwww」

この文は受け手によって以下のどちらにも解釈できるんだよな

1. それはユニットテストといいつつ実質ホワイトボックステストだろ(ユニットテストをホワイトボックスの代わりにするな)
2. (俺はユニットテストをホワイトボックスの代わりに用いるんだが)お前のそれはホワイトボックスではないのか?

ID:gC8biGup が平均的な主張をしていると信じるなら 1. だが、
お前が平均的な主張をしているというソースはないし、受け手でどうとでも解釈できる
人の日本語の問題を指摘する前に、どちらとも受け取れるような日本語使うなよ

219 :デフォルトの名無しさん:2017/05/30(火) 16:47:05.54 ID:8S4zHXFC
>>218
ブラックボックステストとホワイトボックステストという区別はテスト入力値の抽出の観点であって、試験対象の粒度の観点であるユニットテストとは独立した観点。
だから、ユニットテストの代わりにホワイトボックステストをするというのは用語として意味が通らない。

で、普通はユニットテストはソースコードを見れる状態でやるから、大抵はホワイトボックステストをやってる。
むしろユニットテストでブラックボックステストをする方が手間がかかる。

220 :デフォルトの名無しさん:2017/05/30(火) 18:06:05.35 ID:LPiGbjps
>>219
メソッド単位で仕様がカッチリ決まっているほど細かな仕様や設計ならブラックボックスなユニットテストもありえるけど、まあ巷で普通にやられているのはホワイトボックスなユニットテストだわな。

221 :デフォルトの名無しさん:2017/05/30(火) 19:38:53.29 ID:YXdrraWU
ユニットテストならカバレージぐらいはとるしブラックボックステストなんてありえんやろ

222 :デフォルトの名無しさん:2017/05/30(火) 19:47:36.13 ID:k8jJr/2T
>>218
1はあり得ないだろ

223 :デフォルトの名無しさん:2017/05/30(火) 20:29:35.35 ID:o/ByAjuM
>>219
独立した概念だからこそ、 1. も 2. もどちらにもとれるだろ
あと、ホワイトボックステストは入力値の抽出の観点だけではないだろ

ホワイトボックステストというと
デバッガで値を設定し、プログラムを追いつつ確認するようなのも含まれる場合もあるから、
単純にホワイトボックステストをすると言われたら、ユニットテストだけでは足りないという認識

ユニットテストが通常はホワイトボックスとして行われていることは同意

224 :デフォルトの名無しさん:2017/05/30(火) 20:44:06.83 ID:8S4zHXFC
>>223
>ホワイトボックステストというと
>デバッガで値を設定し、プログラムを追いつつ確認するようなのも含まれる場合もあるから、

それがよくある誤解なんだよ。
ホワイトボックスかブラックボックスは入力値の極限値や境界値、組み合わせの特性を決めるのに、箱の中を見るのか見ないのかということを指してる。
デバッガで値を変更するのは、ウォークスルーレビューの一種で、本来机上でやるのを計算機のサポートを得ながらやるという意味であり、狭義のテストではない。
広義のテストではレビューも含まれるから絶対間違ってるってわけではないけどね。

225 :デフォルトの名無しさん:2017/05/30(火) 21:06:18.81 ID:8S4zHXFC
よくある誤解というのは、
ブラックボックステスト=外から見た振る舞いを確認する
ホワイトボックステスト=内部の動きを確認する
というやつね。

これは全くの間違いで、テストは入力を与えて出力を見るものだから、どちらであっても外から見た振る舞いを確認するのが正解。
その時に、どんなテストをやれば効率的に十分な振る舞いを確認出来るのか、という観点で入力値を選ぶ方法として、ブラックボックスとホワイトボックスがある。
入力値自体の特性に着目するのか、入力値の扱い方に着目するのかって違いだね。
カバレッジは更に別の概念で、そうやって作ったテストが実際にどれぐらい振る舞いを網羅したのかという指標。
だから、ブラックボックステストであってもカバレッジは測れるし測るべき。

226 :デフォルトの名無しさん:2017/05/30(火) 21:49:18.36 ID:o/ByAjuM
ふむ、非常に一貫しているな
参考にした文献があるなら教えてほしい

もし独自のものだったら、
「テストは入力を与えて出力を見るものだから、どちらであっても外から見た振る舞いを確認するのが正解。」
これは話が飛びすぎ、または正解の定義が抜けている

再現が難しいテストでソースコードを使って再現させるテストはレビュー扱いか……
テストを入出力で定義したら、ブラック/ホワイトボックステストやレビュー扱いはそうなるよな
だがテストという言葉を独自に定義したのなら、その定義だけを根拠に他人のテストや、
ブラック/ホワイトボックステストの認識を間違いと断じるのはおかしい

少なくとも、テスト以外の扱いになったデバッガによるレビュー作業が正解でないという理由を示すべき
(テストの定義に当てはまらないからという理由なら、お前の中ではなということになっちゃう)

227 :デフォルトの名無しさん:2017/05/30(火) 22:09:55.71 ID:/DgUh2Dj
JSTQB とか参考にすりゃいいんじゃね?
https://webrage.jp/techblog/three_types_of_test_design_techniques/
あとデバッガ云々はテストのやり方の話だからウォークスルーレビューとか言ってる奴はちょっと頭が固いと思う

228 :デフォルトの名無しさん:2017/05/30(火) 22:18:05.12 ID:Fp/ortWi
>>225
ブラックボックステストのカバレッジってなんだか知ってる?
答えを知ってるならそれの測定結果になんら客観性がない事も分かるだろうし
知らないなら口からでまかせに言ってるかとんでもない勘違いのどちらかだし
何れにせよ「ブラックボックステストのカバレッジを測るべき」なんて発言は
著しい知性の欠如によるものだと判断せざるを得ないね

229 :デフォルトの名無しさん:2017/05/31(水) 00:19:18.63 ID:+GyFPiLx
>>228
カバレッジって日本語にしたら網羅率なんだから何のテストのってことはないよ。
プロファイラ掛けながら実行すれば行カバレッジだって取れる。
ブラックボックステストのカバレッジってのに違和感があるなら、ブラックボックステストをテストのやり方だと誤解してるよ。
何度も言うように入力値の決め方(テストケースの選び方)なのだから、テスト項目になってしまえば、ホワイトボックスで決めたのかブラックボックスで決めたのかは区別が付かない。

230 :デフォルトの名無しさん:2017/05/31(水) 00:38:56.45 ID:+GyFPiLx
>>226
>ふむ、非常に一貫しているな
>参考にした文献があるなら教えてほしい

普通に、古典のマイヤーズの「ソフトウェア・テストの技法」だよ。


>再現が難しいテストでソースコードを使って再現させるテストはレビュー扱いか……

デバッガを使えばテストではなくレビューだと言ってるのではないよ。
よく、ホワイトボックステストだと言われがちの、デバッガでステップを追って動作を確認するテストをレビューの方が近いと言ってる。
単にデバッガを汎用スタブ/ドライバ代わりに使えばテスト環境の一部になるしね。
逆にたとえデバッガを使わなくても、行毎にprint文を埋め込んで、どういう入力でどんな出力がでるのかという観点ではなく、どう言う順番で処理したのかに着目してるとしたら、それもテストではなくレビューだと言うべきだと思うね。

>少なくとも、テスト以外の扱いになったデバッガによるレビュー作業が正解でないという理由を示すべき

それはホワイトボックステストでは無いと言ってるだけだが、レビューと呼ぶべきと言うのは蛇足だったかもね。

231 :デフォルトの名無しさん:2017/05/31(水) 00:50:39.49 ID:9eeNyIu8
まあこういう言葉尻とか定義にこだわってるといっこうにテストって作られないよね。

232 :デフォルトの名無しさん:2017/05/31(水) 00:59:05.43 ID:JwC5dUSt
ブラックボックステストとかホワイトボックステトとかいう分類はいらん。
コストの観点から分類してくれ。

手動テストと自動テスト

233 :デフォルトの名無しさん:2017/05/31(水) 01:08:16.33 ID:+GyFPiLx
>>227
これのリンク先もホワイトボックステストを勘違いしてるように見える。
JSTBQの用語集では、以下で定義されてる。
ホワイトボックステスト設計技法(white-box test design technique): コンポーネントやシステムの内部構造の分析に基づきテストケースを設計、選択する技法。

これを、内部構造を検証するテスト、と飛躍してしまってる。これこそ典型的な誤解だ。こうやって誤解がぶんさんしていくんだろうな。

ホワイトボックステストは内部構造の分析に基づいてテストケースを設計するが、検証対象はあくまでも元々のテスト対象であって、テスト対象の内部構造では無い。
テスト対象の内部構造をテストしたい場合は、内部構造のレベルまでおりて、その粒度でまた内部構造の外部仕様(ブラックボックス)と内部構造の内部構造(ホワイトボックス)の分析に基づいてテストケースを設計する。
最終的に一番細かい単位のテストが、いわゆるユニットテストと称される。

234 :デフォルトの名無しさん:2017/05/31(水) 01:20:40.05 ID:+GyFPiLx
>>232
ちゃんと分類出来てないと、全然意味合いが違うもののコストを比較することになるよ。

ソフトウェアテストの場合は、手動テストは言うほど手動でなかったり、テストでなかったりするし、自動テストはそれほど自動でなかったりするからなあ。
コストを比較するなら、特定のテストのどの作業をどう自動化?するのかを論じないと。

自動って言葉って一人歩きするよね。
そのうち、「昔の自動車って手動で運転しなきゃならなかったんだって」って言われるようになるんだろうね。

235 :デフォルトの名無しさん:2017/05/31(水) 01:41:52.25 ID:JwC5dUSt
> 自動って言葉って一人歩きするよね。

いや? 全然。まずテストって言うのは
それが自動化されようがされまいがどんなものでも
ソースコードと同じリポジトリで管理されるべきものってのは
コンセンサス得られているかなぁって思う
この第一歩ができてないところが多すぎ

236 :デフォルトの名無しさん:2017/05/31(水) 01:46:08.21 ID:JwC5dUSt
>>234
> コストを比較するなら、特定のテストのどの作業をどう自動化?するのかを論じないと。

だからあとからコストを考えるのは辞めてほしい。
特定のテストにかかるコストをどうやって下げるかを論じないと。

237 :デフォルトの名無しさん:2017/05/31(水) 06:21:29.98 ID:wEozaoTa
>>235
えっと、もしかして、全てのテストが「テストコード」の実行によるものだと思ってる?

238 :デフォルトの名無しさん:2017/05/31(水) 06:22:19.36 ID:wEozaoTa
>>236
だから、その「特定のテスト」というものをどう切り出すかがテスト技術なんだって気付け。

239 :デフォルトの名無しさん:2017/05/31(水) 06:59:17.85 ID:/NpZlBRI
>>231
仕事の関係でJaSSTとかに何回か行ったことあるけどなんかこういう言葉遊びを延々やってるだけで全然まともなアウトプットがないんだよね
やってる本人達はこうやる「べき」だとかこうやればできる「はず」とかばっかりで、ならお前がやってみろよ!って突っ込みたくなる w

240 :デフォルトの名無しさん:2017/05/31(水) 06:59:55.91 ID:OKIouq/C
>>236
やること決めないでコスト算出したってその算出結果には欠片も意味がないからその算出作業のコスト自体がドブ捨て金になるよ。
自動なら手法確立までのコストが必要だがその後はほぼかからないのに対し、手動なら手法確立のコストは余りいらないが量に比例して作業や管理コストが増える。
そのどちらがいいかはその状況に依る。先行する条件に大きく依存するもので分類したところでそれには意味がない。

そもそも何するか判らない状態でどうやってコスト算出するのかこっちが知りたい。山勘とかはなしで。
だが、ここのスレの議論では得体の知れないコードのテスト方法を研究したいのであってコストの問題なんか知ったこっちゃない。

どういう立場の人か知らないけど、金勘定の話がしたいのならその手のスレに行った方がいい。プログラムロジックやその検証とは全く関係ない。

241 :デフォルトの名無しさん:2017/05/31(水) 07:30:04.08 ID:wEozaoTa
JaSSTはむしろテストの実践をしている人たちがよく登壇するんだがなあ…

242 :デフォルトの名無しさん:2017/05/31(水) 07:30:50.94 ID:wEozaoTa
むしろ対象を定義せずに、テストで何をするんだろう?わけがわからないよ。

243 :デフォルトの名無しさん:2017/05/31(水) 08:33:06.63 ID:/NpZlBRI
>>241
まあ実践なんて一回使っただけでも言えるからねぇ w
で、ここ10年で広まったテスト技術って何よ?

244 :デフォルトの名無しさん:2017/05/31(水) 10:30:31.11 ID:vzRkDbrn
>>233
C0,C1,C2カバレッジという観点は、内部構造の検証だろ

245 :デフォルトの名無しさん:2017/05/31(水) 11:26:49.87 ID:vzRkDbrn
>>241
http://jasst.jp/symposium/jasst17tokyo/report.html
学術方面からとか、第三者検証をする人たちとか、丸投げする人たちメインな感じだが

246 :デフォルトの名無しさん:2017/05/31(水) 11:29:57.45 ID:vzRkDbrn
個人的には、第三者検証の人たちから、テストとは〜とか言われても響かないんだよ
「でも、あんたたち、プロダクトの設計もしてないしコードも書いてないでしょ」と思ってしまう

247 :デフォルトの名無しさん:2017/05/31(水) 12:20:47.36 ID:z53WV942
>>229
全く反論になってない
相変わらず頭悪いなお前w

248 :デフォルトの名無しさん:2017/05/31(水) 12:37:08.33 ID:k6UVBo1S
>>244
もちろんc0,c1,c2カバレッジは内部構造に着目しているけど、内部構造が正しいかを検証するためでは無い。
ホワイトボックステストは内部構造に着目して重複や漏れの少ない効率的なテストケースを作ろうと試みる手法だけど、その時にどれぐらい漏れているかを示す指標だよ。

テスト対象の内部構造を検証することと、内部構造の情報を元にテスト対象の検証効率を上げることを区別しなければならない。
前者はテスト対象を変えてしまってるため、適切なテストケースを作り直さなければならない。

249 :デフォルトの名無しさん:2017/05/31(水) 12:38:50.10 ID:k6UVBo1S
>>247
君は相変わらず煽るのだけは上手いね

250 :デフォルトの名無しさん:2017/05/31(水) 12:50:28.31 ID:vzRkDbrn
言葉遊びの域を超えないね

>>248
> ホワイトボックステストは内部構造に着目して重複や漏れの少ない効率的なテストケースを作ろうと試みる手法
と繰り返しても、誰も納得しないよ

「ホワイトボックステストは、内部構造に着目してテストケースを決定し、その内部構造が意図通りに
実装されていることを確認するもの」と言ったらなにか反論できる?

251 :デフォルトの名無しさん:2017/05/31(水) 12:55:05.70 ID:z53WV942
>>249
ああああ煽りちゃうわ

252 :デフォルトの名無しさん:2017/05/31(水) 13:38:59.00 ID:k6UVBo1S
>>250
言葉の定義合戦をしているわけじゃないんだよね。
ホワイトボックステストがテストの実施方法ではなく、テストケースの設計手法である、ということを認めないのなら平行線だろうね。
用語定義をあたってくれとしか言えないな。

「ホワイトボックステストを内部構造が意図通りに実装されてることを検証すること」と勘違いして人が多いってのが元々の主張だし。
そう考えてるせいで、ソースを逆翻訳したような試験項目や、見れば意図通り実装していることが自明なことをわざわざテストするような不毛な作業に苦しんでいる人がいると思ってるのだけど。

253 :デフォルトの名無しさん:2017/05/31(水) 13:57:08.43 ID:vzRkDbrn
>>252
> 用語定義をあたってくれとしか言えないな。
偶然にも、全く同じことを言いたかったところ

ほれ、ホワイトボックステストを説明したページ
http://e-words.jp/w/%E3%83%9B%E3%83%AF%E3%82%A4%E3%83%88%E3%83%9C%E3%83%83%E3%82%AF%E3%82%B9%E3%83%86%E3%82%B9%E3%83%88.html
http://www.sophia-it.com/content/%E3%83%9B%E3%83%AF%E3%82%A4%E3%83%88%E3%83%9C%E3%83%83%E3%82%AF%E3%82%B9%E3%83%86%E3%82%B9%E3%83%88
https://en.wikipedia.org/wiki/White-box_testing

「ホワイトボックステストがテストの実施方法ではなく、テストケースの設計手法である」と定義してるページplz

> 「ホワイトボックステストを内部構造が意図通りに実装されてることを検証すること」と勘違いして人が多いってのが元々の主張だし。
「自分以外全員正しい」パターンでしょ

254 :デフォルトの名無しさん:2017/05/31(水) 13:59:58.15 ID:vzRkDbrn
>>252
> 見れば意図通り実装していることが自明
さて、以下のコードが意図通り実装されているかどうか、見てすぐにわかるだろうか

if (hoge()) {
 // process1
} else {
 // process2
}

意図はすぐにわかるだろう
そして、コードが「意図」と一致しているかどうかを検証するのがホワイトボックステスト
ちなみにその「意図」は、外部要件とマッチしているとは限らない

255 :デフォルトの名無しさん:2017/05/31(水) 14:11:03.71 ID:k6UVBo1S
>>253
ホワイトボックステストの用語定義を参照
http://jstqb.jp/dl/JSTQB-glossary.V2.3.J02.pdf

256 :デフォルトの名無しさん:2017/05/31(水) 14:15:24.65 ID:vzRkDbrn
>>233
つかよく見たら、ホワイトボックステスト「設計技法」じゃねーか

設計技法の話をしてるんじゃねー
「ホワイトボックステスト」の話をしてるんだが

257 :デフォルトの名無しさん:2017/05/31(水) 14:15:52.57 ID:vzRkDbrn
>>255
ほかのページを2,3例示plz

258 :デフォルトの名無しさん:2017/05/31(水) 14:19:48.42 ID:k6UVBo1S
>>254
ちなみに、実装が実装者の意図通りに実装されていることを検証する目的は何?
その検証に支払うコストに対して、どういう成果が得られる?

259 :デフォルトの名無しさん:2017/05/31(水) 14:25:37.52 ID:vzRkDbrn
>>258
> ちなみに、実装が実装者の意図通りに実装されていることを検証する目的は何?
おいおい、日本語大丈夫かよ
「実装が実装者の意図通りに実装されていることを検証する」こそがホワイトボックスてすとの目的だ

> その検証に支払うコストに対して、どういう成果が得られる?
TDDの文脈で言えば、確信・安心だな

つか、お前は「「実装が実装者の意図通りに実装されていること」は、いつどんなテスト手法で確認するんだよ?

260 :デフォルトの名無しさん:2017/05/31(水) 14:43:53.04 ID:k6UVBo1S
>>256
いやだから、ホワイトボックス「テスト設計技法」でテストケースを作って、それを実施するのがホワイトボックス「テスト」だよ。

261 :デフォルトの名無しさん:2017/05/31(水) 14:55:57.65 ID:vzRkDbrn
>>260
いい加減、勘違いに基づくアホ主張だったって認めろよ

262 :デフォルトの名無しさん:2017/05/31(水) 15:18:48.87 ID:jQ0rWyUQ
>>250
>言葉遊びの域を超えないね
それは君が言葉の定義を理解できていないからでは?

263 :デフォルトの名無しさん:2017/05/31(水) 15:20:59.39 ID:vzRkDbrn
という言葉遊びをまだしたいの?

俺は飽きたよ

264 :デフォルトの名無しさん:2017/05/31(水) 15:54:53.97 ID:k6UVBo1S
>>261
ホワイトボックステストを「テスト対象の内部構造をテストする手法」と定義することに何のメリットも感じないからね。
ホワイトボックス/ブラックボックスが、テストの粒度や手法や対象を指す用語ではなく、テストケースを作る観点を指していると考えると、色々スッキリするのでお勧めするという程度にしておくよ。

265 :デフォルトの名無しさん:2017/05/31(水) 17:29:01.41 ID:jQ0rWyUQ
ブラックボックステストのメトリクスをコードカバレッジで取ろうがどうでもいい。
そんなものはホワイトボックステストとブラックボックステストの違いの本質じゃない。
なんなら、組み合わせテストやペアワイズテストを実施した効果を評価するためにコードカバレッジを計測しても何の問題もない。
ホワイトボックスとブラックボックスで重要なのはテストデータを作成する基準なのだから。

266 :デフォルトの名無しさん:2017/05/31(水) 19:14:04.11 ID:ac0fXejp
>>264
スッキリしてないのはお前な
訳のわからん自分の勘違いに一つ気がついて皆にも教えてあげたいんだろうけど
そこを力説されても周りはポカンとするばかりなんだよ
あたりまえの事なんだから
お前一人レイヤの違うところで話をしてる
それどころかまだまだお前の勘違いは多いよ
もう少し素直になれば?

267 :デフォルトの名無しさん:2017/05/31(水) 20:04:35.26 ID:k6UVBo1S
>>266
具体的にどうぞ

268 :デフォルトの名無しさん:2017/05/31(水) 20:11:16.92 ID:k6UVBo1S
>>266
何が当たり前のことだと言いたいのか?
違うレイヤとはどのレイヤなのか?
他の勘違いとは何か?
ってところね。
そこが具体的じゃないと汎用煽り文句にしか見えない

269 :デフォルトの名無しさん:2017/05/31(水) 23:41:46.63 ID:QLf76euS
>>264
それそれ

ブラックボックステストとかホワイトボックステストとかどうでもいいんだわ
ソースコードを少しでも修正した時に、今までやったテストを再度実行できますか?
で考えれば、手動でテストしていたら現実的に不可能

手動で行うテストは、テストのサボり方を計算しなければいけない。
サボり方と悪い言い方をしたが要するに、「コード修正したけど、
これぐらいならテストやんなくていいっすよね?www」という話

手動でテストしていれば、コードを書きました→テストしました→バグが出ました→バグを修正しました→
修正した後のテストはしますか?前回テストでOKだった部分はテストしますか?
という問題が常に付きまとう

なのでコストが高いテストと、コストが低いテストにわけて、
○○というコードやシステムはテストのコストが高いです。
テストにかかるコストが低い方法に変更しましょうという話をするべき

ブラックボックステストとかホワイトボックステストとかいう区別はどうでもいい
なるべく小さいパーツでテストしたほうがコストがかからないということさえ知っていればいい
つまりはユニットテストでテストの大半を実施するのば良い

270 :デフォルトの名無しさん:2017/06/01(木) 01:23:49.70 ID:P48QZU+o
>>269
おいおい、ブラックボックステストとホワイトボックステストの違いが最もわかりやすいのがリグレッションテストだぞ…

271 :デフォルトの名無しさん:2017/06/01(木) 03:49:56.18 ID:WrS7qOOk
>>270
ならそのテーマで違いをわかりやすく説明せよ

272 :デフォルトの名無しさん:2017/06/01(木) 07:58:12.31 ID:RRNws2Be
>>271
外部仕様が変わったら再設計しなければならないのがブラックボックスで作ったテストケース
内部構造が変わったら再設計しなければならないのがホワイトボックスで作ったテストケース

まあ何を元にテストケースを設計したのかを考えれば当たり前の話だ
ただしホワイトボックステストも入出力をテストしてる限りは外部仕様を満たすから、内部構造が変わったからと言って今迄通っていたテストが通らなくなるわけではない。
ホワイトボックスの観点で重複するケースや漏れてるケースが生じるだけだ。
逆に外部仕様を変えればホワイトボックスで作ったテストケースの想定出力値を変えなければならない。

273 :デフォルトの名無しさん:2017/06/01(木) 08:27:45.89 ID:n/Xu1pq6
やたらとスレ違いな話題を振って噛み付いてくるのがいると思ったらテストに関する総合スレというか隔離スレみたいなのがないのね。
そういうスレ立てて餌を付けといたら隔離できるかな? 障害は早めに摘み取らないと。

274 :デフォルトの名無しさん:2017/06/01(木) 09:25:38.95 ID:WrS7qOOk
>>272
そいでリグレッションテストの話はどうしたよ?w

外部仕様が変わろうが、内部構造が変わろうが、
コードを修正することに変わりはない。

条件によってテストケースを修正することはないと言いたいのだろうが
どちらの条件でもコードは修正する。

そのコードの修正が予想外の影響が現れていないかどうかを
確認するテストがリグレッションテストだが?

それとも外部仕様が変わったなら、新たにプログラムを作る。
既存のコードは修正しない。コピペして使うんだ。とか言いたいわけ?

275 :デフォルトの名無しさん:2017/06/01(木) 09:27:37.25 ID:WrS7qOOk
>>272
> ただしホワイトボックステストも入出力をテストしてる限りは外部仕様を満たすから、内部構造が変わったからと言って今迄通っていたテストが通らなくなるわけではない。

それは予想外の影響が本当に現れてない場合ですよね?
予想できないから、予想外というのに、何もテストしなくて
予想外の影響が現れてないといえるのですか?

276 :デフォルトの名無しさん:2017/06/01(木) 09:29:48.49 ID:WrS7qOOk
>>272
なるほどそうか。
あんたはテストを修正する必要がないといってるだけで
(テストを修正せずに)再度テストを行う必要がないとは言ってないわけだ

277 :デフォルトの名無しさん:2017/06/01(木) 10:44:09.51 ID:zYZy0iHm
>>269
> ブラックボックステストとかホワイトボックステストとかどうでもいいんだわ
テスト手法を学ぶことには意味があるし、他者とコミュニケーションするときも意味がある。
上のように、君と君以外の「ホワイトボックステスト」の意味が異なると、まともに話ができません。

278 :デフォルトの名無しさん:2017/06/01(木) 10:44:36.77 ID:RRNws2Be
>>242
テスト対象を定義しないから、privateな関数をテストするべきか、なんて問題が生じるんだよ
テスト対象をclassにしたならば、privateメソッドはテストの入出力には使えない。ホワイトボックス手法で分析して、そのprivateメソッドを含めて網羅するpublicメソッドの入力値を探さなければならない。
それは非常に大変な場合が多々あるから、テストを変更するという対策が取られる。
大きく分けて2つ。テスト対象自体を変更する(privateをpublicに変えるとか)か、テストのスコープを変更する(classのテストをやめてclassの個々のメソッドをテスト対象にする)か。
どちらにせよ前までのテストは終わって別のテストを始めたと認識しなければならない。

279 :デフォルトの名無しさん:2017/06/01(木) 10:51:47.00 ID:RRNws2Be
>>276
そうだよ
テストケースを作るのとテストを実施するのを分けて考えなければならない。
それが顕著に現れるのがリグレッションテストだからね。
リグレッションテストは既にテストケースが存在していることが多いが、全部をそのまま使えるわけではないし、使えるテストケースの全てを実施するのことが費用対効果に優れているわけではない。
その時の指標になるのが、ホワイトボックス手法で作ったテストケースなのかブラックボックス手法で作ったテストケースなのかという情報だよ。

280 :デフォルトの名無しさん:2017/06/01(木) 11:31:34.33 ID:zYZy0iHm
>>278
> classのテストをやめてclassの個々のメソッドをテスト対象にする
どういう世界にいると、こんな考え方になってしまうんでしょうね。

281 :デフォルトの名無しさん:2017/06/01(木) 17:24:20.53 ID:Beh+XvgI
>>280
ある程度の高信頼性が求められるようなシステムでは大抵そこまでやってると思うが。

282 :デフォルトの名無しさん:2017/06/01(木) 17:44:32.62 ID:zYZy0iHm
>>281
そういう話じゃなくて、「classをテストするぞというマインド」が、「classのメソッドを呼び出してテストする」とは
違うようだという驚き。

283 :デフォルトの名無しさん:2017/06/01(木) 18:11:18.77 ID:Beh+XvgI
単に、テストで確認する事柄が
「クラスが仕様通りに実装されているか」
から
「メソッドが仕様通りに実装されているか」
に変わるだけでしょ。よくあることだよ。

284 :デフォルトの名無しさん:2017/06/01(木) 18:43:46.14 ID:zYZy0iHm
>>283
いやだからさ、君の言語が伝わってないってことなんですが。

285 :デフォルトの名無しさん:2017/06/01(木) 18:49:29.09 ID:zYZy0iHm
「テスト対象を定義」しろ
その対象とは、
・クラス
・クラスの個々のメソッド
である。
そして、両者には明確なマインドセットの違いが存在する。

というような考え方は、どこでなにをどのようにテストする文化だとそうなるんですかね。

ということなんですが。

286 :デフォルトの名無しさん:2017/06/01(木) 19:40:04.14 ID:MQIsy3K1
>>285
質問なのか揶揄なのか分からないんだけど、聞きたいのは、以下のどっち?

・「クラスをテストする」と「クラスのメソッドをテストする」ことの違い
・「クラスをテストする」と「クラスのメソッドをテストする」ことの違いを認識するのに必要な文化

後者なら分かりません。

287 :デフォルトの名無しさん:2017/06/01(木) 21:48:37.71 ID:WrS7qOOk
>>279
> リグレッションテストは既にテストケースが存在していることが多いが、全部をそのまま使えるわけではないし、

リグレッションテストの話です。
使えないテストケースとはどういうものですか?
繰り返しますが、リグレッションテストの話です。

288 :デフォルトの名無しさん:2017/06/01(木) 21:50:29.25 ID:WrS7qOOk
>>279
> それが顕著に現れるのがリグレッションテストだからね。

リグレッションテストの話です。
顕著に現れた一例を教えてください。
しつこいようですが、リグレッションテストの話です。

289 :デフォルトの名無しさん:2017/06/01(木) 22:49:36.44 ID:MQIsy3K1
>>287
リグレッションテストをするということは、変更した部分があるよね?
その変更によって、元々あったテストケースのうち、期待する出力が変わるテストケースと変わらないテストケースが存在する
期待する出力が変わったテストケースは再設計が必要になる。ここまでok?

290 :デフォルトの名無しさん:2017/06/01(木) 22:52:56.08 ID:MQIsy3K1
>>288
しつこくリグレッションテストを繰り返すということはリグレッションテストとは何かについて合意が取れてないことをアピールしてるのだと思うけど
リグレッションテストを何だと考えてるか説明してくれる?

291 :デフォルトの名無しさん:2017/06/01(木) 23:04:03.90 ID:WrS7qOOk
http://e-words.jp/w/%E3%83%AA%E3%82%B0%E3%83%AC%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%86%E3%82%B9%E3%83%88.html

リグレッションテストとは、プログラムを変更した際に、その変更によって予想外の影響が現れていないかどうか確認するテスト。

もっとも一般的に行われるのは、プログラムのバグを修正したことによって、そのバグが
取り除かれた代わりに新しいバグが発生していないかどうか、という検証である。

近年のOSのように大規模なプログラムでは、各部分のプログラムが複雑に関係しあっているために、
ある部分に加えた修正が一見何の関係もない部分に影響して誤動作を引き起こすことがある。
OSに修正パッチを適用したらアプリケーションが動かなくなった、といった話がそうした影響の代表例である。

292 :デフォルトの名無しさん:2017/06/01(木) 23:04:57.82 ID:WrS7qOOk
https://enterprisezine.jp/iti/detail/195

 システムに修正を加えた時、今まで動いていたところに影響が出ないことを
保証するのが、リグレッションテストです。

仕様の変更に伴う修正が入った場合も、システム全体への
影響を慎重に考える必要があります。

293 :デフォルトの名無しさん:2017/06/01(木) 23:06:42.95 ID:WrS7qOOk
http://type.jp/s/itac/article23.html

上記以外に、『リグレッションテスト』と呼ばれるテストもあります。
リグレッションテストは、バグの改修後や仕様変更の対応後に行うテストのことです。

294 :デフォルトの名無しさん:2017/06/01(木) 23:12:06.03 ID:WrS7qOOk
>>289
> ここまでok?

OKですよ。

でも次レスするときは「想定外」という言葉を使ってくださいね
理論上は問題ないはずだと思っていた想定が外れることを
想定外と言います。

295 :デフォルトの名無しさん:2017/06/01(木) 23:18:40.71 ID:MQIsy3K1
>>294
ごめん、何を想定外と言ってるのか分からないわ。
理論上は、過去に設計したテストケースは、テスト対象に変更を加えても、全てそのまま使えるはず、って言ってる?

296 :デフォルトの名無しさん:2017/06/01(木) 23:25:43.82 ID:WrS7qOOk
めんどくせーから先に答えを書くか

リグレッションテストをするということは、変更した部分がある。
というか時系列が逆で、何かの理由で変更したならばリグレッションテストをする

変更した部分があるということは、それと同時に多くの変更してない部分が存在している。

出力が変わった部分のテストケース・・・新しいテストの実行(ブラックテストかホワイトテストかは関係なし)
↑こっちはリグレッションテストではないので無視してい良い

↓重要なのはこっち
出力が変わってない部分のテストケース・・・変わってない想定であるがもしかしたら変わってるかもしれない
本当に変わってないのか不安だ。こういう時にやるのがリグレッションテスト


変更した部分があるといっても、変更しない部分が大半であり
その変更していない初の部分に影響を与えていないかを調べるのがリグレッションテスト

だからいくら「出力が変わった部分」にフォーカスしても意味はない
変わってないはずのところが本当に変わってないことを調べるのがリグレッションテストだから

297 :デフォルトの名無しさん:2017/06/01(木) 23:27:09.16 ID:WrS7qOOk
>>295
テストケースの話していない。

リグレッションテストは過去に存在するテストケースを
もう一度やる行為

テストケースではなくて行為

298 :デフォルトの名無しさん:2017/06/01(木) 23:33:46.17 ID:WrS7qOOk
>>295
> 理論上は、過去に設計したテストケースは、テスト対象に変更を加えても、全てそのまま使えるはず、って言ってる?

言ってない


理論上は、過去に設計したテストケースは、テスト対象に変更を加えても、テスト対象以外は全てそのまま使えるはず、って言ってる

想定外の箇所=テスト対処"以外"の箇所
に対してもう一度テストを行うことがリグレッションテスト

テスト対処以外は変わってないはずだって
再テストしなくても大丈夫だって思い込むのはやめなされ

299 :デフォルトの名無しさん:2017/06/01(木) 23:34:57.69 ID:MQIsy3K1
>>297
いつから、テストケースの話でなくなったのか分からないわ。

300 :デフォルトの名無しさん:2017/06/01(木) 23:35:49.26 ID:WrS7qOOk
>>299
リグレッションテストの話をしてからだが?

301 :デフォルトの名無しさん:2017/06/01(木) 23:40:49.71 ID:MQIsy3K1
>>298
>理論上は、過去に設計したテストケースは、テスト対象に変更を加えても、テスト対象以外は全てそのまま使えるはず、って言ってる

テスト対象じゃなくて変更対象に関わるテストケースだよね。リグレッションテストのテスト対象は全体だから。
で、それ以外は全てそのまま使えるってことは、それは使えないって意味だよね。
使えないテストケースについて合意が取れたようで何より。

>テスト対処以外は変わってないはずだって
>再テストしなくても大丈夫だって思い込むのはやめなされ

やっぱりテストケースを作ることとテストすることを混同してる気がするよ。

302 :デフォルトの名無しさん:2017/06/01(木) 23:42:12.54 ID:MQIsy3K1
>>300
>>287でテストケースについて質問しているように見えるけど?

303 :デフォルトの名無しさん:2017/06/01(木) 23:44:40.03 ID:WrS7qOOk
本当にリグレッションテストが分かってないんだなw

リグレッションテストは、変わってないはずのところが
本当に変わってないことを確かめるためのテストだって言ってるんだが

変更した部分があって、その変更した部分の仕様が "変わってない" ならば、
仕様を変えた部分を含めて、全てのテストケースをもう一回実施する

変更した部分があって、その変更した部分の仕様が "変わっている" ならば、
仕様を変えた部分を除いて、残りのテストケースをもう一回実施する

リグレッションテストのテスト対象は、最初から変わってないはずの部分と決まってるんだから
いくら変わったはずの部分のテストケースがどうとか話をしても意味がない

304 :デフォルトの名無しさん:2017/06/01(木) 23:45:09.92 ID:n/Xu1pq6
なんかこの話の噛み合わなさがスレタイっぽくなってきました。

305 :デフォルトの名無しさん:2017/06/01(木) 23:45:44.76 ID:O9hXITjG
>>302
リグレッションテストについて教えてもらえてよかったね

306 :デフォルトの名無しさん:2017/06/01(木) 23:46:37.96 ID:WrS7qOOk
>>301
使えないテストケースの合意を取ってどうするの?

リグレッションテストの話をしてるんだから
変わってない部分(正確に言うと変わってないはずの部分)のテスト
変わってない部分なんだから、当然テストケースも使えるというのは大前提なんだが?

リグレッションテストの話をしましょうやw

307 :デフォルトの名無しさん:2017/06/01(木) 23:48:02.49 ID:WrS7qOOk
で、リグレッションテスト=変わってないはずの部分の再テストと
ブラックボックステストやホワイトボックステストがどう関係するのさ?w

308 :デフォルトの名無しさん:2017/06/01(木) 23:48:12.28 ID:MQIsy3K1
>>303
いや、そんなことは分かってるけど…
リグレッションテストにホワイトボックステスト/ブラックボックステストの観点がどう役立つかを知りたかったんじゃなかったの?

309 :デフォルトの名無しさん:2017/06/01(木) 23:49:44.12 ID:WrS7qOOk
>>308
ここしばらく俺以外
ホワイトボックステスト/ブラックボックステスト
という用語すら出てこなかったよね?

それこそリグレッションテストと
ホワイトボックステスト/ブラックボックステスト には
何の関係もないことの証拠なんだがw

310 :デフォルトの名無しさん:2017/06/01(木) 23:52:22.21 ID:MQIsy3K1
>>303

あ、一点意見が違うわ。

>変更した部分があって、その変更した部分の仕様が "変わっている" ならば、
>仕様を変えた部分を除いて、残りのテストケースをもう一回実施する

仕様を変えた部分を除いて残りのテストケースを実施するんじゃなくて、仕様を変えた部分のテストケースを再設計して、だ。

311 :デフォルトの名無しさん:2017/06/01(木) 23:54:01.72 ID:WrS7qOOk
>>310
仕様を変えてテストケースも変えた時点で、
それはリグレッションテストではない。

リグレッションテストではないものの話はしてない
リグレッションテストの話をしている

312 :デフォルトの名無しさん:2017/06/02(金) 00:03:05.17 ID:hTWL2ZhC
>>311
つまり、テストケースを変えたらリグレッションテストとは認めないって主張ね。
よく読んで無かったけど、あのリンク先にはそういうことが書いてあるわけだ。

313 :デフォルトの名無しさん:2017/06/02(金) 00:09:34.75 ID:Vv44G7XD
変わってないはずの部分が本当に変わってないことを確かめるのが
リグレッションテストなんだからそりゃそうだろ

なんか引っかかるのは、全体を再テストした時
一部でも変わっている部分があるのなら、それは
リグレッションテストではないと言い出しそうなところだよなw

その場合は「変更された部分のテスト+リグレッションテスト」を行ってる。
リグレッションテストをしてないわけじゃない。

やりたいなら別に分けて実行しても良いよ。その場合は変更された部分だけテストを行いました。
後日、それ以外の部分に対してリグレッションテストを行いました。となる。
分けて実行したと考えれば、リグレッションテストを行っていることが容易に理解できるだろう。

314 :デフォルトの名無しさん:2017/06/02(金) 00:11:11.11 ID:hTWL2ZhC
>>309
つまり、もう興味はないってことかな?

315 :デフォルトの名無しさん:2017/06/02(金) 00:13:04.90 ID:xUiVlsMK
>>312
言葉が足りないね

316 :デフォルトの名無しさん:2017/06/02(金) 00:13:33.07 ID:Vv44G7XD
>>270
> おいおい、ブラックボックステストとホワイトボックステストの違いが最もわかりやすいのがリグレッションテストだぞ…

最初に話を戻すと、ブラックボックステストとホワイトボックステストの違いと
リグレッションテストには何の関係もないってこった

317 :デフォルトの名無しさん:2017/06/02(金) 00:39:05.52 ID:OWzBxuDw
>>316
うん、それで良いと思うよ。
君の勝利だ、おめでとう!

318 :デフォルトの名無しさん:2017/06/02(金) 08:25:34.95 ID:WIzhUdHX
ああ、わかった、このバカは、
変更されていないコンポーネントに対するテスト実行のみがリグレッションテストだと思ってるわけだ。

「変更部分の影響範囲を調べて元のテストデータから再テストすべき部分を切り出し、
さらに追加すべきテストデータを作成して、リグレッションテスト用のテストデータを
作成する」ことはリグレッションテストに含めないと。

本物のバカだな。テスト工程とは何なのか、全く理解できていない。

319 :デフォルトの名無しさん:2017/06/02(金) 08:28:45.76 ID:WIzhUdHX
おれのエスパー予想によると、
このバカは学部2年生ではじめて授業で「リグレッションテスト」なる言葉を聞き齧って
わけもわからずに独自解釈をわめきちらかしているだけ。

320 :デフォルトの名無しさん:2017/06/02(金) 08:56:10.37 ID:OWzBxuDw
多分、リグレッションテスト工程とリグレッションテストは違うと言いたかったんじゃないの?
知らんけど

321 :デフォルトの名無しさん:2017/06/02(金) 09:45:09.88 ID:Vv44G7XD
>>381
> (ソースコードが)変更されていないコンポーネントに対するテスト実行のみがリグレッションテストだと思ってるわけだ。

それは違うよ。ソースコードが変更されてないのではなくて
仕様が変更されてない部分に対して、以前やってテストを
再度行うテストがリグレッションテスト

322 :デフォルトの名無しさん:2017/06/02(金) 09:47:00.50 ID:Vv44G7XD
>>318
もちろんテストケースが足りなければ追加してもいいけど、
リグレッションテスト用のテストケースなんてのは存在しない。
そのテストケースをリグレッションテスト用にする必要はないから

負荷テストじゃないんだからさw

323 :デフォルトの名無しさん:2017/06/02(金) 09:48:12.96 ID:Vv44G7XD
>>320
"リグレッションテスト工程"なんて言葉はないようですね。
Googleで検索したら一件しか見つかりませんでした。

普通そんな工程は存在しないってことでしょう。

324 :デフォルトの名無しさん:2017/06/02(金) 09:49:28.62 ID:Vv44G7XD
普通はリグレッションテストはテスト工程の一つとして行いますからね

325 :デフォルトの名無しさん:2017/06/02(金) 09:52:15.00 ID:Vv44G7XD
>>318
> 「変更部分の影響範囲を調べて

リグレッションテスト目的が「想定外の箇所に影響を与えていないか?」だから
変更部分の影響範囲=想定内の箇所

調べて影響ないと思ったが、想定外の箇所に影響があった!
↑これを知ることがリグレッションテストの目的なんだから
影響範囲を調べてそこだけテストするのは、リグレッションテストにはならないよ

326 :デフォルトの名無しさん:2017/06/02(金) 10:11:55.17 ID:Uyi/oFkG
リグレッションテストって仕様がドキュメント化されてなくて
実装が仕様ですみたいなソフトウェアに対してするもんだと思ってたよ。

327 :デフォルトの名無しさん:2017/06/02(金) 11:23:31.07 ID:2tmjhXTO
>>286
> ・「クラスをテストする」と「クラスのメソッドをテストする」ことの違い
その違いとは?

> ・「クラスをテストする」と「クラスのメソッドをテストする」ことの違いを認識するのに必要な文化
微妙にニュアンスが変わっているが、どういう文化にいると上記のような使い分けをするようになるのか?

328 :デフォルトの名無しさん:2017/06/02(金) 11:30:20.06 ID:2tmjhXTO
>>325
> 影響範囲を調べてそこだけテストするのは、リグレッションテストにはならないよ
またおかしなことを言い始めた。

影響範囲内のテストを再実行するのもリグレッションテストでしょ。
影響範囲調査が間違っていたというのは、また別の話。

・影響範囲を調査するのが困難
・その調査に誤りがある可能性が高いと思われる
・全部テストし直した方が速い
の場合は、全部テストすればいいさ。

329 :デフォルトの名無しさん:2017/06/02(金) 11:36:04.80 ID:OWzBxuDw
>>326
いや、さすがにそれは違うでしょ
仕様がドキュメント化されていないソフトウェアは、どんなテストも総合テストや単にテストと呼んでいるイメージがある

330 :デフォルトの名無しさん:2017/06/02(金) 11:37:15.95 ID:2tmjhXTO
上で西先生disみたいなこと言ったが、いいこと言ってるわ(上から目線やめろ)

「【西康晴が語るソフト品質・第4回】テストの間引きが下手な企業は,品質事故が多発」
http://techon.nikkeibp.co.jp/article/NEWS/20060327/115426/

331 :デフォルトの名無しさん:2017/06/02(金) 12:49:43.86 ID:WIzhUdHX
>>325
わかりやすいシロートだな。
ちゃんと先生のいうこと聞いて勉強するんだぞ。
そうしたら半年後には自分の書き込みを見て赤面できる程度の知識はつく。
がんばれ。

332 :デフォルトの名無しさん:2017/06/02(金) 12:51:16.17 ID:WIzhUdHX
>>330
そういうこと。リグレッションテストもテストデータの間引きが重要。

333 :デフォルトの名無しさん:2017/06/02(金) 12:56:20.79 ID:WIzhUdHX
修正箇所から理論上変更が及ぶ可能性がある範囲と、
修正内容が「正しく」修正できていれば元と同じ振る舞いをする「はず」な範囲は別。
リグレッションテストは前者の範囲を再テストすることで、
後者の範囲の中にある誤り、つまり「正しく」修正できなかった箇所を発見する。
それがリグレッションテストな。

で、ホワイトボックステストとブラックボックステストでは、
リグレッションテストでのテストデータを間引くための技術が異なる。
当然のことだ。

334 :デフォルトの名無しさん:2017/06/02(金) 18:53:27.15 ID:WgeJS9BI
間引くってwwww
勝手にテストを間引くなよw
こういうの聞くといかにデタラメにテストしてるかが如実にわかるなw
普通はレビューで弾かれるもんだぜそういうのw
テストとして成立する前の話w
一度成立したテストはリグレッションで間引いてもいいテストなんかねえよw

335 :デフォルトの名無しさん:2017/06/02(金) 19:30:43.26 ID:ROv7EaIx
>>330
で、これ10年以上前の記事なんだけどWモデルとか流行ってるの?

336 :デフォルトの名無しさん:2017/06/02(金) 20:32:21.29 ID:FD8JrTHG
一度テストしたものを間引くってわけじゃないだろ。なんでそんなアホな解釈になるんだか。

337 :デフォルトの名無しさん:2017/06/02(金) 21:44:04.91 ID:td0NXywc
記事では工数のためテストを間引くって言ってるから、
一項目数十分以上とかのテストで、開発工程が終了したモジュールのテストとか対象じゃないかな

ただ、リグレッションテストを間引くのは怖いよな

338 :デフォルトの名無しさん:2017/06/02(金) 22:55:25.53 ID:Vv44G7XD
なんで俺がこれまで話してすらいないテストケースの間引きの話になってるんだよw

そもそもテストケースの間引きは、リグレッションテストではないものの話だろ
テストケースを必要十分に間引くって話はわかる

そして、え?なに? 必要十分とされたテストケースを、リグレッションテスト用にさらにまびくの?
よくそんな恐ろしいことができるな。間引く理由は自動化されてないからかね?

339 :デフォルトの名無しさん:2017/06/02(金) 22:57:17.42 ID:Vv44G7XD
>>333
> リグレッションテストは前者の範囲を再テストすることで、
> 後者の範囲の中にある誤り、つまり「正しく」修正できなかった箇所を発見する。

君の主張はわかった。だがそれは君の主張でしかない。
俺はちゃんと世間で言われているリグレッションテストの説明が
書いてあるページをもってきた。(上の方のレス参照)

それであんたの主張はそのページのどこに当てはまるのかね?

340 :デフォルトの名無しさん:2017/06/03(土) 02:46:49.36 ID:4CJADC1Q
>>338
あげられた記事ではリグレッションテストを間引くって話をしてる
難しい作業であることも記事は認めてる
間引く理由は工数のため

テストケースが必要十分って網羅性の観点から出たような言葉使ってるけど、
バグ発見の費用対効果のために網羅性を多少犠牲にしてでも間引くのをうまくやろうって話だぞ

テストケースってテストの入出力のデータだよな?
「リグレッションテスト用のテストケースなんてのは存在しない」って主張してるけど、
テストが異なれば当然テストケースも異なるわけだし
例えば、CUIのプログラムのリグレッションテストって、
オプション引数と入力ファイル、出力ファイル、標準入出力をファイル化したものとかだぞ

もしかしてユニットテストを何度も実行することを回帰テストと思ってたりする?

341 :デフォルトの名無しさん:2017/06/03(土) 03:03:16.93 ID:UA6ZbAhA
だからなんで間引くって話になってるんだよ?

リグレッションテストとホワイトボックス・ブラックボックステストが
どう関係あるのかって話だっただろ

342 :デフォルトの名無しさん:2017/06/03(土) 03:05:41.40 ID:UA6ZbAhA
>>340
リグレッションテスト用に間引く=既存のテストケースから
減らすってことを語っておきながら、

既存のテストケースにはないものを
追加するって話をしてるんだよ。w

減らすのか追加するのかはっきりしやがれ

343 :デフォルトの名無しさん:2017/06/03(土) 03:27:45.09 ID:paL1bH/i
もう完全に最初の話題(議論には程遠い)から脱線してる。

ここ最近の話題として、まずはテストケース選択で白黒の定義をはっきりさせようとしてたよな。
で、コストバカが出て来て知らない言葉を勝手に追加し始めて発散して。

一旦もうどうでもいいや、ってなりかけたのに
>>270 がひょっとリグレッションとか言っちゃったのを調子乗りがすぐ拾っちゃったのが今の惨状なわけだ。
雑談好きにはいいヒマ潰しなんだろうがな。付き合いきれん。

君ら一応ロジックを書いてる人達なんでしょ? この程度の話の流れすら制御できないのか。
一旦このスレ全部読み返せ。赤面ものの恥しい展開になってるから。

344 :デフォルトの名無しさん:2017/06/03(土) 05:56:57.42 ID:cVCELxIC
こう言う基地外がプロジェクトにいるとテストしにくいよね

345 :デフォルトの名無しさん:2017/06/03(土) 06:13:09.68 ID:dv4YO+sT
> 仕事の関係でJaSSTとかに何回か行ったことあるけどなんかこういう言葉遊びを延々やってるだけで全然まともなアウトプットがないんだよね
このスレと同レベルってことか

346 :デフォルトの名無しさん:2017/06/03(土) 08:19:11.69 ID:M94Hhk3q
>>345
このスレにいる ID:Vv44G7XD みたいのがレベル低すぎて
せっかくJaSSTで説明してもらった話を理解できてないだけ。

347 :デフォルトの名無しさん:2017/06/03(土) 08:21:07.24 ID:YuTJSBBf
何かを考察するならともかく、単に相手を言い負かそうとしてるからね
匿名掲示板で自分が多数派だと主張し始めるやつが出てきたら、もう議論にはならないよ

348 :デフォルトの名無しさん:2017/06/03(土) 08:24:01.96 ID:M94Hhk3q
このスレで勝利宣言したところで仕事が捗るわけじゃないのにな。
ほんとバカだ。
せっかく色々な人が教えてくれているのだから、
真摯に学べば、そのうち仕事も捗るようになるだろうに。

349 :デフォルトの名無しさん:2017/06/03(土) 08:37:27.87 ID:SWe7C40W
学んでもバカが加速するだけだからバカなんだよw

350 :デフォルトの名無しさん:2017/06/03(土) 09:16:40.17 ID:dv4YO+sT
>>346
で、JaSST のアウトプットってなに?
他人を見下す満足感ですか? w

351 :デフォルトの名無しさん:2017/06/03(土) 11:08:27.12 ID:8rEz/Sos
末尾wは劣等感の表れ

352 :デフォルトの名無しさん:2017/06/03(土) 20:54:34.31 ID:uoockcF7
リグレッションテストは自身に変更がなくても全然関係なさそうな他部署の変更とかセキュパッチ更新程度でも毎回通達が来るテストだぞ
変更当事者なら影響範囲を反映したテストを用意するし
その範囲はユニットテストとどまらない

353 :デフォルトの名無しさん:2017/06/03(土) 21:05:26.37 ID:8rEz/Sos
もう、リグレッションテストの定義はそれぞれの心の内で解決して、テストしにくいコードをテストする方法について語ってくれ

354 :デフォルトの名無しさん:2017/06/03(土) 21:07:32.42 ID:uoockcF7
じゃあテストしにくいコードって何なの
しにくいだけでテストできないわけじゃないよね
何か語る意味あるの

355 :デフォルトの名無しさん:2017/06/03(土) 21:27:08.13 ID:4CJADC1Q
具体的なコード例や体験談がたくさん報告されれば
よかったんだけどな

でも、スレで具体的なコードって十数行程度だろうし、
体験談も抽象的な書き方になって、このスレの住人だと設計が悪いで片付けられそうだ

356 :デフォルトの名無しさん:2017/06/03(土) 21:37:27.24 ID:KIyeoCmw
>>354
> じゃあテストしにくいコードって何なの

しにくい = 時間がかかると読み替えればいいと思うよ

357 :デフォルトの名無しさん:2017/06/03(土) 21:39:28.73 ID:KIyeoCmw
>>355
> 体験談も抽象的な書き方になって、このスレの住人だと設計が悪いで片付けられそうだ

なら設計が悪いコードを、設計を直さずにテストするチームと
設計を直してテストするチームに別れればいいともう

テストで頑張るって人は、そのままテストすればいいし
設計が悪いって言ってる人は設計を直せばいい

358 :デフォルトの名無しさん:2017/06/03(土) 22:05:39.00 ID:KIyeoCmw
テストにかかるコストと時間が大幅に減れば
コードを修正するたびに全てのリグレッションテストを行うことも可能になる。

それができないところは、一部のリグレッションテストだけを
時々やる方式にするしかない。そうすると同意しても漏れが出てしまうし
問題に気づくのも遅れてしまう

359 :デフォルトの名無しさん:2017/06/03(土) 22:46:54.61 ID:F8bh+pEI
一般にテストしずらい原因
1. 仕様を誰も知らない
2. 実行時間が長い
3. 実行環境を用意するのが難しい
4. 依存関係がわからない
5. 非決定性プロググラムなため正しいか間違ってるかわからない
こんなとこかね。
それぞれで対処法を考えてくのもありかな。

360 :デフォルトの名無しさん:2017/06/03(土) 22:53:06.87 ID:KIyeoCmw
マウスで手順通りポチポチやって同じ状態を作らないと
いけないってのはどれに当たるのかな?

361 :デフォルトの名無しさん:2017/06/03(土) 23:02:21.54 ID:uoockcF7
そういう同じ状態なら仮想環境でポチポチ後にイメージコピって作れるじゃん

362 :デフォルトの名無しさん:2017/06/03(土) 23:05:57.65 ID:KIyeoCmw
テストケースごとにデータベースなんかも含めた
全システムのイメージ作るってこと?

363 :デフォルトの名無しさん:2017/06/03(土) 23:06:33.26 ID:ez6eSYjJ
>>360
そんな事も出来なくてプログラマーとしてやっていけるの?

364 :デフォルトの名無しさん:2017/06/03(土) 23:08:47.47 ID:KIyeoCmw
>>363
え?お前なら5秒でできるっていうの?

365 :デフォルトの名無しさん:2017/06/03(土) 23:10:53.79 ID:ez6eSYjJ
>>364
え?お前はマウスでポチポチ作らなくていいテストは5秒でできるの?凄いね!

366 :デフォルトの名無しさん:2017/06/03(土) 23:13:24.93 ID:uoockcF7
時間かかる的なのはUATの段階で予想外の障害が上がって来て
しかも障害上げた当事者はシステムのことを全く知らない
アポ取って現地行ってヒアリングして再現に時間が掛かったりする
結局それは窓の仕様ですねで時間だけ浪費して帰るみたいなことはある

367 :デフォルトの名無しさん:2017/06/04(日) 00:13:31.74 ID:h7vkXgcL
仮想環境を導入する権限ないプログラマとかいるからなー

あ、ホントにテストしにくいコードをテストする方法って、
上司の説得の仕方とか、権限の拡大の仕方とか、そういうことなのか?

136 KB
新着レスの表示

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50
名前: E-mail (省略可) :


read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)