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

テストしにくいコードをテストする方法 その2

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

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


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

2 :デフォルトの名無しさん:2017/01/03(火) 18:00:08.97 ID:f6cee8Pv.net
例で考えよう。
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.net
その関数で対応する動物がもっと増えたとしよう。

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.net
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.net
これを手抜きやずるいやり方だと思うか?

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

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

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

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

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

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

ということでおしまい。

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

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

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

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

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



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

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

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

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

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

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

8 :デフォルトの名無しさん:2017/01/03(火) 18:02:53.02 ID:f6cee8Pv.net
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.net
「privateだからテストしてはいけない」という意見はそもそも的外れで
テストすべきものがprivateという状態ができたら
それは設計がおかしいと気づかないといけない。

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

27 :デフォルトの名無しさん:2017/01/06(金) 14:31:04.58 ID:jUueQ44/.net
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.net
公開する必要のないprivateメンバーをpublicにしてまでテストするなんて真逆の発想なんだよなぁ

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

80 :デフォルトの名無しさん:2017/01/21(土) 23:43:42.51 ID:ij3ZsOnR.net
>>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.net
他人に使われるものを作ってるんだったら必要ないものまでpublicにする(外部に公開する)のは良くないよ。
なのでaもbもどっちもダメ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

149 :デフォルトの名無しさん:2017/04/22(土) 18:38:24.70 ID:+5rvIbLJ.net
>>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.net
>>149
やりきれないとやりきれるの境目はどこ?
100個? 1000個? 1万個?
やれるなら、やれるところまでやるべきだって話なんだよね?


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

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

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

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

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

一歩前にもどるなよw

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

174 :デフォルトの名無しさん:2017/04/23(日) 12:27:10.81 ID:T4INally.net
>>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.net
>>174
コード上の境界値だけテストすれば十分だと思ってるの?
こわいなあ

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

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

178 :デフォルトの名無しさん:2017/04/23(日) 13:01:58.16 ID:T4INally.net
>>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.net
テストするならせめてもう一つ外側とかかな。
例えば履物が合計何個必要かとかを計算する関数のテストとかね。

get_sum_feet( animal_list )
のテストとか。

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

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

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

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

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

182 :デフォルトの名無しさん:2017/04/23(日) 13:13:22.57 ID:T4INally.net
>>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.net
>>182
だから単体はともかく結合じゃいるよ

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

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

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

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

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

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

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

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

numberOfFeet(animal)
get_sum_feet( animal_list )

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

ということらしい

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

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

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

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

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.net
>>192
「引数で渡した数値が二乗されて帰ってくる関数」って意味だよ。

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

195 :デフォルトの名無しさん:2017/04/23(日) 16:16:02.47 ID:CU9TQkMq.net
>>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.net
補足

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

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

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

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

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

199 :デフォルトの名無しさん:2017/04/23(日) 16:43:56.84 ID:T4INally.net
>>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.net
>>199
え?テスト追加してるじゃん?追加なしに検出出来るんじゃなかったの?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

手動テストと自動テスト

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

253 :デフォルトの名無しさん:2017/05/31(水) 13:57:08.43 ID:vzRkDbrn.net
>>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.net
>>252
> 見れば意図通り実装していることが自明
さて、以下のコードが意図通り実装されているかどうか、見てすぐにわかるだろうか

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

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

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

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

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

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

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

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

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

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

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

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

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

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

俺は飽きたよ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ということなんですが。

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

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

後者なら分かりません。

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

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

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

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

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

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

291 :デフォルトの名無しさん:2017/06/01(木) 23:04:03.90 ID:WrS7qOOk.net
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.net
https://enterprisezine.jp/iti/detail/195

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

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

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

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

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

OKですよ。

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

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

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

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

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

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

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


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

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

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

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

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

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

言ってない


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

あ、一点意見が違うわ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

368 :デフォルトの名無しさん:2017/06/04(日) 08:54:25.13 ID:W7e7oN9Z.net
>>365
テストケースが10000個あったとして1個5秒もかかっていれば
833分、13時間、コード修正のたびにこんなに時間かけてりゃ
やってられんだろ。5秒でも長すぎる。

遅くとも1個あたり0.01秒ぐらいで全てテストしたとしても100秒
程度じゃなければやってられん

369 :デフォルトの名無しさん:2017/06/04(日) 11:05:10.68 ID:yCxQT6OE.net
>>368
InMemoryのUnitテストならミリ秒単位だろ

370 :デフォルトの名無しさん:2017/06/04(日) 11:06:42.34 ID:zptvcWS6.net
>>368
5秒って実行時間の事かよ。だったら
>どれに当たるのかな
なんて聞くまでもなく自明だろ?

371 :デフォルトの名無しさん:2017/06/05(月) 11:10:39.41 ID:bwrXOc4q.net
>>335
> で、これ10年以上前の記事なんだけどWモデルとか流行ってるの?
千人月を超える規模の開発では、ウォーターフォールあるいはウォーターフォールを内包した
スパイラルモデル(あるいはそれもどき)で開発するのが主流。
Wモデルという単語自体が現場で飛び交っているかどうかは不明だが、その概念は今や常識だろう。

アジャイルや数十人月程度の小さなシステムなら、そもそもVモデルっぽい開発はしない場合が
多いだろう。なので、Wモデルという概念もない。

372 :デフォルトの名無しさん:2017/06/05(月) 12:42:25.47 ID:cR57/ADJ.net
>>371
> その概念は今や常識だろう。
コーディング前に全てのテスト設計が完了してるなんてほんとに実現できてるの?

> 数十人月程度の小さなシステムなら、そもそもVモデルっぽい開発はしない場合が
> 多いだろう。
普通にウォーターフォールで開発してるけど?

373 :デフォルトの名無しさん:2017/06/05(月) 13:03:10.25 ID:bwrXOc4q.net
>>372
> コーディング前に全てのテスト設計が完了してるなんてほんとに実現できてるの?
Wモデルのことを理解してないでしょ。
http://www.itmedia.co.jp/im/articles/1111/07/news202.html

> 普通にウォーターフォールで開発してるけど?
で、いまだに上流工程での設計ミスが、受け入れテストで発覚なんてやってるの?

374 :デフォルトの名無しさん:2017/06/05(月) 13:22:22.33 ID:bwrXOc4q.net
あ、わかった。

>>372
> コーディング前に全てのテスト設計が完了してるなんてほんとに実現できてるの?
俺が言ったのは、Wモデル(あるいはそれに類するような概念・問題意識)が常識だということで、
「Wモデルの実施」が常識的に行われているということではない。

実施そのものはまだまだ、あるいは試行錯誤中ってとこが多いと思う。
2012年時点の雰囲気:
http://www.kumikomi.net/archives/2012/03/rp11jas2.php

375 :デフォルトの名無しさん:2017/06/05(月) 17:47:48.39 ID:agHtRoLD.net
>>374
概念は知ってるけど実践はできてないってこと?
10年も経ってそれって意味ないじゃん w

376 :デフォルトの名無しさん:2017/06/05(月) 18:06:46.41 ID:bwrXOc4q.net
>>375
どうとでも、とって(投げやり

377 :デフォルトの名無しさん:2017/06/05(月) 22:10:56.23 ID:+JsFSKJf.net
結局口先だけなんだよな...

378 :デフォルトの名無しさん:2017/06/05(月) 22:11:38.26 ID:hT8phHO4.net
はっきり言えばいい。

Wモデルは実施されていない

379 :デフォルトの名無しさん:2017/06/06(火) 01:57:31.04 ID:a00fACdn.net
>>373
大丈夫。設計ミスなんて忖度で存在しなかったことになりますから。
コーディング、テスト担当が数人クビになってその派遣元が取引停止になるだけです。

380 :デフォルトの名無しさん:2017/06/06(火) 07:38:53.48 ID:CCnnQlLm.net
実施される/されないとかじゃなくて、モデルってのはそういうものだ。
バカじゃねーの?

381 :デフォルトの名無しさん:2017/06/06(火) 12:49:13.06 ID:rRaTvlwz.net
>>380
また実践もできない口先君が来たのか w
> モデルってのはそういうものだ。
具体的にどう言うものか書いてみ

382 :デフォルトの名無しさん:2017/06/06(火) 13:05:14.52 ID:N+7Sgk2g.net
半角スペース+wで荒らしてる奴、他のスレでも見た気がするぞ

383 :デフォルトの名無しさん:2017/06/06(火) 14:47:01.40 ID:YcFu/OxL.net
末尾wのレスを抽出すれば分かるが、基本的に無視して構わないことしか言ってないので、簡単にNGに出来るよ

384 :デフォルトの名無しさん:2017/06/06(火) 15:56:12.63 ID:N+7Sgk2g.net
ウォーターフォールにおけるV-modelからのW-modelの流れは、BDD(Befavior Driven Developemtn), ATDD(Acceptance Test Driven Development)アプローチと似てると思う。

いずれにしても、テスト準備を前に持って行けば持って行くほど、問題の解決コストが低くなる可能性が高くなるというのがメリット。

385 :デフォルトの名無しさん:2017/06/06(火) 20:03:45.13 ID:NTIs1mOP.net
糞みたいなうんちくはどうでもいいよ。
意味のないテストは削除して、意味のあるテストを増やしてけばいいだけ。
それができないのが問題なだけなんだよ。

386 :デフォルトの名無しさん:2017/06/06(火) 20:52:49.64 ID:rRaTvlwz.net
>>384
> いずれにしても、テスト準備を前に持って行けば持って行くほど、問題の解決コストが低くなる可能性が高くなるというのがメリット。
で、なぜ流行ってないの? w

387 :デフォルトの名無しさん:2017/06/06(火) 21:02:06.69 ID:mfyahOnQ.net
低くなる可能性が高くなる

馬鹿特有の言いまわしですよこれ

388 :デフォルトの名無しさん:2017/06/06(火) 21:18:19.83 ID:6cAGm0S8.net
>>387
さすがにそれはお前がアホすぎる

389 :デフォルトの名無しさん:2017/06/06(火) 21:26:27.96 ID:a00fACdn.net
>>386
テストを先に書けるだけ要件が決まってるプロジェクトが流行ってないからだろ。

>>387
[[コストが低くなる可能性]が高くなる]という構造を勝手に壊すのは馬鹿特有の解釈だと言うことができます。

390 :デフォルトの名無しさん:2017/06/06(火) 21:39:50.60 ID:6cAGm0S8.net
>>389
いやいや金融の案件とかやったことあればわかると思うけどレビューやりまくってがっちがちに仕様決めてからやるプロジェクトもあるよ
でもWモデルなんて実務で見たことない

391 :デフォルトの名無しさん:2017/06/06(火) 21:42:59.59 ID:Br9v/AuE.net
>>390
成功したwモデルを見たことないならともかく、失敗したwモデルも見たことないなら、単に見たことのある現場が少ないだけだよ

392 :デフォルトの名無しさん:2017/06/07(水) 06:54:04.96 ID:898Dxfil.net
>>391
まあうちの会社は基本的に金融関係はあまりやってないからそんなにたくさんは見てないよ
そもそもその手のプロジェクトだと2〜3年はかかるし
で、君のところではWモデル使ってるの?

393 :デフォルトの名無しさん:2017/06/07(水) 09:16:49.17 ID:kUtim7jQ.net
>>391
wモデルが使われてないってだけでは?

394 :デフォルトの名無しさん:2017/06/07(水) 10:22:58.75 ID:GHczQA0K.net
>>390
その金融の案件の詳細はわからないけど、勘定系システムの場合は早い段階(上流工程)からQA担当が入るだろ

395 :デフォルトの名無しさん:2017/06/07(水) 10:30:52.77 ID:GHczQA0K.net
Wモデルが普及してないのは明らかなんだが、何をこだわってるんだろう?
Wモデルとか言ってた奴pgrってこと言いたいのか?

396 :デフォルトの名無しさん:2017/06/07(水) 10:57:09.96 ID:WpL8bUE6.net
Wモデルが普及してないとしても、方法としては非常によいもののように見える

普及していないというのは、どういう理由なんだろう?

a. マイナーな方法なので誰も知らない
b. 呼び方が定着してないだけで実践されてる
c. Wモデルの方法では欠陥がある(コストとか?)
d. 業界がテストの最新方法を取り入れるのが遅れている

testing w-model とかで検索したら、それなりにヒットしたので a. ではないな
日本では流行ってないということなのかな?

e. 日本で取り入れるのが遅れているだけなのか、
f. 日本のソフトウェア業界には合わないのか

というのも追加しとこう

397 :デフォルトの名無しさん:2017/06/07(水) 11:12:19.16 ID:+jtNx/NC.net
>>393
見たことのある人が存在する以上は使われていないってことはないな
N系の大規模開発で見たことあるよ

398 :デフォルトの名無しさん:2017/06/07(水) 11:14:03.17 ID:+jtNx/NC.net
>>392
使うプロジェクトの時も、使わないプロジェクトのときもある
wモデルのおかげで成功したと感じたことは一度も無い

399 :デフォルトの名無しさん:2017/06/07(水) 12:57:33.13 ID:G2FybFJq.net
>>394
入るけどその上流の段階でテスト設計して仕様にフィードバックしてる?

>>397-398
そりゃ一回でも使われてたら
「使われてないことはないな」
って言えるけどそんな話をしたい訳じゃない
いったいどれぐらいの割合で使ってるの?
って話

400 :デフォルトの名無しさん:2017/06/07(水) 13:50:18.92 ID:GHczQA0K.net
>>399
> 入るけどその上流の段階でテスト設計して仕様にフィードバックしてる?
そりゃ、テスト設計の知見により仕様に誤りや漏れが発見されたら、
当然フィードバックされるでしょ。

401 :デフォルトの名無しさん:2017/06/07(水) 14:07:05.89 ID:+jtNx/NC.net
>>399
>いったいどれぐらいの割合で使ってるの?
>って話
それは使われてる割合の大小で何かを主張したい人が調べるべきでは?
割合を論点にするなら、あなたが全体のどれぐらいのプロジェクトを見たかを示さないと、見たことがないから流行ってないと主張は無意味ですよね。

402 :デフォルトの名無しさん:2017/06/07(水) 14:14:21.36 ID:GHczQA0K.net
Wモデルって、アジャイルでいうプラクティス的なものがきっちり決まってるわけじゃないから、
「今回はWモデルを採用しました」みたいなことが言いづらいってのもあるかもね。

QAチームが独立して入る、ある程度以上の規模のプロジェクトなら、Wモデル的な何かの
取り組みは大抵してる気がするんだがどうだろうか。

403 :デフォルトの名無しさん:2017/06/07(水) 17:56:45.38 ID:Zj9ffJlO.net
>>390
おまえの世間は狭いな。

404 :デフォルトの名無しさん:2017/06/07(水) 17:57:24.36 ID:Zj9ffJlO.net
>>396
他の開発モデルと同様に、取り入れられても事例として明らかにできない事情が多いから。

405 :デフォルトの名無しさん:2017/06/07(水) 19:52:36.68 ID:G2FybFJq.net
>>400
> そりゃ、テスト設計の知見により仕様に誤りや漏れが発見されたら、
> 当然フィードバックされるでしょ。
いや、だから上流段階でテスト設計までしてますか? って話

>>401
ざっくり100プロジェクト程度を見てもうちではほぼ使われてない
君のところでは使われたり使われなかったりするんでしょ?
で、その割合はどんなものかと

406 :デフォルトの名無しさん:2017/06/07(水) 21:56:01.51 ID:kUtim7jQ.net
>>397
> 見たことのある人が存在する以上は使われていないってことはないな

確率の問題。見たことある人が極端に少ない以上
殆ど使われてないと判断するしかない

最悪のケースでは「一件だけ使われている」ことだってありうる。

407 :デフォルトの名無しさん:2017/06/08(木) 00:36:58.12 ID:ueYAhQD8.net
要件定義の時点で「顧客はこの画面で入力値を1コ増やしたがる」と予見できるなら
できるかもしれないが

相手だってこっちだって全部わかってるわけじゃないんだよ

という現実的な問題がある
初期の経済学では「市場参加者は全部ワカってるはずだ」と仮定してて
そりゃないだろっつって情報の不均衡とか言い出して
最終的には「知ってる/知らない」をモデルに盛り込んだ理論でようやくってところだ

408 :デフォルトの名無しさん:2017/06/08(木) 00:38:12.04 ID:93Zc8GJH.net
日本で使われてる使われてないとか、どうでもよくね?

409 :デフォルトの名無しさん:2017/06/08(木) 02:48:19.21 ID:Y89msTuK.net
>>406
うん。気になるなら調べてみれば良いんでないの?

410 :デフォルトの名無しさん:2017/06/08(木) 03:19:55.32 ID:V9/FpTjK.net
調べた結果はもうわかってるよ。
使われているという実例は存在しない。

結論としてはそれで良いはずなんだが、
肝心の反論する人が反論の根拠を示さないから
あーだこーだいう羽目になってる。

やめやめ。Wなんたらとかは使われてない。以上。

411 :デフォルトの名無しさん:2017/06/08(木) 07:22:26.91 ID:CfLJLTCe.net
>>410
おまえの狭い世界では、だな。
現実世界では少なくとも俺は複数事例を知っている。

412 :デフォルトの名無しさん:2017/06/08(木) 08:05:19.29 ID:Che4gnSp.net
でも使われてる割合は明かせない
ってか w
数回使っただけで実践中って言うのはよくある話

413 :デフォルトの名無しさん:2017/06/08(木) 08:26:45.03 ID:c4NtK3hT.net
>>410
現在進行形で使ってるんだが

414 :デフォルトの名無しさん:2017/06/08(木) 08:31:06.50 ID:SSbqo8UT.net
>>402
まずWモデルと名乗って導入する前にV字モデルで開発プロセスを適用してなければならない。
それまでのプロセスをV字モデルと呼んでなければ、Wモデルと呼ぶことはないだろうから。

次にV字モデルの実施者にとって、Wモデルは、単純に工数を二倍にして先にテストプロセスを開始して設計プロセスに重ねただけに見える。
こう捉えてしまうと、V字モデルに比べて二倍の成果が出ないと元が取れた気がしない。人月の神話で有名なように、期間辺りの人員を二倍にした場合、成果は二倍を下回る。

最後に、Wモデルは何をやるかについては言及しているが、何をしないかについて言及していない。
だから、やることが増えることによって、開発プロセスの制御が困難になることに対応する指針にも使えない。

結局、このモデルの役割は、設計が終わらなければ試験設計を始めることが出来ない、という固定観念を崩す程度でしかない。じゃあ、どうやったらそれが上手く出来るのか、についてまで踏み込めていない。

固定観念を崩すということについては、実装を行う前に試験を実施する「テストファースト」に比べると、それほど突飛な事を主張しているわけでもない。

415 :デフォルトの名無しさん:2017/06/08(木) 09:44:35.92 ID:V9/FpTjK.net
>>413
君はZモデルを知ってるかね?
俺のは複数の使用事例を知っている。
使用している割合はあかせないが
現在進行形で使ってるんだが?
疑うんじゃねーよ

416 :デフォルトの名無しさん:2017/06/08(木) 10:55:34.99 ID:iO6bxGau.net
>>414
> 次にV字モデルの実施者にとって、Wモデルは、単純に工数を二倍にして先にテストプロセスを開始して設計プロセスに重ねただけに見える。
スキルの低い奴がTDDをやっても意味がないように、スキルの低い集団がWモデル(やそれに類する取り組み)をやっても意味がない。
そういうことだよ。

417 :デフォルトの名無しさん:2017/06/08(木) 10:57:30.48 ID:iO6bxGau.net
>>410
> 使われているという実例は存在しない。
いや、軽くググった程度で事例は見つかるだろ。

> やめやめ。Wなんたらとかは使われてない。以上。
なんでそういうことにしたいのか、そのモチベーションはどこから来てるんですかね。

418 :デフォルトの名無しさん:2017/06/08(木) 11:10:44.20 ID:iO6bxGau.net
>>405
> いや、だから上流段階でテスト設計までしてますか? って話
するでしょ。
もししないのなら、上流から入ったQAチームは何してるんだ?

419 :デフォルトの名無しさん:2017/06/08(木) 12:48:32.36 ID:Che4gnSp.net
>>418
> するでしょ。
なるほどちゃんとやってるところもあるんだな

> もししないのなら、上流から入ったQAチームは何してるんだ?
QAの観点でのレビューと仕様の早期把握でしょ

420 :デフォルトの名無しさん:2017/06/08(木) 12:54:30.12 ID:xFAk2Iqr.net
そもそも上流て設計する工程ちゃうでw

421 :デフォルトの名無しさん:2017/06/08(木) 14:26:54.03 ID:c4NtK3hT.net
>>415
キチガイか

422 :デフォルトの名無しさん:2017/06/08(木) 16:02:53.77 ID:SSbqo8UT.net
>>415
そのZモデルについて語りたいなら、存分にどうぞ。
どれぐらいの割合で使われているかに関係なく、何か役に立つ示唆を与えてくれるモデルなら、興味を持つ人もいるだろう。

423 :デフォルトの名無しさん:2017/06/08(木) 16:13:08.12 ID:iO6bxGau.net
俺が言うのもアレだが、このスレって

>>1
> ここで言うテストっていうのは
> ユニットテストみたいなものね。

なんだよね。

424 :デフォルトの名無しさん:2017/06/08(木) 22:52:24.77 ID:TyBSFeDZ.net
ユニットテストはテストコードを書いてやるものだけじゃないけどな

425 :デフォルトの名無しさん:2017/06/09(金) 08:13:12.88 ID:HjcwOhxM.net
結局、知識も調査能力も低いバカが「Wモデルなんて使われてないもーん」と駄々をこねていただけでした。
ちゃんちゃん。

426 :デフォルトの名無しさん:2017/06/09(金) 08:18:15.83 ID:HjcwOhxM.net
>>414
>次にV字モデルの実施者にとって、Wモデルは、単純に工数を二倍にして先にテストプロセスを開始して設計プロセスに重ねただけに見える。

それはお前がバカだから。

427 :デフォルトの名無しさん:2017/06/09(金) 08:58:12.34 ID:t9Hdk3pK.net
>>426
そんなに構って欲しいのか?

428 :デフォルトの名無しさん:2017/06/09(金) 12:36:40.07 ID:p+uc5TUG.net
>>425
具体的な数値を出さずに実践してますから〜
ってか w

429 :デフォルトの名無しさん:2017/06/09(金) 13:57:16.84 ID:ehLmIvol.net
Wモデル?聞いたことないわw

あれ、知らないの俺だけ?

いや、全然使われてないっしょ?w

ん?そうでもないのか?

具体的な数値出せやw

とでも言っとけば、誰も出せないからマウント完了w

な感じか

430 :デフォルトの名無しさん:2017/06/09(金) 22:41:59.93 ID:yARYpVIR.net
傍目にはデタラメなネコパンチ合戦にしか見えないけどこんなのでマウントって言うの?

431 :デフォルトの名無しさん:2017/06/09(金) 23:58:50.05 ID:g9EAqvex.net
>>429
> とでも言っとけば、誰も出せないからマウント完了w

こういうのはマウントと言わないでしょ?

裁判かな?
証拠出せ!証拠ありません!
じゃあ認められないな

閉廷

432 :デフォルトの名無しさん:2017/06/10(土) 09:35:16.38 ID:1OFjIP+4.net
>>429
> Wモデル?聞いたことないわw
そんなこと言ってるのはお前だけ
バカは絡んでくるなよ

初っぱなの >>330 を除けば具体的な話は >>373>>374 だけ
>>373 は上っ面の説明だし >>374 は JaSST の発表で5年前で試行錯誤って状態
ググればわかるけど2012〜2013辺りはそこそこ活発だったけどその後は鳴かず飛ばず状態
嘘だと思うなら期限を一年以内にして Wモデル でググればいい
ある意味笑える

433 :デフォルトの名無しさん:2017/06/10(土) 11:03:45.37 ID:fc6PrpF3.net
Wモデル否定バカがどんどん主張がショボくなっていくの笑える

Wモデル?聞いたことないわw

あれ、知らないの俺だけ?

いや、全然使われてないっしょ?w

ん?そうでもないのか?

具体的な数値出せやw

期限を一年以内にしてWモデルをググっても出てこないぞ

ほんとバカだわ。こんなのがソフトウェア開発業界にいるんじゃ、そりゃ炎上案件が出るわ

434 :デフォルトの名無しさん:2017/06/10(土) 11:52:36.17 ID:GrQ3Xe9Q.net
ググってリンク貼るのが調査です!

435 :デフォルトの名無しさん:2017/06/10(土) 11:53:16.79 ID:6qbw37FJ.net
具体的な事例も出せずに使ってるうって言うだけの簡単なお仕事お疲れ

436 :デフォルトの名無しさん:2017/06/10(土) 14:29:56.13 ID:3E5jUL+m.net
モデル名クイズスレとかでも作ってそっちでやれ。
これなら脚の本数でグダグダ言ってる方がまだテストスレっぽいわ。

437 :デフォルトの名無しさん:2017/06/10(土) 14:40:16.04 ID:TJyr+hnH.net
Wモデルがなぜ失敗したのかを調べたほうが良いだろうね。

438 :デフォルトの名無しさん:2017/06/10(土) 20:24:20.70 ID:GrQ3Xe9Q.net
そっちの方が価値があるだろうね

439 :デフォルトの名無しさん:2017/06/10(土) 20:33:01.99 ID:qxfpSvpV.net
研究成果が世の中に浸透するのに時間がかかる分野ってあるから、
流行してない = 失敗というのは早すぎるんじゃないかな?

最近ラムダ式がプログラミングでは一般的になってきた感じがするけど、
理論は 1930年代からあったみたいだし……

テストのような応用分野では普及はもっと早いとは思うけど

440 :デフォルトの名無しさん:2017/06/10(土) 20:41:48.78 ID:TJyr+hnH.net
>>439
使われないのと
使われてるのに評価されないのとは意味が違うよ

使われてないものは、使われ始めてやっと評価されるが、
Wモデルは使われてるんだろ?
なのに評価されてない。

ダメだったってこと

441 :デフォルトの名無しさん:2017/06/10(土) 20:48:04.74 ID:GrQ3Xe9Q.net
>>439
流行しているかどうかを気にしているのは少ないんじゃないか?
たとえ流行していたとしても、Wモデルに開発モデルとしての価値はないと思ってる

442 :デフォルトの名無しさん:2017/06/11(日) 00:47:30.44 ID:ED3vqoUB.net
流行に流されない俺かっこいい的な事を言いたい模様

443 :デフォルトの名無しさん:2017/06/11(日) 00:55:24.14 ID:xLXJwyhz.net
>>442
実際に言ってるのはお前だけどなw

444 :デフォルトの名無しさん:2017/06/11(日) 01:23:23.97 ID:9NPc/KiM.net
流行は亡くなったろ

445 :デフォルトの名無しさん:2017/06/12(月) 10:55:50.46 ID:6z3DqIFq.net
>>441
TDDに開発モデルとしての価値はないと思ってる
アジャイルに開発モデルとしての価値はないと思っている

なんでも言えるな

446 :デフォルトの名無しさん:2017/06/12(月) 11:00:46.96 ID:bV4n/B4Y.net
>>445
お前は何も言ってないけどな

447 :デフォルトの名無しさん:2017/06/12(月) 11:15:28.06 ID:6z3DqIFq.net
>>446
俺が何も言ってないんだとしたら、>>441も何も言ってないな

448 :デフォルトの名無しさん:2017/06/12(月) 12:29:00.22 ID:FzHZJ7Qu.net
ちなみに俺は何も言ってないよ

449 :デフォルトの名無しさん:2017/06/12(月) 12:37:26.08 ID:bV4n/B4Y.net
>>447
じゃあ、なんでも言えるんじゃなくて何にも言ってないってことで

450 :デフォルトの名無しさん:2017/06/12(月) 13:00:18.46 ID:6z3DqIFq.net
日本人じゃないのか、致命的に日本語能力に欠ける日本人なのか

451 :デフォルトの名無しさん:2017/06/12(月) 15:24:48.28 ID:bV4n/B4Y.net
そんなに自分のことを卑下しなくてもいいのに

452 :デフォルトの名無しさん:2017/06/12(月) 16:46:34.23 ID:mNr/mq3k.net
>>440
ダメなのはお前だバカ

453 :デフォルトの名無しさん:2017/06/12(月) 17:30:06.41 ID:6z3DqIFq.net
俺が知らないものは世界には存在しない教
俺が見えないものは世界には存在しない教
ググって見つかっても、やはり世界には存在しない教

454 :デフォルトの名無しさん:2017/06/12(月) 21:25:13.23 ID:gcWGi0lu.net
そろそろスレタイ見直すべきじゃない?

455 :デフォルトの名無しさん:2017/06/12(月) 23:15:51.37 ID:DpxyRymo.net
>>453
存在は誰も否定してないよ。
それが有効かどうかって話

456 :デフォルトの名無しさん:2017/06/12(月) 23:51:00.44 ID:XSFIuBP4.net
>>454
別にここのスレを存続させる必要はないから放置しとけばいいよ。
気になって見てしまった人にとっては釣りスレになるけどしゃーない。

457 :デフォルトの名無しさん:2017/06/13(火) 10:32:32.03 ID:3KAtKhUp.net
>>455
まずやってみろよ

458 :デフォルトの名無しさん:2017/06/13(火) 18:34:25.19 ID:vj/BzsS0.net
自分とこのプロジェクトがWモデルだとしても、
曽孫受け末端PGは気付かないだろうからなあ。
Wモデルなんて使われていないと言っているのは
そういうレベルの連中なんだろう。

459 :デフォルトの名無しさん:2017/06/13(火) 21:29:26.64 ID:oa+lAdCQ.net
つーか現状で何が不満なわけ?

Wモデルは使われてない(反論するなら証拠出せ)派と
Wモデルは使われてる(証拠はない・だせない・示せない)派に別れてるでしょ?

使われてない派は、(自分の意見が正しくあるために)証拠が出ないことを望んでいる
使われてる派は、(何らかの理由で)証拠を出さないことを望んでいる。

どちらも「証拠はない」という現状で満足しているわけだから
これで両者とも納得してると思うんだけど?

あとは「証拠がない」故に使われてない
「証拠がない」が使われてるという風に
お前ん中ではなという結論でしょ?

相手を説得するつもりがないんだから、これで解決じゃね?
(これ以上のレベルで相手を説得したいならどちらにしろ証拠を出すしかない)

460 :デフォルトの名無しさん:2017/06/13(火) 22:47:51.18 ID:OsSQx4DZ.net
>>458
害虫さん乙
普通の企業ならWモデルみたいなプロセスの変更がある時は全員に教育するよ
でないと混乱するし

461 :デフォルトの名無しさん:2017/06/13(火) 22:51:28.06 ID:Qhff7TC3.net
>>460
最初からW次モデルの場合は教育しないのかよ

462 :デフォルトの名無しさん:2017/06/14(水) 06:53:17.38 ID:xl37jtKC.net
>>459
普通に使われてると主張してる奴が証拠出せばいいだけ
>>374 によると5年前でも導入するかしないか程度だからその後普及してるなら JaSST とかでもっと発表があるはず
でも実際は...
ってことでしょ

>>461
> W次モデル
なんだその新しいモデルは? w

463 :デフォルトの名無しさん:2017/06/14(水) 08:57:38.65 ID:JrGv0x1p.net
検索すればたくさんヒットするじゃん
グーグル検索にヒットするのは氷山の一角だから
潜在的な利用数はその千倍あると言っていいでしょう

464 :デフォルトの名無しさん:2017/06/14(水) 11:38:08.48 ID:4KaRZHoy.net
>>459
Wモデルの使用例を知っている人にとって、使われていることなんて自明だから議論の対象ですらない。
また、自分がWモデルの使用例を知らないから殆ど使われていないと主張する人を納得させるメリットもないから、単に馬鹿にして楽しんでいるだけ。

Wモデル自体のメリット・デメリットについて興味ある人が二人以上同時に現れないから、それについての議論は始まってもいない。

465 :デフォルトの名無しさん:2017/06/14(水) 12:56:27.80 ID:3smJPRIt.net
>>463
> 検索すればたくさんヒットするじゃん
最近の話題を10件ぐらい出してみそ

466 :デフォルトの名無しさん:2017/06/14(水) 13:06:16.04 ID:/XZF9UoW.net
品質保証に1ミリも興味なさそうなんで、会話しても意味ない

467 :デフォルトの名無しさん:2017/06/14(水) 13:45:33.40 ID:dcTaX4yq.net
>>466
うむ。品質保証どころかコードの臭いもしない。伝書鳩が騒いでると思って諦めてる。

468 :デフォルトの名無しさん:2017/06/14(水) 18:10:57.72 ID:OTRTw69H.net
>>465
自分でググればいいじゃん

469 :デフォルトの名無しさん:2017/06/14(水) 18:45:36.31 ID:e2eXjlyw.net
> 検索すればたくさんヒットするじゃん
> 最近の話題を10件ぐらい出してみそ
> 自分でググればいいじゃん ← 今ここ

分かりやすすぎる w

470 :デフォルトの名無しさん:2017/06/14(水) 23:47:27.34 ID:eiBEZk9G.net
>>462
> 普通に使われてると主張してる奴が証拠出せばいいだけ

使われていると主張しているやつは
証拠を出したくないんだよ

それがわからないの?


使われているやつは、証拠を出したくない。
使われてないと言ってるやつは、証拠を出してほしくない

両方共証拠がない方がWin-Winでいいだろ?

なんで証拠を求めるんだ?

471 :デフォルトの名無しさん:2017/06/14(水) 23:49:37.89 ID:eiBEZk9G.net
このまま証拠がない状態であれば、


証拠がないのは、自明なことだからだろ。ふふふん。
と言ってるやつと
証拠がないのは、使われてないってことだろ。ふふふん。
と両方がこういうふうに思ってる。

ほら両者満足じゃん?
ふふふんと本気で思っているならば、
証拠がない状態で満足なんだから、
現状維持(証拠はない)にしておけよ。

472 :デフォルトの名無しさん:2017/06/15(木) 01:19:26.75 ID:lXZb+APL.net
>>471
何言ってんの?ずっと現状維持に決まってんじゃん
誰も解決しようとなんてしてないだろ

473 :デフォルトの名無しさん:2017/06/15(木) 06:44:42.66 ID:mtYV3Z5n.net
>>470
> 使われていると主張しているやつは
> 証拠を出したくないんだよ
出せないだけだろ
Win-Win とか頭にうじでもわいてるのか?

474 :デフォルトの名無しさん:2017/06/15(木) 10:26:24.07 ID:v/cBOZ+2.net
使っている:NTTデータ、日本ユニシス、複数の第三者検証会社

475 :デフォルトの名無しさん:2017/06/15(木) 10:30:02.72 ID:v/cBOZ+2.net
まあ、日立も富士通もNECもどこでも、Wモデルに類する取り組みはやってると思うがね。
やってないと思いたい理由がわからんわ。お前に関係ないだろと思うね。

476 :デフォルトの名無しさん:2017/06/15(木) 10:44:32.60 ID:iEtlER/O.net
>>475
日立は基本Wだね

477 :デフォルトの名無しさん:2017/06/15(木) 11:47:17.42 ID:RsKahxsz.net
議論に証拠は必要ないと思うけどなあ

478 :デフォルトの名無しさん:2017/06/15(木) 11:53:01.82 ID:RsKahxsz.net
裁判プレイなのかね

479 :デフォルトの名無しさん:2017/06/15(木) 11:53:22.25 ID:v/cBOZ+2.net
議論するつもりなんかないでしょ

480 :デフォルトの名無しさん:2017/06/15(木) 12:37:44.80 ID:Yf/PfV0U.net
言い負かすのが目的になってて、自分の知識を増やしたり新たな考え方を知ろうというのを目的にしていないから

481 :デフォルトの名無しさん:2017/06/15(木) 18:54:40.39 ID:XdSvhdkq.net
>>476
メジャーなSIerの名前だして使ってる(はず)って言うだけの簡単なお仕事お疲れ w
SQiP2013 の論文も読んだことないんだろうな

482 :デフォルトの名無しさん:2017/06/15(木) 18:57:08.86 ID:iEtlER/O.net
>>481
君はHIPACE読んだことないんだろうな

483 :デフォルトの名無しさん:2017/06/16(金) 12:45:21.85 ID:fQeM8oeB.net
>>482
第5版の方?
それとも Agile Scrum Methodology の方?
両方ざっと見たけどWモデルの話なんて見当たらないからどこに書いてあるのか教えてくれるかな

484 :デフォルトの名無しさん:2017/06/16(金) 13:07:39.65 ID:USlDWF2C.net
>>481
SQiP2013 の論文を読むと、メジャーなSIerのどこでもWモデルに類する取り組みがなされてないことがわかるのか。

485 :デフォルトの名無しさん:2017/06/16(金) 13:26:46.78 ID:USlDWF2C.net
つか、Wモデルを否定している奴のところは、QAチームはどのへんからプロジェクトに参加するんだ?

486 :デフォルトの名無しさん:2017/06/16(金) 14:25:40.50 ID:ekgkhFbF.net
>>483
読んでないのがバレバレ

487 :デフォルトの名無しさん:2017/06/16(金) 21:33:48.68 ID:ilQh64O7.net
>>484
えっ?
日立の話だろ?
SQiP の論文見たことないのか?

>>485
ものによるけどでかい案件だと受注段階から絡んでるよ
でもそれとWモデルの話は別なのぐらいはわかるよね?

>>486
具体的に書けないなら黙ってろよ w
第5版って書けばイントラ見れる奴ならわかるはずだし

488 :デフォルトの名無しさん:2017/06/16(金) 21:37:02.34 ID:rR75oHDm.net
>>487
俺は読んでないよ。
説明してくれるかい?

489 :デフォルトの名無しさん:2017/06/16(金) 21:55:46.90 ID:ilQh64O7.net
>>488
まず読めばいいと思うよ
https://www.juse.jp/sqip/symposium/archive/2013/day2/files/ronbun_A3-3.pdf
俺の感想は相当レベル低いな
って感じだけど w

490 :デフォルトの名無しさん:2017/06/16(金) 22:11:39.00 ID:ekgkhFbF.net
>>487
日立のイントラ見れるやつならすぐわかるだろ
今時新入社員研修でも扱ってるし

491 :デフォルトの名無しさん:2017/06/16(金) 22:12:15.61 ID:rR75oHDm.net
オープンソースプロジェクトでの採用事例無いの?

492 :デフォルトの名無しさん:2017/06/16(金) 22:41:02.70 ID:e6Uo8nQP.net
>>489
これって、wモデルを適用したって論文じゃないの?

493 :デフォルトの名無しさん:2017/06/17(土) 08:27:13.95 ID:5tQ1Dv+v.net
>>490
だからどこに書いてあるんだ?
内容は書かなくて良いから章・節番号を書いてみて

>>492
そうだよ
ちょっと試してみましたって奴
その後使われてると言う話はさっぱり聞かないけどね

494 :デフォルトの名無しさん:2017/06/17(土) 11:33:13.61 ID:7VDXunxt.net
>>493
じゃあ>>475の言うとおりwモデルに関する取り組みはしてるってことじゃないか

495 :デフォルトの名無しさん:2017/06/17(土) 11:47:09.45 ID:hpXZLyYV.net
そしてその取り組みは終わったんでしょう?

496 :デフォルトの名無しさん:2017/06/17(土) 11:56:06.12 ID:5tQ1Dv+v.net
>>494
>> 数回使っただけで実践中って言うのはよくある話

497 :デフォルトの名無しさん:2017/06/17(土) 12:03:38.04 ID:hpXZLyYV.net
大企業ってはたから見れば意味のないことやるからな。
ちょっとした検証した程度で、すごい効果がありましたって
プレスリリースだすのには驚いた。

大企業ってのは小さな部門がたくさんあって成果を出しなさいって
上から言われてるから、内容はともかく「成果を上げた」ということを
会社に知らせるためにやってるんだろうなって聞いてて思った。

あとプレスリリース自体が宣伝になってるとかね

498 :デフォルトの名無しさん:2017/06/17(土) 12:07:50.69 ID:7VDXunxt.net
>>496
ようするに、あまり使われてないって主張したいのかね?

499 :デフォルトの名無しさん:2017/06/17(土) 12:09:04.35 ID:7VDXunxt.net
>>495
知らん
もう取り組んでないって論文が出てきたのかと思って聞いだけ

500 :デフォルトの名無しさん:2017/06/17(土) 12:45:54.02 ID:5tQ1Dv+v.net
>>497
まあやってみないとわからんからやることは別におかしくない
やったらそれを報告しないとなにもやってないと思われるしね

>>498
そうですけどそれがなにか?

>>499
なにか別のやり方に変えるとか以外でそんな論文見たことある?

501 :デフォルトの名無しさん:2017/06/17(土) 13:47:49.64 ID:7VDXunxt.net
>>500
論文を引き合いに出すわりには、想像を語るだけなんだなぁ

502 :デフォルトの名無しさん:2017/06/17(土) 13:54:31.91 ID:hpXZLyYV.net
>>500
俺が言いたいのは報告するかどうかじゃなくて、
その報告にどれだけの価値があるのかってことだよ

アフリカに井戸を作りました。という報告はいいけど、
その一年後、どうなっているかを見に行ったら
井戸は破壊されていました。じゃ問題は解決してないだろう?

重要なのは「その報告」をその後どう役立てたかだよ。

503 :デフォルトの名無しさん:2017/06/17(土) 13:59:52.42 ID:5tQ1Dv+v.net
>>501
想像?
HIPACE ガーって言うから具体的にどこ?
って聞いたらノーレス
これが事実ですよ w

504 :デフォルトの名無しさん:2017/06/17(土) 14:07:36.50 ID:5tQ1Dv+v.net
>>502
> その報告にどれだけの価値があるのかってことだよ
書いてあるだろ?
>> 報告しないとなにもやってないと思われるしね
> 重要なのは「その報告」をその後どう役立てたかだよ。
それは各組織内の話
まあ役立てられてたらHIPACEとかにも反映されてるはずなんだが...

505 :デフォルトの名無しさん:2017/06/17(土) 14:13:58.42 ID:7VDXunxt.net
>>503
想像で悪いわけじゃないけど、>>484の反論に対して、論文を読めみたいに言うから、wモデルの普及率についての論文なのかと思ったら全然違ったので

506 :デフォルトの名無しさん:2017/06/17(土) 14:26:52.31 ID:5tQ1Dv+v.net
>>505
普及率を論じられた資料も見つからない
ってことでお察しください w

507 :デフォルトの名無しさん:2017/06/17(土) 14:32:23.69 ID:P+HusDAs.net
>>503
うん、読んでないんだよね君は

508 :デフォルトの名無しさん:2017/06/17(土) 14:38:57.37 ID:5tQ1Dv+v.net
>>507
日本語を理解できないのかな? w

>> 両方ざっと見たけどWモデルの話なんて見当たらないからどこに書いてあるのか教えてくれるかな

509 :デフォルトの名無しさん:2017/06/17(土) 14:40:16.00 ID:7VDXunxt.net
>>506
そりゃ普及率を気にする人が少ないからでは?

ちょっと気になって調べたら、これの総論8ページで、

>近年,V字型モデルを進化させたダブルV字型(=W字型)モデルが利用される ようになってきています。
ソフトウェアテスト見積りガイドブック
http://www.ipa.go.jp/files/000005132.pdf

って書かれてたわ。
本当かどうかは各自で判断してください。

というか、無料でこういうのが読めるんだな。ありがたい話だ。

510 :デフォルトの名無しさん:2017/06/17(土) 15:19:33.13 ID:hpXZLyYV.net
>>509
> 本当かどうかは各自で判断してください。

それは不可能。証明責任は主張する側にある

511 :デフォルトの名無しさん:2017/06/17(土) 15:27:27.78 ID:7VDXunxt.net
>>510
コストはそれによって利益を受ける側が負担すべき
疑うならIPAに問い合わせなよ

512 :デフォルトの名無しさん:2017/06/17(土) 15:36:51.46 ID:hpXZLyYV.net
聞いた所で利益は得られない。

本を配布して宣伝する側が利益を受けているわけで
やっぱり本を書いた側が負担すべき問題だなw

513 :デフォルトの名無しさん:2017/06/17(土) 15:38:42.58 ID:P+HusDAs.net
>>508
日本語を理解できないのかな?
新入社員研修ですら嫌と言うほど見せられる有名な図だよ?読んだことないのがバレバレ

514 :デフォルトの名無しさん:2017/06/17(土) 15:41:31.08 ID:hpXZLyYV.net
> 新入社員研修ですら

いくつの会社の新入社員研修ですか?

515 :デフォルトの名無しさん:2017/06/17(土) 15:44:29.88 ID:P+HusDAs.net
>>514
知らないね。ただHIPACE扱うような会社なら避けられないような重要な項目。ほら見てないんでしょ?

516 :デフォルトの名無しさん:2017/06/17(土) 15:45:15.20 ID:CpvsreYw.net
>>508
グループ外秘じゃねえの?

517 :デフォルトの名無しさん:2017/06/17(土) 15:52:39.56 ID:hpXZLyYV.net
>>515
だって、他社の新入社員研修なんて知らないしw

お前の知ってる一社以外では
使われてないんだから
知るわけないよね?

知らない人が多い = 使われてないということ

518 :デフォルトの名無しさん:2017/06/17(土) 15:55:31.04 ID:hpXZLyYV.net
> HIPACE扱うような会社なら避けられないような

HIPACE = HitachiHigh-Paceを扱うような会社って
日立システム以外の会社で使われてるんですか?

日立システムの下請けとか子会社に押し付けてるから
使われてるんだ!なんてのはなしですよw

日立システムとは関係ない、例えば海外の会社で
使われてるんですか?

519 :デフォルトの名無しさん:2017/06/17(土) 15:56:50.08 ID:P+HusDAs.net
>>517
日本語読めないの?HIPACE読んだなら書いてあるでしょって言ってんのwww

520 :デフォルトの名無しさん:2017/06/17(土) 15:57:19.14 ID:hpXZLyYV.net
HIPACEなんてゴミを読む人はいませんよ。

521 :デフォルトの名無しさん:2017/06/17(土) 15:57:34.27 ID:fcgaNhkc.net
>>518
日立システムってなあに?

522 :デフォルトの名無しさん:2017/06/17(土) 15:57:47.22 ID:hpXZLyYV.net
HIPACEは日立の社員が、会社からよめと
押し付けられるものですからねwww

523 :デフォルトの名無しさん:2017/06/17(土) 15:59:22.16 ID:hpXZLyYV.net
うひひひひw

http://blog.goo.ne.jp/katakait/e/acf5eda9e249719a0795c5e1692b8097

富士通のSDEMに対し、日立はHIPLAN、HIPACEと言っていた開発方法(手順)です。
当時、その会社にいましたが、これに従って資料を作ったらとんでもない手間になって
しまいます。しかし、デザインレビューでは、アレをやったか、コレをやったかと責め
立てられます。バ〜カ!と思いつつ、SEは時間をかけて体裁を整えていました。
決してお客さんのためではない時間の使い方です。そもそも、分厚い設計資料を見て
喜ぶお客は、システム導入で効果を出そうなどと思っていないでしょうね。教条主義な
設計手順、その全体となるRFP、いずれも遺物ならぬ異物です。
誠に情けないことですが、後生大事に今でもこの発想がはびこっているのが現状です。
大手SIerでこれに染まっていないところがあれば、そこに開発依頼をしたいものです。
しかし、我こそは、という気鋭のSIerに任せて安心できない、というのも一方の現実。
難しいですね、この辺。

524 :デフォルトの名無しさん:2017/06/17(土) 16:00:22.02 ID:hpXZLyYV.net
http://sugi-tec.tokyo/2015/03/09/%E3%82%A6%E3%82%AA%E3%83%BC%E3%82%BF%E3%83%95%E3%82%A9%E3%83%BC%E3%83%AB%E6%99%82%E4%BB%A3%E3%81%AE%E6%89%8B%E6%B3%95%E3%81%AB%E5%9B%BA%E5%9F%B7%E3%81%97%E3%81%AA%E3%81%84/

大型コンピュータから出される帳票、伝票を見ながら仕事する時代が
1970年前半からパソコンが業務処理の主役に台頭してくる1990年前半まで
長い間続いていました。この時代、大手コンピュータベンダに人材が集まり、
各社から様々な開発手法が発表されました。日立はHIPACE、HIPLAN、富士通は
SDEMなどがありましたが、いずれも仕様ががっちり固まってからのウオータフォールが前提でした。

525 :デフォルトの名無しさん:2017/06/17(土) 16:01:28.33 ID:hpXZLyYV.net
用語集

HIPACE(日立システム開発方法論)

526 :デフォルトの名無しさん:2017/06/17(土) 16:41:13.05 ID:U5/tp328.net
凄いぜスレ違いを延々と続けるこの情熱。普及してるとかしてないとかがそんなに大事な事なのか?
なんというか典型的な日本人って感じだね

527 :デフォルトの名無しさん:2017/06/17(土) 16:43:00.77 ID:h1XWghRt.net
>>509
それ何年前の本なのか知ってる?
あと独立行政法人だからそれなりに税金投入されてるのでただと言う訳じゃないよ

528 :デフォルトの名無しさん:2017/06/17(土) 16:52:32.65 ID:h1XWghRt.net
>>513
具体的な場所を示せない時点で吹いてるだけなのがバレバレ w

>>516
そんなにハードルは高くないけど閲覧は特定のグループ会社のみだよ

>>524
一応改訂してるから汎用機時代のままじゃないよ
まあ現場からの評判は散々なのは変わらんけど w

529 :デフォルトの名無しさん:2017/06/17(土) 16:55:26.39 ID:7VDXunxt.net
>>527
知ってるよ。2008年付だから9年前だね。
独立行政法人なのも知ってるよ。税金投入されててもこの文脈では無料と言うよね、

530 :デフォルトの名無しさん:2017/06/17(土) 16:58:34.14 ID:P+HusDAs.net
>>528
具体的な場所を示せない時点で読んでないのがバレバレwww

531 :デフォルトの名無しさん:2017/06/17(土) 16:59:24.56 ID:XCVqNiku.net
>>518
ねえねえ日立システムってなあに?

532 :デフォルトの名無しさん:2017/06/17(土) 17:15:24.86 ID:WIL4eA1g.net
このスレの役目は前スレ時点で終わってるからスレ違いだろうがなんだろうが消費させてとっとと落とすのが吉。

533 :デフォルトの名無しさん:2017/06/17(土) 17:18:24.28 ID:h1XWghRt.net
>>529
知ってたならそんな本あまり意味がないこともわかると思うんだが...

534 :デフォルトの名無しさん:2017/06/17(土) 17:28:08.84 ID:h1XWghRt.net
>>530
書いてないものの場所を示せとかアホすぎる w

535 :デフォルトの名無しさん:2017/06/17(土) 17:41:17.29 ID:hpXZLyYV.net
結局HIPACE(日立システム開発方法論)なんてものは
日立以外では使われてないってことか
まあ名前のまんまだなw

536 :デフォルトの名無しさん:2017/06/17(土) 18:05:41.51 ID:P+HusDAs.net
>>534
ないことの証明は?

537 :デフォルトの名無しさん:2017/06/17(土) 18:06:39.14 ID:Y25GEJCJ.net
>>534
君も全く読まずにレスしてるねwww

538 :デフォルトの名無しさん:2017/06/17(土) 18:11:29.32 ID:5tQ1Dv+v.net
>>536
読んでもらうしかない
これはグループ外の人には基本無理
でもあることを示すにはある場所を明示すればいいだけ
それをやれないと言うことは...

>>537
何度も同じこと書いて虚しくないの?

539 :デフォルトの名無しさん:2017/06/17(土) 18:37:05.04 ID:FfY0j2lX.net
>>538
何度も同じこと書いて虚しくないの?

540 :デフォルトの名無しさん:2017/06/17(土) 19:11:14.60 ID:U0QNG0AV.net
だから、開発プロセス全体を見る立場にない5次受け末端PGが
「W字モデルを使ってるところなんて見たことないもん!」
と駄々こねてるだけなんだから、みんな遠巻きにニヤニヤしながら眺めてればいいんだよ。

541 :デフォルトの名無しさん:2017/06/17(土) 19:47:00.35 ID:hpXZLyYV.net
そうおもうならこそば、その5次受け末端PGに
使っているという証拠を突きつければいいだけなのでは?

542 :デフォルトの名無しさん:2017/06/17(土) 23:32:18.28 ID:QXw6kq0k.net
>>533
意味がないとは?

543 :デフォルトの名無しさん:2017/06/17(土) 23:58:01.20 ID:QXw6kq0k.net
>>533
あぁ、他人を罵る役に立たないって意味か

544 :デフォルトの名無しさん:2017/06/18(日) 01:36:27.61 ID:MnZf8dSY.net
>>509
それのW字モデルの定義を見ると、後半の工程はテストの実施と修正を分離しただけだから、前半の工程で試験設計をするかどうかがV字モデルとの違いだな。
試験設計が実装完了を待つ必要がないのは自明だから、開発チームとは別にテストチームを持ててる所は、W字モデルと呼んでなくても、W字モデルに準拠するやり方でやってるんじゃないのかな?

545 :デフォルトの名無しさん:2017/06/18(日) 02:56:01.88 ID:dLIsPmeH.net
自明って言葉は、自分が説明できないことから
逃げるためのセリフだってじっちゃんが言ってた。

自明ってことを言うやつには、それが何故自明なのかを
説明されると、簡単に論破できるってばっちゃんも言ってた

546 :デフォルトの名無しさん:2017/06/18(日) 08:09:29.20 ID:y5TaghHe.net
>>542
現在の普及状況を知りたいのに9年前の情報もらってもねぇ

>>543
なんだよ単なる煽りかよ

547 :デフォルトの名無しさん:2017/06/18(日) 09:27:58.32 ID:y5TaghHe.net
>>544
> 開発チームとは別にテストチームを持ててる所は
そんなところあるのか?
運用テストとかシステムテストはQA部門がやるとしても単体テストや統合テストを別チームとか難しくね?

548 :デフォルトの名無しさん:2017/06/18(日) 09:33:25.47 ID:5SfAcpgV.net
>>546
それはあなたにとって意味がないってことだよ
そもそもIPAのこの文言がどこまで信頼できるかも分からないし、だから、各自で判断しろと書いた
もっと最新の普及率について知りたいなら、それで利益を得るのはあなたなんだから自分で探しなよ

549 :デフォルトの名無しさん:2017/06/18(日) 10:20:06.65 ID:y5TaghHe.net
>>548
> 各自で判断しろと書いた
だから自分の判断を書いたわけなんだけど...
アホなの?

550 :デフォルトの名無しさん:2017/06/18(日) 10:45:54.58 ID:5SfAcpgV.net
>>549
>>533
あなたに意味があるかどうかはあなた以外には分からないと思うのだが…

551 :デフォルトの名無しさん:2017/06/18(日) 10:59:08.01 ID:y5TaghHe.net
>>550
9年前の情報に意味があると言う主張?

552 :デフォルトの名無しさん:2017/06/18(日) 11:06:06.59 ID:WGtDcH0y.net
アルゴリズムの本は30年前のものでも役に立った
テストテクニックは何年くらい通用するのだろうか
毎年画期的な発明や発見があるわけではないであろうし内容で判断するしかないんじゃ……

553 :デフォルトの名無しさん:2017/06/18(日) 11:08:35.46 ID:5SfAcpgV.net
>>551
自分にとっては意味があるが、それを主張してるわけではない。しても仕方ないし
あなたに意味がないということは、事前に分からないというのが主張
つまり、>>533に対する反論
自分に意味がある資料は自分で探しておいで

554 :デフォルトの名無しさん:2017/06/18(日) 11:36:23.44 ID:2uyrEIrL.net
既に2012年の状況が示されてる(>>374)のにそれより古い情報をどや顔で出してくるとか
ちょっと頭の構造を疑うレベルだわな

555 :デフォルトの名無しさん:2017/06/18(日) 11:43:21.01 ID:SrhEXG8X.net
新しければいいってものじゃないだろ
ファッション感覚でテストやってんのか!?(ドヤ

556 :デフォルトの名無しさん:2017/06/18(日) 12:07:17.36 ID:5SfAcpgV.net
>>554
それがあんたに役に立ったんならそれで良いじゃん
相手がドヤ顔に見えるのは、あんたの劣等感の問題だから他人には解決出来ないよ

557 :デフォルトの名無しさん:2017/06/18(日) 12:25:38.94 ID:gxNeY7u0.net
うめ

558 :デフォルトの名無しさん:2017/06/18(日) 13:48:48.55 ID:FhFrbJQX.net
>>556
> それがあんたに役に立ったんならそれで良いじゃん
役立たずの資料だしてそんなこと言われてもね
> 相手がドヤ顔に見えるのは、あんたの劣等感の問題だから他人には解決出来ないよ
はいはい w

559 :デフォルトの名無しさん:2017/06/18(日) 15:39:57.56 ID:5SfAcpgV.net
>>558
末尾wも劣等感の表れ

560 :デフォルトの名無しさん:2017/06/18(日) 15:55:50.96 ID:YLg0us0V.net
IPAの文書を誰が書いたのかは知らないが、5SfAcpgV よりは信頼できそうだとは思うな。

561 :デフォルトの名無しさん:2017/06/18(日) 16:02:08.43 ID:MnZf8dSY.net
>>558が今もっと役に立つ資料を探してきてくれるよ

562 :デフォルトの名無しさん:2017/06/18(日) 16:03:45.61 ID:HlYLKNru.net
>>560
そりゃそうだ
ここの匿名発言のどれよりも信頼できる

563 :デフォルトの名無しさん:2017/06/18(日) 16:13:01.70 ID:y5TaghHe.net
>>560
そりゃそうだ
別に信用できないと言う話じゃなくて情報が古いってだけの話だし
まあ>>561はそう言うことも理解できてないみたいだけど w

564 :デフォルトの名無しさん:2017/06/19(月) 11:27:55.04 ID:Ce38C9l/.net
最近はDevOpsでもWモデル的な考え方が取り入れられてきている。
どういうことかというと、上流の設計時点でデプロイ方法や監視方法までを視野に入れて、
それを上流の設計にフィードバックするというもの。

565 :デフォルトの名無しさん:2017/06/19(月) 23:10:37.66 ID:l1liGy+g.net
>>564
そもそもさ、実装(コーディング)のために
設計するって当たり前じゃね?

実装で使う道具によって、設計変わるんだしさ。
jQuery使うかReact使うかAngular使うかで設計違うし

下流のことを知らないSEが上流の設計をやってるっていうのが
大きな間違いだって、随分前から言われてる

566 :デフォルトの名無しさん:2017/06/20(火) 08:15:18.55 ID:OgjZHXLz.net
>>564
最近あまりDevOps見てないけどそんな流れあったっけ?

567 :デフォルトの名無しさん:2017/06/20(火) 08:17:01.88 ID:OgjZHXLz.net
>>565
> jQuery使うかReact使うかAngular使うかで設計違うし
それだいぶ下流だよ

568 :デフォルトの名無しさん:2017/06/20(火) 09:43:15.81 ID:uMblZ3Am.net
>>567
あぁ、君、旧世代の人だねw

569 :デフォルトの名無しさん:2017/06/20(火) 10:38:25.97 ID:Msjo2Gc+.net
>>565
> そもそもさ、実装(コーディング)のために
> 設計するって当たり前じゃね?
>>564は、そういう話じゃないんだけど。

>>566
> 最近あまりDevOps見てないけどそんな流れあったっけ?
Wモデルでは、開発とQAが縦割りだったのを有機的に融合させるというスタイルで、
同じようなことが、DevOpsで開発と運用が縦割りだったのを融合させ、結果的に
デプロイ・運用を見込んだ上流設計(方式設計)がされることが多くなった。

570 :デフォルトの名無しさん:2017/06/20(火) 14:51:59.27 ID:6Z76wlCR.net
設計時点でテストの概念を導入しようなんてのは
モデルが出来ては忘れられ名前を変えて出て来ては忘れられしてきてるんだよ。
原因は便利そうだと飛び付いた上流とか言ってる奴らが理解できずに運用できなくて結局途中でやめるから。

きれいなサンプルコードに分岐網羅でいいからテストを書かしてみたいもんだ。
「ちゃんと動作することを目視する」とか書きそうな気がしてならない。

571 :デフォルトの名無しさん:2017/06/20(火) 15:07:05.55 ID:Msjo2Gc+.net
まあ、QAエンジニアと経験が数千時間、数万時間違うのに何いってんだってことですわ。

572 :デフォルトの名無しさん:2017/06/20(火) 20:49:50.55 ID:T6PY0LWM.net
>>569
> 同じようなことが、DevOpsで開発と運用が縦割りだったのを融合させ、結果的に
> デプロイ・運用を見込んだ上流設計(方式設計)がされることが多くなった。
具体性の欠片もなくて笑うしかない
JaSST の連中が得意気に言いそうな内容だな

573 :デフォルトの名無しさん:2017/06/21(水) 06:17:25.83 ID:W4oNZqsC.net
>>572
なるほど、君がいるあたりのド底辺の事情はJaSSTの人たちは知らないかもな。
でもそれはJaSSTのせいじゃないから。君自身の責任だから。がんばって。

574 :デフォルトの名無しさん:2017/06/21(水) 07:08:02.51 ID:tmnPHhmO.net
>> 具体性の欠片もなくて
には触れないJaSSTかぶれ乙

575 :デフォルトの名無しさん:2017/06/21(水) 08:03:27.30 ID:kbVPf5Jj.net
難癖付けるのは具体的でなくてもいい良いから楽だしな

576 :デフォルトの名無しさん:2017/06/21(水) 08:13:17.60 ID:tmnPHhmO.net
「具体性の欠片もなくて」と言う具体的な指摘をされてるのに何を言ってるんだ?

577 :デフォルトの名無しさん:2017/06/21(水) 09:00:23.94 ID:BZXMZb7j.net
具体性の定義がないし欠片の定義もないじゃないか
具体的どころかぐだぐだじゃないか

578 :デフォルトの名無しさん:2017/06/21(水) 10:11:56.13 ID:kbVPf5Jj.net
>>577
それが具体的だというなら、「開発と運用が縦割り」も「デプロイ・運用を見込んだ上流設計(方式設計)」も十分具体的だよな

2chに書けることなんてヒントぐらいでしかないのに、アレが無いコレが無いって文句ばかり言うだけで、もっと詳しい資料が提示されたら読みもしないで意味がないと言う

いつもそうだよ、構うだけ無駄

579 :デフォルトの名無しさん:2017/06/21(水) 12:42:37.94 ID:FmgD4alH.net
>>578
> 詳しい資料が提示されたら
提示してから言えばいいと思うよ
まあどうせ出てこないだろうけど

580 :デフォルトの名無しさん:2017/06/21(水) 20:17:57.58 ID:W4oNZqsC.net
>>579
君は本当に馬鹿だね。がんばれ。

581 :デフォルトの名無しさん:2017/06/21(水) 20:31:26.25 ID:FmgD4alH.net
馬鹿としか言えない哀れな人乙

582 :デフォルトの名無しさん:2017/06/24(土) 18:06:23.18 ID:jG1C/Elt.net
他人を馬鹿にする人は心のどこかで自分に対して不満や無価値感を持っている人である

583 :デフォルトの名無しさん:2017/06/24(土) 23:41:56.68 ID:gi9Y/LTU.net
他人を馬鹿にする人を馬鹿にする人は心のどこかでナニ満をもってるの?

584 :デフォルトの名無しさん:2017/06/24(土) 23:57:31.76 ID:a1OlPOBm.net
他人を馬鹿にする人に対する不満じゃね? 不満を言うことは馬鹿にすることじゃないよ

585 :デフォルトの名無しさん:2017/06/25(日) 08:06:18.53 ID:8epxdf6f.net
要するに自分は正しい、他人は間違っているとゆうわけですね
馬鹿ですね〜

586 :デフォルトの名無しさん:2017/06/25(日) 08:18:19.83 ID:NO+bhPJd.net
自分だけは常に正しいという前提

587 :デフォルトの名無しさん:2017/06/25(日) 11:20:05.50 ID:8epxdf6f.net
自分だけは常に正しいという他人の持つ前提は間違っているという前提
馬鹿ですね〜

588 :デフォルトの名無しさん:2017/06/25(日) 12:39:52.58 ID:NO+bhPJd.net
>>587
どこにも間違ってるなどとは書いていません
ただその前提があるというだけ

589 :デフォルトの名無しさん:2017/06/25(日) 14:49:49.24 ID:C+r4XAn2.net
まあ、間違ってると思うけどね

590 :デフォルトの名無しさん:2017/06/25(日) 15:35:40.59 ID:Ylg516Tn.net
正しいとは限らない、としか言わなければ常に正しい

591 :デフォルトの名無しさん:2017/06/25(日) 15:58:37.28 ID:C+r4XAn2.net
>>590
その姿勢が正しくない

592 :デフォルトの名無しさん:2017/06/25(日) 16:02:36.06 ID:8epxdf6f.net
他人だけは常に正しくないという前提

593 :デフォルトの名無しさん:2017/06/25(日) 16:39:38.44 ID:G1doar1f.net
>>590
とは限らない

594 :デフォルトの名無しさん:2017/06/26(月) 19:00:42.22 ID:NlJN5AI+.net
JSのMochaってすげえ簡単にテスト環境構築できるんだな、
ちょっと感動したわ。

595 :デフォルトの名無しさん:2017/06/26(月) 19:14:02.11 ID:MwytOOTB.net
>>594
ただ、そこにカバレッジとか付け足そうと
思ったら大変になるよw

なんかのフレームワークでそこら辺まで
ちゃんと整備されていればいいんだけどね

596 :デフォルトの名無しさん:2017/07/01(土) 11:22:28.28 ID:N+ZXroXE.net
人をバカにしないと自分の価値が維持できないという強迫観念
自分は人より何でもよく知っていないと価値がないんだという価値観

597 :デフォルトの名無しさん:2017/07/02(日) 17:07:05.54 ID:ZSh6PefU.net
自己紹介ですね

598 :デフォルトの名無しさん:2017/07/02(日) 17:37:34.20 ID:J2BCSwZK.net
>>596は無意識で起こる根底の深層心理であって普通は意識されない
自分は違うと思っている人ほど掘り下げるとそうである

599 :デフォルトの名無しさん:2017/07/15(土) 11:58:17.10 ID:N0flRzpM.net
あー、いまなんかモヤモヤしているのが解決した気がする。

コードのテストは必要。だけどデータはテストは不要。ってこと。

もう少し詳しく言うと、コードを実行した結果の処理されたデータ(戻り値)はもちろんテストする。
そのことに対してコードのテストは必要と書いた。

だけど、例えば、クラスのデータとしてなんらかの定数を持たせて
その定数が定義どおりであること。なんてテストは不要
ある関数を引数を渡して呼び出した時、その引数が渡した物と一致するかのテストも不要
テスト済みのライブラリを使ってJSON形式の設定ファイルを読み込んで、
その設定値が正しく読み込まれているかのテストも不要
(ただし何かしらの処理で加工されている場合は、それに対してのテストは必要)

関数を通した時にデータが何の加工もされずに使われたり戻る場合はそのテストは不要ということ
そんなものにテストを書いたとしても、結局データが書いたとおりの値であることしか調べられないので
単にコードとテストコードの両方に同じ定義を二回書くだけでしかない

600 :デフォルトの名無しさん:2017/07/16(日) 05:02:49.11 ID:yo5XpH/o.net
バグで加工されてるのが検出できないな
セッタゲッタをコピペして参照するメンバがそのままでバグとかよく見かける

仕様通りだったら問題ないからテストしないというのは賛成できない
品質落ちてもいいから工数削減のためにどのテストから削るかってならわかるけど

601 :デフォルトの名無しさん:2017/07/16(日) 10:35:16.46 ID:qSnPeHti.net
プロパティ使えよ

602 :デフォルトの名無しさん:2017/07/16(日) 11:42:55.41 ID:yo5XpH/o.net
>>601
プロパティをラップできる言語とは限らないし
何かフックしてるからコピペなのかもだろ

お前のテストは抜けが多そうだな
ひとつの言語しか触ったことないというならまあしょうがない気もするが

603 :デフォルトの名無しさん:2017/07/16(日) 11:47:43.24 ID:qSnPeHti.net
>>602
かわいそうに

604 :デフォルトの名無しさん:2017/07/16(日) 11:52:25.63 ID:yo5XpH/o.net
>>603
それしか言えないのかw

605 :デフォルトの名無しさん:2017/07/16(日) 12:09:51.04 ID:qSnPeHti.net
>>604
(そういうバグをよく見かけるような環境で)かわいそうに

って言わないとわかんないのかい?

606 :デフォルトの名無しさん:2017/07/16(日) 14:28:51.75 ID:7yCzKBGI.net
理由を書いても理解されないことが多々あるのに、
感情だけ書かれて理由を察しろって無理だから

607 :デフォルトの名無しさん:2017/07/16(日) 16:21:11.76 ID:yo5XpH/o.net
>>605
感情でテストするのか
テスト経験が少ないのに
周りがかわいそうだな

608 :デフォルトの名無しさん:2017/07/16(日) 17:29:12.51 ID:qSnPeHti.net
>>607
テストとそれ以外の区別もつかないなんてあわれなやつ

609 :デフォルトの名無しさん:2017/07/17(月) 10:02:52.51 ID:a/BJdC61.net
>>608
テストの話じゃないならスレチなのでお帰りください

610 :デフォルトの名無しさん:2017/07/17(月) 12:04:26.71 ID:voKBolpL.net
ここでスレチでない話題なんかほとんどねーよ。

611 :デフォルトの名無しさん:2017/07/17(月) 14:47:57.26 ID:a/BJdC61.net
テストとそれ以外の区別もつかないなんてあわれなやつ

612 :デフォルトの名無しさん:2017/07/18(火) 07:30:57.94 ID:nV7oRxMW.net
どうやって区別するの?

613 :デフォルトの名無しさん:2017/07/18(火) 07:31:21.36 ID:nV7oRxMW.net
自分もわかってないんじゃない?

614 :デフォルトの名無しさん:2017/08/10(木) 09:41:33.46 ID:12DlMIVs.net
get と set をテストしなきゃならんとか
開発効率めちゃくちゃ悪そう。

こんなところにバグがあるならそもそも
もうすこしレイヤの高いメソッドでバグが出るもんだろうし、
そういうところでテストすべきだと思うよ。

615 :デフォルトの名無しさん:2017/08/19(土) 17:34:48.08 ID:uww7i/PR.net
コードの量が空行も入れて100行ぐらいしかないです。

簡単なツールで、関数すらありません。
処理の内容は、あるファイルを元にサーバーに対して
REST APIを呼ぶ程度です。

これをテストするとしたら、クラスや関数を作って
REST API部分はモックを使わなければ行けないと思うのですが
やる価値ありますか?

616 :デフォルトの名無しさん:2017/08/19(土) 17:58:42.31 ID:9KU7ntuJ.net
QUnit, Sinon, Jasmin とかだろ

617 :デフォルトの名無しさん:2017/08/19(土) 22:46:59.22 ID:9sjMFNW8.net
>>615
テストすることで得られる情報量とコストを比べろ

618 :デフォルトの名無しさん:2017/08/19(土) 23:06:20.61 ID:uww7i/PR.net
>>617
テストすることで何が得られるんでしょうか?
100行程度なので実行コードを見れば
何をしているかなんて明らかななんですよ

テストコード書いたらおそらく100行以上になるので
実行コードを見るよりも時間が掛かるでしょう。

619 :デフォルトの名無しさん:2017/08/19(土) 23:14:01.85 ID:RbCsVb76.net
>>618
何がしたいのお前

620 :デフォルトの名無しさん:2017/08/19(土) 23:25:31.12 ID:9sjMFNW8.net
>>618
何が得られるかはお前にしか分からない
テストしても新たな情報が得られないのが分かっているならテストしなくて良いよ

621 :デフォルトの名無しさん:2017/08/19(土) 23:35:58.11 ID:uww7i/PR.net
>>620
ですよね。これぐらいの短いコードに
テストコードがあったて意味が無いと思ってました

622 :デフォルトの名無しさん:2017/08/20(日) 00:18:36.94 ID:4afFh/HS.net
>>618
テスト対象は今後変更することは無い?
もし変更するのであれば、テストコードはリグレッションテスト用として価値があるかと。

623 :デフォルトの名無しさん:2017/08/20(日) 00:29:40.53 ID:ye9mPKN8.net
>>622
変更するときは仕様を変えるときだろうな。
その時はテストも変えないといけないだろうね。

100行って意外と大したことないよ。
コマンドライン引数の処理部分で20行ぐらい使ってるし。
(当然ライブラリ使ってるのでここに条件分岐とかない)

624 :デフォルトの名無しさん:2017/08/20(日) 00:40:08.51 ID:PGSVSpKF.net
今ある機能はそのままで機能追加とかよくある事だと思うんだけど

625 :デフォルトの名無しさん:2017/08/20(日) 00:41:57.09 ID:ye9mPKN8.net
シンプルに単機能にしてるからなぁ。

全く別の機能を追加するぐらいだったら
別のツールにするし。

出来る限り機能は削ぎたいぐらい

626 :デフォルトの名無しさん:2017/08/20(日) 00:42:02.88 ID:PGSVSpKF.net
あと、テストを後から書こうとするから面倒くさいん

627 :デフォルトの名無しさん:2017/08/20(日) 00:54:04.14 ID:ye9mPKN8.net
というかクラスにも関数にもなってないようなもの
というかそうするまでもないような短いコードに
どうやってテストを書けばいいのかわからん

テストを書くためにわざわざ関数やクラスにして
モック使って倍以上の量にして
それを読めって言う方が大変だろう

628 :デフォルトの名無しさん:2017/08/20(日) 02:15:26.56 ID:4afFh/HS.net
>>623
あぁ、テスト対象って特定の機能じゃなくてクラスとかモジュールとかもっと大きな単位で考えてたわ。言葉足らずだったか。
今までの機能はそのままで追加機能とか別の機能の変更とかそういう時のリグレッションテストに役立つかと。

629 :デフォルトの名無しさん:2017/08/20(日) 04:05:43.40 ID:zvlsjK6m.net
テストはなくても簡単にサンプルが実行できるスクリプトとかは
書いておいた方がいいんじゃないの?

630 :デフォルトの名無しさん:2017/08/20(日) 05:56:24.39 ID:PGSVSpKF.net
ライブラリ使ってるというならそのライブラリの挙動含めて意図通りになってるかテスト書いておいた方がいいと思うけどね。
俺の環境では動いたは仕事では通らないし。
環境含めて提供するなら別だが、単機能のツールにDockerとか持ち出されても困るだろ。

趣味なら好きにしたらいい

631 :デフォルトの名無しさん:2017/08/20(日) 10:00:51.11 ID:dyFXBla+.net
100行程度のツールとかなら
・正常系
・ファイルがないとか読めない
・サーバーにアクセスできない
・...(ファイルの内容を色々)
程度のテストはする
よほど重要とか多数の人に配るとかでもない限りREST API のモックまではやらないな

632 :デフォルトの名無しさん:2017/08/20(日) 12:09:58.79 ID:8rqqhxmU.net
こいつは単にテストする気がないだけだろ

633 :デフォルトの名無しさん:2017/08/20(日) 12:24:27.07 ID:m30rRqux.net
いや、テストなら手動でやってるよ。

634 :デフォルトの名無しさん:2017/08/20(日) 12:27:14.87 ID:m30rRqux.net
良い例えを思いついたよ。

Dockerfileから呼び出す
エントリーポイントのシェルスクリプト

例えばこんなのな
https://github.com/docker-library/mysql/blob/e207dbbdfd5c95e4b51bdc2dae62c5f72a1dd908/8.0/docker-entrypoint.sh

これはループも条件分岐もある203行のコードだが
これに対するテストコード書くの?って話

635 :デフォルトの名無しさん:2017/08/20(日) 12:30:16.44 ID:8rqqhxmU.net
>>634
だからお前はここで何がしたいの?

636 :デフォルトの名無しさん:2017/08/20(日) 12:32:36.13 ID:m30rRqux.net
>>635
最初に書いてあるよね?

> やる価値ありますか?

637 :デフォルトの名無しさん:2017/08/20(日) 14:01:19.93 ID:t7S1uBht.net
>>636
誰にとっての価値を聞いてる?

638 :デフォルトの名無しさん:2017/08/20(日) 14:03:33.58 ID:m30rRqux.net
そりゃテストコードを書く場合と一緒だろ
お前は誰のためにテスト書いてるんだよ?

639 :デフォルトの名無しさん:2017/08/20(日) 15:08:35.49 ID:3YN/FpP2.net
>>634
俺なら書くよ。

逆に聞きたいけど、例えばその規模のコードを書くとき、全く動作確認もせずに0から全部書き切るの?
いや、動作確認はするよってことだったら、それはテストだよね。

640 :デフォルトの名無しさん:2017/08/20(日) 15:28:02.06 ID:m30rRqux.net
>>639
テストコードは書かないよ
実際に動かしてテストすればいい

641 :デフォルトの名無しさん:2017/08/20(日) 15:36:34.11 ID:3YN/FpP2.net
>>640
10行書く毎にテストするとして、最後の1回の動作確認は最後に書いた10行分の動作確認をするの?
それとも、今まで確認したこと全てやりなおすの?

前者だとしたら、今までOKだったものが動作しなくなっている場合に検知できないし、後者なら
動作確認に時間がかかりすぎる。

だから、俺たちはテストコードを書くんだ。

642 :デフォルトの名無しさん:2017/08/20(日) 15:44:22.01 ID:m30rRqux.net
> それとも、今まで確認したこと全てやりなおすの?

単機能なんで、今まで確認したことの全て=一つと言ってもいいぐらいなんだよw

643 :デフォルトの名無しさん:2017/08/20(日) 15:46:20.52 ID:m30rRqux.net
もちろん全く一つではないけどね。
オプションで-vをつけると詳細なログがでる。

というテストを書く?

オプションで--debugとつけると
デバッグログが出力される

というテストを書く?

--versionと書くとVERSION変数の中身を表示するだけ
というテストを書く?

644 :デフォルトの名無しさん:2017/08/20(日) 16:05:48.62 ID:3YN/FpP2.net
>>642
> 単機能なんで、今まで確認したことの全て=一つと言ってもいいぐらいなんだよw
いやいや、例えば>>634のコードなら、というのが前提の話だよ。

> というテストを書く?
書かないよ。
まぁざっくり言えばC0カバレッジで考えたときに、明らかに意味のないもの以外のテストを書くだろうね。

仮に_check_config(), _get_config()なんかがリファクタリング(重複コードのメソッド抽出)の
結果だとするなら、何度もテストできるテストコードがあってよかった、ってことになると思う。

645 :デフォルトの名無しさん:2017/08/20(日) 17:34:52.00 ID:P16figJJ.net
>>636
もうお前の中で結論出てるんだろ

646 :デフォルトの名無しさん:2017/08/20(日) 20:32:13.07 ID:UwJAOTbj.net
夏休みも終わりだな

647 :デフォルトの名無しさん:2017/08/21(月) 17:53:08.75 ID:/uRF2gxn.net
まあ短いコードでもネットワークアクセスやデータベースアクセスみたいに
副作用の強いものとつながってるんなら、
そういう部分をスタブで置き換えてテストできるくらいには
整えておくのもいいんじゃないかね。

648 :デフォルトの名無しさん:2017/08/22(火) 06:13:39.28 ID:cjA4wxxB.net
テストするかどうかも決まってないのに
方法に来てどうするんだ

649 :デフォルトの名無しさん:2017/08/22(火) 06:40:15.00 ID:kG/K9vWp.net
各々の中で決まってるだろ。

650 :デフォルトの名無しさん:2018/05/23(水) 21:54:18.74 ID:Au5e7VGg.net
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』

UZFWS

651 :デフォルトの名無しさん:2018/07/05(木) 00:08:07.11 ID:RfoszcD2.net
KWG

652 :デフォルトの名無しさん:2018/07/26(木) 19:44:42.33 ID:7pP0Ecr7.net
>>646
バカヤロウ、まだ始まってもいねぇよ!

653 :デフォルトの名無しさん:2020/06/14(日) 00:53:03.07 ID:5oNWegSg.net
イチカラツクリナオセ

654 :デフォルトの名無しさん:2020/06/14(日) 13:20:55.07 ID:m+2zmaXu.net
ユニットにできないなら結合した状態でテストするしかあるまい。
リファクタリングするなりして徐々にテスト範囲を小さくするが王道。

655 :デフォルトの名無しさん:2020/07/04(土) 07:57:34.91 ID:9B1sQRM5.net
ftpクライアントみたいなsocket通信を含むライブラリを開発しようと思ったらどうやってテストコード書きます?

2つソケット作って相互テストする?

656 :デフォルトの名無しさん:2020/07/04(土) 08:07:16.61 ID:gmurOIZf.net
一応別プロセス立ち上げてお互いに通信させるようなコード書くかな。

657 :デフォルトの名無しさん:2020/07/04(土) 08:28:39.39 ID:ewxE356G.net
テストしたいのが通信そのものじゃなくて自分のロジックならスタブやモックを使うのが良いんじゃね。
総コーディング量が多くなったり想定していない状況が漏れたりする可能性があるけど、逆に
想定できる状況なら網羅性を高くできるしテスト環境準備の手間も少なくなる。

658 :デフォルトの名無しさん:2021/05/25(火) 11:08:34.53 ID:6aeoZGgo.net
関数のアウトプットのオブジェクトがダイナミックに構造を変える時のパラメータ化テストが難しい

659 :デフォルトの名無しさん:2021/05/25(火) 19:59:55.83 ID:vDgp1zAi.net
>>658
いくら構造が変わるからといっても条件があるだろうから、その条件を固定して出力構造を固定化してやればよくね?

660 :デフォルトの名無しさん:2021/05/25(火) 20:15:23.88 ID:7xIwUOw5.net
>>659
条件固定でやるのは当然だけど
出力の構造が異なるとパラメータ化して一気にテストってのができない
構造ごとにテストケースを書かないといけない

661 :デフォルトの名無しさん:2021/05/30(日) 12:47:56.92 ID:sJ/lY+qu.net
外部APIクライアントのテストってどうやってんだ?
テスト専用アカウント作ってやるとか?

662 :デフォルトの名無しさん:2021/06/27(日) 10:51:06.30 ID:h2kpgEo5.net
>>661
インフラではなく、プログラミングレベルの妥当性確認がしたいのなら、フレームワークの機能を使ってテストするのが一般的じゃないかな。
やることは大抵、登録処理の実行、レスポンスの確認、データ取得処理の実行、レスポンスの確認、登録エラーが起こる処理の実行...をテストフレームワークが用意したライブラリを使ってゴリゴリテストコードに記述していくだけだけど。

当然、テストフレームワーク環境での実行なので、サーバーサイドは真っ白な状態からスタートする。

663 :デフォルトの名無しさん:2022/12/15(木) 16:54:51.27 ID:MV1x1AJa.net
夜間バッチのテストが難しすぎて困った
組み合わせ多すぎ、処理フロー複雑すぎでどうやってテストしたらいいか頭が追いつかない

664 :デフォルトの名無しさん:2022/12/15(木) 18:45:15.92 ID:kp2u5+JM.net
ログ仕込め

665 :デフォルトの名無しさん:2022/12/19(月) 11:53:17.90 ID:7xt1WnSN.net
ずっと悩んでるけど夜間バッチ処理のテストいまだにわからんすわ
ペアワイズ法とか色々小賢しいテクニックでテストケースを減らすことができることは学んだけど
それやった上でもまともに管理できるテストケース数じゃなくなるんだが…
マジでどうすりゃいいのさ

クラスが綺麗に分離しててそれぞれ独立にテストできればそうして結合は手抜きでも良いかなって考えたんだけど
コードをリファクタリングする権限なんて無いしな…

副作用はRDBだけだからインフラ周りで難しいことはないけど
単純にテストケース数が多すぎて手に負えない
みんなどうやって解決してんだろ

>664
ログ出力で何をするんですかね

666 :デフォルトの名無しさん:2022/12/19(月) 18:13:03.14 ID:KnS+FMSG.net
テストが難しいような単位で物を作っているからいけない。

667 :デフォルトの名無しさん:2023/03/21(火) 01:20:44.21 ID:PRQ38MNf.net
画面がないと動かせない
データベースがないと動かせない
切り離すのめんどくさい

668 :デフォルトの名無しさん:2023/06/06(火) 22:27:59.61 ID:jiKuTUOv.net
テストドライバやスタブの概念がないレベルか?

669 :デフォルトの名無しさん:2023/08/14(月) 10:18:51.03 ID:lHGygmd4x
最近地球破壊テ囗リス├税金泥棒自閉隊が都心付近まて゛クソヘリやらC-130やらクソ爆音航空機飛は゛しまくって低周波騒音引き起こしてるな
自閉隊とは,國民の生命と財産を守る存在て゛はなく、税金泥棒しながら、エネ価格に物価にと暴騰させて、住民の権利を強奪して破壞して
氣候変動させて災害連發させて國土まで破壞しながら私腹を肥やすテ囗リストの典型た゛と理解しよう!
ウクライナの軍事予算はGDΡ比4%以上あったわけた゛し.軍のク一テ゛ターによって政権掌握されたミャンマ‐はGDp比2%台.
徴兵して拒否すれは゛犬コ□公務員に制圧させて殺害可能な社會にしようとしてるのか゛防衛予算のために増税まて゛計画している岸田増税文雄
ちなみに,2014年にマレ―シア地球破壞テ口リス├機MH17を地対空ミサイ儿9K37フ゛━クて゛見事に撃墜したのは,戦闘民族ウクライナ人な
真の防衛として,利権を貪って税金泥棒して地球破壞して私権侵害して私腹を肥やすだけの人類に涌いた害蟲クソ公務員を全滅させて,
新≡種の神器、拳銃.スティンガ―、手榴弾を−刻も早く全家庭に普及させないとお前ら間違いなく口シア逃亡民みたいな目に合うぞ

創価学会員は.何百万人も殺傷して損害を与えて私腹を肥やし続けて逮捕者まて゛出てる世界最惡の殺人腐敗組織公明党を
池田センセ−が□をきけて容認するとか本氣で思ってるとしたら侮辱にもほどがあるそ゛!
hΤTРs://i,imgur.cоm/hnli1ga.jpeg

670 :デフォルトの名無しさん:2023/11/24(金) 04:33:48.06 ID:Jzh7gNS7X
池田犬作が死亡したわけだがマインドコントロー儿されてる創価学会員は一刻も早く統一教会のような返還請求しないと
私腹を肥やすためなら都心まで数珠つなぎで日本近海の海水温か゛突出して上昇するほど莫大な温室効果カ゛スまき散らして気候変動
魚は捕れない、農産物は壊滅、鳥ウイルスやら蔓延して鷄卵やら食糧価格暴騰、日本のみならず世界中て゛土砂崩れ、洪水.暴風、熱中症にと
災害連発させて世界中の住民の生命と財産を強奪して私腹を肥やす世界最悪の殺人テロ組織公明党強盗殺人の首魁蓄財3億円超の斉藤鉄夫ら
テロリストどもに俺も俺もと食い荒らされて10兆円の資産なんてあっという間に消滅するぞ、多額の金を払ってニ束三文の山奥の墓を買った
ジジババとか維持管理され続けるなんて甘いこと考えてんじゃねえた゛ろうな、さらに多額の管理費とか請求されてこれは金にならない
となれは゛とっとと切り捨て朽ち果て荒れ放題とても墓参りなんて不可能な状態になるのが目に見えてるわ
創価学会資産の実質的支配者は池田犬作なんだから相続税を課させるようお前らも運動しないとダメ絶対!
(羽田)ttps://www.сall4.jp/info.php?type=items&id=I0000062 , tTps://haneda-projecT.jimdofree.com/
〔成田)Тtps://n-souonhigaisosyoudan.amebaownd.com/
(テロ組織)tTps://i.imgur.com/hnli1ga.jpeg

225 KB
新着レスの表示

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

read.cgi ver 2014.07.20.01.SC 2014/07/20 D ★