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

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

1 :
2017/01/03(火) 14:50:44.83 ID:f6cee8Pv
ここで言うテストっていうのは
ユニットテストみたいなものね。

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


前スレ テストしにくいコードをテストする方法教えて下さい
http://echo.2ch.net/test/read.cgi/tech/1334408391/
2 :
2017/01/03(火) 18:00:08.97 ID:f6cee8Pv
例で考えよう。
private function numberOfFeet(動物) returns 脚の数
{
 if (動物 == 人) { return 2 }
 if (動物 == 犬) { return 4 }
 if (動物 == 猫) { return 4 }
 raise exception 知らない動物
}
っていう関数が既にあるとする。
3 :
2017/01/03(火) 18:00:28.68 ID:f6cee8Pv
その関数で対応する動物がもっと増えたとしよう。

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

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

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

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

カバレッジを100%にするためには必要?
それは "設計が悪いから" こうするしかなくなってしまってるんだよ
4 :
2017/01/03(火) 18:00:58.15 ID:f6cee8Pv
private関数がテストしたいと思ってきたら設計が悪いという話だったね。
この場合は、このprivate function numberOfFeetを
publicにしてテストするのではなくて設計を変えるってことだよ。

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

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

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

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

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

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

なぜならばLookupTableのテストはすでに書いているからだ。
おそらくこのコードは別のテストコード時に最低1回は通るだろう。
それでカバレッジは100%になる。いくら動物が増えたとしても
そのdataというデータ定義の行は通るのでカバレッジは100%のままだ。
5 :
2017/01/03(火) 18:01:14.98 ID:f6cee8Pv
これを手抜きやずるいやり方だと思うか?

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

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

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

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

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

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

ということでおしまい。
6 :
2017/01/03(火) 18:01:31.58 ID:f6cee8Pv
プログラム設計の善し悪しとテスト技法は密接に関係している。

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

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

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

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



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

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

だから一時的なテストコードになるんだよね。
7 :
2017/01/03(火) 18:01:50.63 ID:f6cee8Pv
あ、そうそう

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

このprivate関数へのテストはリファクタリングをしたあとの
テストコードのメンテナンスでなくなるという前提であれば
一時的にprivate関数へのテストコードを書くのはあり。
8 :
2017/01/03(火) 18:02:53.02 ID:f6cee8Pv
https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.md#testing-private-code

Testing Private Code

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

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

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

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

依然として内部実装コードをテストする必要がある場合は、そうする必要のない
優れた設計があるかどうかを検討してください。 しかし、非公開のインターフェイスコードを
絶対にテストしなければならない場合は、できます。
9 :
2017/01/03(火) 18:03:14.28 ID:f6cee8Pv
「privateだからテストしてはいけない」という意見はそもそも的外れで
テストすべきものがprivateという状態ができたら
それは設計がおかしいと気づかないといけない。

「privateだからテストしてはいけない」は単なる思考停止で
privateをテストしたいのは設計がまずいからだね、設計をなおそう。
という流れにならなければいけない。
10 :
2017/01/03(火) 18:03:37.53 ID:f6cee8Pv
http://higelog.brassworks.jp/1941

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

・昔はテストコードがメンテ対象であるという意識が薄かった
・見てすぐ分かるテストコードがよいという考えからコピペコードが非常に多かった
・テストコードがたくさんあることによって動きが取りづらくなり、変更コストも上がる
・素早く動きたいがためにTDDしているのにそんな皮肉な結果になってしまう
・たくさん書くのではなく必要十分書くことが大切
・書き散らすと「テストケース爆発」を起こす
・テストコードもメンテし続けるためにリファクタリングして行く必要がある
11 :
2017/01/03(火) 18:04:15.86 ID:f6cee8Pv
http://dev.classmethod.jp/testing/10_errors_about_unit_testing/
> 3.テスト対象が完璧な設計であるという勘違い
>
> ユニットテストを実践することによりプロダクションコードが
> 適切に修正されていく状態でなければなりません。
>
> ユニットテストの重要な目的のひとつに「テスト対象クラスやメソッドの
> 使用感を把握する」ことがあります。机上の設計やフィーリングだけで
> 書いたコードは、使ってみての違和感や使いにくさに気付き難いものです。
> それらの使用感は、実際に利用してみてはじめて気付きます。
> だから、テストコードを書くことで実際に利用してみます。これはサンプルコードを書く事に他なりません。
>
> サンプルコードを書くと、「これは使いにくい」と感じたり、
> 「これはこうした方が使いやすい」と感じたりします。それはユニットテストの
> 大きな効果です。もし、使いにくいと感じたならば、すぐにテスト対象を修正します。
> テスト対象が完璧な設計で変更する余地が全く無い、または変更し
12 :
2017/01/03(火) 18:04:36.15 ID:f6cee8Pv
これも関連する話。まずリファクタリング後にテストを変更するのは当然

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

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

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

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


こうやってヘルパークラスや親クラスに処理を移動して、それに対するテストを書くことで
それを使用している部分ではテストが不要という状態を作り上げることが重要
13 :
2017/01/03(火) 18:05:03.70 ID:f6cee8Pv
privateメソッドに対してテストをしたくなっったら
それはクラスが肥大化してる証拠だよ。

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

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

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

privateメソッドをテストしたいっていうのは、作り方が悪いんだよ。
14 :
2017/01/03(火) 18:06:10.26 ID:f6cee8Pv
ある程度埋めないと落ちるといわれたので、
前スレのハイライト(笑)をコピペ
15 :
2017/01/03(火) 18:45:05.85 ID:mYtDE+67
なめてんの?
16 :
デフォルトの名無しさん
2017/01/03(火) 19:23:41.90 ID:Oj8nbLhF
>>13
>privateメソッドをテストしたいっていうのは、作り方が悪いんだよ。

バカ丸出し。
privateメソッドだからといって十分にunit testingしない奴は頭が悪いんだよw
privateメソッドがあるからといって設計のせいにするのは性格が歪んでんだよw
privateメソッドをテストする技術を持たないからといって
出鱈目な ”あるべき論” を捏造する奴は技術者としての道徳が欠如してるんだよw
17 :
2017/01/03(火) 22:27:14.69 ID:f6cee8Pv
>>16
お前日本語がわかってないなw
18 :
2017/01/04(水) 09:28:49.04 ID:cRY9oGv2
privateメソッドとテストに相関はありません
リファクタリングのスレに移動してください
19 :
2017/01/04(水) 14:06:42.84 ID:mEkZwZd0
>>13
馬鹿丸出し
頭固すぎ
20 :
2017/01/04(水) 14:10:32.56 ID:mEkZwZd0
>>9
> テストすべきものがprivateという状態ができたら
> それは設計がおかしいと気づかないといけない。
という思考停止にきづかない馬鹿pgr
21 :
2017/01/05(木) 04:41:00.85 ID:4wDE4Xcp
当のKentは ID:f6cee8Pv みたいな教条主義とは対極にいるんだがな。
22 :
2017/01/05(木) 07:46:32.69 ID:SvuiXrcs
>>21
どこが?
https://twitter.com/kentbeck/status/3579860805

2chのレスだけで知ったかぶってる、まさに半可通
この手のクズは他分野でも同様なのだろうが、
本も読まず、手も動かせない人間なんて、
職人気質なTDD実行側の人間が、一番嫌うタイプだぞ
23 :
2017/01/05(木) 07:59:15.46 ID:SvuiXrcs
むしろつまみ食いしかしてないくせに、拡大解釈して腐ったコード撒き散らすな
ケントベックはXPは熟練者が必要とは言ってるだけで、手法は何でも良いなんて言ってない
テストコードも、trivialな物は不要、複雑なprivateメソッドは設計が悪いと一蹴してる
これを教条主義だと言うなら、レッテル張る事しかできない屑だな
24 :
デフォルトの名無しさん
2017/01/05(木) 08:26:33.27 ID:rS/TqFdr
前スレでprivateメンバーしか見ずにそれをテストしようとしたり、考え方がおかしい。

あと、Kent Beckはテストは不要だと思ったらやらない、と言うぐらい柔軟な思考の持ち主だぞ
25 :
2017/01/05(木) 09:16:09.02 ID:qUpJhZLr
前スレ埋めてからやってくれ。
26 :
2017/01/06(金) 14:09:56.36 ID:jUueQ44/
>>23
> 複雑なprivateメソッドは設計が悪いと一蹴してる
ソースは?

>>22のtweetがそれだとしたら、その会話の流れが設計の善し悪しであることを示す他のtweetも示せ
27 :
2017/01/06(金) 14:31:04.58 ID:jUueQ44/
Kent BeckはImplementation Patternsの中でこう言ってる

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

* Method Visibility
* Make methods as private as possible.

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

別に、private classやprivate methodを否定しているわけではない
28 :
デフォルトの名無しさん
2017/01/06(金) 15:00:59.05 ID:ueXke68e
公開する必要のないprivateメンバーをpublicにしてまでテストするなんて真逆の発想なんだよなぁ
29 :
2017/01/06(金) 15:23:30.30 ID:jUueQ44/
>>28
まあ、そのprivateメソッドが、所属するクラスと直交していて再利用可能な内容だった場合は
別クラスにpublicメソッドとして切りだすのもいいけど、いつでもそうとは限らないからな
30 :
2017/01/06(金) 16:24:11.26 ID:bv2F1pCR
31 :
2017/01/06(金) 19:55:59.99 ID:SxMvRiz3
飽きてきたので以降privateの話題禁止
32 :
2017/01/06(金) 21:44:03.66 ID:IT5nhYwQ
>>27
レスをよく読め文盲め
言ってもいない事を言ったかのように叩くやつがあるか
33 :
2017/01/06(金) 21:44:44.23 ID:IT5nhYwQ
>>26
勝手に追えばいいだろ
くだらない人種だな
34 :
2017/01/07(土) 01:43:02.53 ID:jcRWOLCk
結局世界的有名人であるKent Beckが言ってることは
>>1がまとめたとおり。

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

悪い設計を直す過程でpublicになる。
設計を直さなないで単にpublicに変更するのは間違い。
35 :
2017/01/07(土) 07:12:47.19 ID:0cNXAmIk
>>34
まだそんなこと言ってんの?ばかだなあw
36 :
2017/01/07(土) 07:22:58.29 ID:55rirhTJ
そこで#define private publicですよ。え?
37 :
2017/01/07(土) 08:54:35.16 ID:bP0cwlRr
publicメソッドしかテストできない道具を使ってprivateメソッドをテストすることはできない。
一種のトートロジーだな。
38 :
2017/01/07(土) 12:20:08.80 ID:HNCUhS1Q
前スレ埋めてからやれ
こういう奴らが糞コードを放りっぱなしにしていってこっちが掃除しなくちゃならなくなるんだよ
バグ解析依頼されて見てみたら、意識だけ高いけどそのまま放置されたゾンビコードに当たったときの腹立たしさって
まあお前らのおかげでちょっといい飯が食えるんだから感謝しないといけないな
39 :
2017/01/07(土) 13:20:41.90 ID:jcRWOLCk
>>35
悔しいなら反論しろよw
40 :
2017/01/07(土) 19:21:41.83 ID:adAq7wbq
今現在を占う 2017/1/7 19:21

おみくじ 大吉 →  ♌ 獅子座
.      吉   →  ♈ 牡羊座 ♋ 蟹座   ♓ 魚座 
.      中吉 →  ♏ 蠍座 
.      小吉 →  ♉ 牡牛座 ♍ 乙女座 ♎ 天秤座 ♒ 水瓶座
.      末吉 →  ♊ 双子座
.      凶   →  ♐ 射手座
.      大凶 →  ♑ 山羊座
41 :
2017/01/08(日) 09:54:40.93 ID:qkk6ZrX+
吉だぜ、いやっほーい
42 :
2017/01/08(日) 09:54:57.91 ID:qkk6ZrX+
あ、昨日か.....
43 :
2017/01/09(月) 20:16:25.89 ID:pl8AdjB2
今現在を占う  2017/1/9 20:16  (不定期テスト)

おみくじ 大吉 →  ♍ 乙女座 ♑ 山羊座
.      吉   →  ♉ 牡牛座 ♎ 天秤座 ♒ 水瓶座
.      中吉 →  ♋ 蟹座 
.      小吉 →  ♈ 牡羊座 ♏ 蠍座 
.      末吉 →  ♌ 獅子座
.      凶   →  ♊ 双子座 ♐ 射手座
.      大凶 →  ♓ 魚座 
44 :
2017/01/11(水) 00:09:48.89 ID:ha9kcMkV
あんまり可視性でグダグダ言っても揉め事しか起こらん印象は有る。
だからあんまりカプセル化周りの議論は好きではない。
重要なのはテストするコードの粒度じゃないかね。
3 のレベルのコードをテストするのは粒度が細かすぎる。
3のコードを呼んで何かしてるコードのテストコードを書くべきなんだろう。
45 :
2017/01/11(水) 23:15:37.40 ID:1SbN3a75
端折って網羅性が確保できなくなるのであればそもそもこのテスト自体イラネーってのあるよ
だからやるなら機械的に全部やるかそもそもやらないかのどっちかになると思う
46 :
2017/01/11(水) 23:16:53.94 ID:1SbN3a75
あ、Visual Studioのユニットテスト的な話ね
47 :
2017/01/12(木) 00:02:44.60 ID:qhQd7W/g
>>46
2017のlive unit testのことを言ってる?
48 :
2017/01/13(金) 06:48:56.80 ID:tNTQooLV
>>44
しょうがないよ、ID:f6cee8Pvの能力ではそこが限界・・・
49 :
2017/01/13(金) 23:07:22.63 ID:9L2JHio8
>>48
呼んだか?

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

今のところ俺の書き込みに論理的に反論している
文章は存在していない。
50 :
2017/01/13(金) 23:40:30.59 ID:2oF12qKz
テスト
○○○●○○○○○○○○●○○○○○○○○●
○○○●○○○○○○○○●○○○○○●●●●●●●
○○○●○○○○○●●●●●●●○○●○○○○○●
○●○●○●○○○○●○○○●○○○○●●●●●○
○●○●○●○○○○●○○○●○○○○○○○●○○
○●○●○○●○○○○●○●○○○○○○○●○○○
○●○●○○●○○○○●○●○○○○●●●●●●●
●○○●○○●○○○○○●○○○○○○○○●
○○○●○○○○○○○●○●○○○○○○○●
○○○●○○○○○○●○○○●○○○○○○●
○○●●○○○○○●○○○○○●○○○○●●

○○○○○○○●○○○○○○○○○○○○○○○○●○○○○○○○○○○○○○○○○●
○○○○○○○●○○○○○○○○○○○○○○○○●○○○○○○○○○○●●●●●●●●●●●●●●
○○○○○○○●○○○○○○○○○●●●●●●●●●●●●●●●●○○●○○○○○○○○○○○○●
○○○○○○○●○○○○○○○○○○○○○●○○○○○○●○○○○○○●○○○○○○○○○○○○●
●●●●●●●●●●●●●●●●○○○○○●○○○○○○●○○○○○○○○●●●●●●●●●●
○○○○○○○●○○○○○○○○○○○○○●●○○○○●●○○○○○○○○○○○○○○○●●
○○○○○○●●●○○○○○○○○○○○○○●○○○○●○○○○○○○○○○○○○○○●●
○○○○○○●○●○○○○○○○○○○○○○●●○○●●○○○○○○○○○○○○○●●
○○○○○○●○●●○○○○○○○○○○○○○●○●●○○○○○○○●●●●●●●●●●●●●●●●
○○○○○●●○○●○○○○○○○○○○○○○○●●○○○○○○○○○○○○○○○●
○○○○○●○○○●●○○○○○○○○○○○○●●●●○○○○○○○○○○○○○○●
○○○○●●○○○○●●○○○○○○○○○○●●○○●●○○○○○○○○○○○○○●
○○○●●○○○○○○●●○○○○○○○○●●○○○○●●○○○○○○○○○○○○●
○○●●○○○○○○○○●●○○○○○●●●○○○○○○●●●○○○○○○○○○○●
●●●○○○○○○○○○○●●●○●●●○○○○○○○○○○●●●○○○○○○●●●
51 :
2017/01/16(月) 23:19:44.60 ID:9FmOEppL
>>48
お前ってプログラムに限らずいつも的はずれな難癖しかつけないよな
52 :
2017/01/21(土) 00:48:16.31 ID:EhyrNbEj
>>49
>>27に論理的な反証があるだろw
ほんとに頭悪いのな
Kentの書いてる英語のとこだけ読み直してお前自身の矛盾に気がつけないの?
53 :
デフォルトの名無しさん
2017/01/21(土) 06:46:40.76 ID:gnjAlXGF
>>52
前スレでもそうだったけど、彼は都合の悪いレスは目に入らない人だから何言っても無駄
54 :
2017/01/21(土) 13:01:41.54 ID:sMDuy5hJ
>>52
それのどこが論理的な反証?

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

Kent Beckのどこにprivateメソッドの話が書いてあるんだ?
55 :
2017/01/21(土) 13:28:19.57 ID:zMOHiEOd
くすくす…
56 :
2017/01/21(土) 13:47:45.70 ID:EhyrNbEj
残念な頭だな
57 :
2017/01/21(土) 13:58:00.26 ID:sMDuy5hJ
反論お待ちしてまーすw
58 :
2017/01/21(土) 14:03:40.46 ID:EhyrNbEj
Kentの引用読んでも矛盾に気づけない残念さ
ひとりだけ斜め上
59 :
2017/01/21(土) 14:04:25.54 ID:sMDuy5hJ
時間が相手勘違いされかねんから俺の意見を書いておくか

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

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

そうすればpublicメソッドをテストすれば良くなる。
60 :
2017/01/21(土) 14:04:58.86 ID:sMDuy5hJ
>>58
俺の意見とどう矛盾するのか言ってみな
61 :
2017/01/21(土) 14:05:54.01 ID:EhyrNbEj
脳が単純だから単純な考え方に縋っちゃうんだろうね
それがたたって物事を複雑にする
62 :
2017/01/21(土) 14:07:22.70 ID:sMDuy5hJ
脳が単純だとprivateメソッドのテストコードの話をしていたのに
privateメソッドを作っていいかどうかの話に
単純化(笑)されるんだろうね。
63 :
2017/01/21(土) 17:46:46.32 ID:O/GZ8TN6
クラス自体がウンコ

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

ID:sMDuy5hJ は「製品コードにテストコードが混在するのは良くない設計だ」とでも言うだろうか。
65 :
2017/01/21(土) 20:08:55.14 ID:sMDuy5hJ
>>64
なんか罠張ってますぜって臭いがプンプンするなw
俺からなんて言葉を引き出したいのさ?

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

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

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

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

> 「(優れた)製品コードにテストコードが混在するのは良くない設計だ」とでも言うだろうか。
あぁ、そのとおりだ。何か言いたいことがあるならどうぞ
66 :
デフォルトの名無しさん
2017/01/21(土) 21:01:47.67 ID:gnjAlXGF
sqliteみたいな例外はあるけど一般的にはそこまで書かない、全てのコードに対してsqlite並みにテストコード書いてたらプロジェクト終わらんよな
67 :
2017/01/21(土) 21:22:40.22 ID:ij3ZsOnR
>> 「(優れた)製品コードにテストコードが混在するのは良くない設計だ」とでも言うだろうか。
>あぁ、そのとおりだ。何か言いたいことがあるならどうぞ

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

そのへん曖昧なまま「privateメソッドをテストしようとするのは設計が悪い」と主張しても、
証明になってないという突っ込みする奴はいるかもしれないが、それ以上反論は
しようがないわな。
68 :
2017/01/21(土) 22:36:34.80 ID:sMDuy5hJ
>>66
> sqliteみたいな例外はあるけど一般的にはそこまで書かない、全てのコードに対してsqlite並みにテストコード書いてたらプロジェクト終わらんよな

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

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

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

だから言うんだprivate関数をテストしたいと思ったら
設計が悪いだけだってこと。
69 :
デフォルトの名無しさん
2017/01/21(土) 22:37:51.39 ID:gnjAlXGF
>>68
それは汎用ライブラリーを作らない人の立場での話だな。
70 :
2017/01/21(土) 22:40:50.50 ID:sMDuy5hJ
>>67
> 問題はこんな単純なことですら「良い設計」の定義が一致しないということ。

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

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

俺が言ったのは「製品コードだからって良い設計ということにはならない」と
言うこととと「悪い設計」の話だけなんだがちゃんと理解できてないのか?
そういやprivate関数をテストしたくなったらそれは「悪い設計」とも言ったな。
71 :
2017/01/21(土) 22:41:52.89 ID:sMDuy5hJ
>>69
> それは汎用ライブラリーを作らない人の立場での話だな。

汎用ライブラリを作る人の立場の君に聞きたい。
世の中でよく使われている汎用ライブラリで
sqlite並みにテストコードを書いてないライブラリはどれだ?
72 :
デフォルトの名無しさん
2017/01/21(土) 22:55:22.41 ID:gnjAlXGF
>>71
一杯あるとおもうけど、それを聞いてどうすんだ?
73 :
2017/01/21(土) 23:08:11.88 ID:sMDuy5hJ
>>72
どうするんだと言われてもね。

よくテストされてる汎用ライブラリを使いましょうという
当たり前のことしか言わないよ。
74 :
デフォルトの名無しさん
2017/01/21(土) 23:12:54.46 ID:gnjAlXGF
えっ、話を逸らしただけ?
75 :
2017/01/21(土) 23:16:13.67 ID:sMDuy5hJ
>>74
話をそらしたのはお前じゃね?
俺は>>68でちゃんと会話をしている。

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

俺は話を>>68に戻しただけ。
わからないならここに>>68の内容を
コピペしてやっても良いんだぜ?
76 :
デフォルトの名無しさん
2017/01/21(土) 23:21:02.28 ID:gnjAlXGF
>>75
ああ、そういうことか、sqliteがどんなテストコード書いてるか見たらprivateをpublicにするとか言えないと思うんだけど、すまんねその前提で言ってたわ
77 :
2017/01/21(土) 23:23:43.91 ID:sMDuy5hJ
みんなsqliteのテストコード見なくていいぞw
どうせこいつが言ってるだけのことだから。
78 :
デフォルトの名無しさん
2017/01/21(土) 23:36:56.46 ID:gnjAlXGF
まあ見なくて良いよ。普通のプロジェクトにとっては間違いなく過剰だから。
本体のソースコードの行数が122.9Kのところテストのコードとスクリプト含めて91596.1Kらしいから。
ちなみに内部でassertも大量に書いてる。
79 :
2017/01/21(土) 23:41:58.25 ID:sMDuy5hJ
それが今までの話、
privateメソッドをテストしたくなったら
設計が悪いって話と何の関係があるのかな?
80 :
2017/01/21(土) 23:43:42.51 ID:ij3ZsOnR
>>70

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

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

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

1.や3.に反論しようと思ったら設計が良い/まずいの定義に踏み込まざるを得ない。
81 :
デフォルトの名無しさん
2017/01/21(土) 23:59:42.25 ID:gnjAlXGF
他人に使われるものを作ってるんだったら必要ないものまでpublicにする(外部に公開する)のは良くないよ。
なのでaもbもどっちもダメ
82 :
2017/01/22(日) 01:41:32.45 ID:etjPL+qg
>>81
他人ってどういう意味?
その文脈で何故他人が出てくるの?

もしかしてpublicメソッドの話をしているのに、
一般用語のパブリック(大衆の、公共の、公衆の)と間違えちゃった?
だとしたら恥ずかしいね。
83 :
デフォルトの名無しさん
2017/01/22(日) 04:45:25.75 ID:77/TNfJH
>>82
何故他人が出てきたらいけないの?
あなたは自分しか使わないものしか作らないの?
84 :
2017/01/22(日) 05:34:13.73 ID:etjPL+qg
>>83
もしかして図星だった?
質問にちゃんと答えようね

もしかしてpublicメソッドの話をしているのに、
人間に対して使う用語ののパブリック(大衆の、公共の、公衆の)と間違えちゃった?
85 :
2017/01/22(日) 05:37:05.25 ID:bK3k81d3
>>80
publicにしなくてもテストできるやろ
86 :
デフォルトの名無しさん
2017/01/22(日) 07:00:17.67 ID:gigvK4EO
>>84
いや、間違えてないけど?
87 :
デフォルトの名無しさん
2017/01/22(日) 07:12:24.26 ID:gigvK4EO
逆に聞きたいんだが、使う人を考えてクラス設計するのがそんなに不自然か?
意味不明な解釈してると決め付けるぐらいに
88 :
2017/01/22(日) 07:13:16.92 ID:etjPL+qg
じゃあ自分しか使わないものは
全部privateにするわけね。

自分っていうのは人間の話ね。
89 :
デフォルトの名無しさん
2017/01/22(日) 07:17:40.52 ID:gigvK4EO
>>88
自分しかつかわないなら好きにすればいいんじゃない?それこそ全部publicでも誰も文句言わない
90 :
2017/01/24(火) 12:54:18.38 ID:QA0ZcG3O
自分しか使わないからprivateって、なんてクソな設計なんだろうw
91 :
2017/01/24(火) 20:35:15.30 ID:dMWZcDP0
むかしオブジェクト指向システムの設計ってスレで
将棋の例を出して暴れてたやつにそっくりだなw
92 :
2017/01/24(火) 21:30:19.03 ID:8U3NWpZ6
むしろ自分しか使わないならpublicでええやん
93 :
デフォルトの名無しさん
2017/02/06(月) 23:15:46.42 ID:Z4T16Vvy
設計的な公開/非公開はpublic/privateで分ける
人に対しての公開/非公開はスコープで分ける
94 :
2017/02/07(火) 08:52:53.46 ID:SRenyBWg
>>93
それって逆でもいいんじゃね?
95 :
2017/02/07(火) 08:59:32.21 ID:ppv+uzEt
開発者が俺とお前の2人ならそれでも良いかもな
96 :
2017/02/08(水) 01:47:58.35 ID:oZ8qLhDf
>>4

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

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

あなたの実装漏れを知った顧客は、あなたの報告するカバレッジが100%であることに何の意味もないことを知り、あなたの報告に疑いを持つようになりました(ちゃんちゃん)
97 :
2017/02/08(水) 03:00:48.24 ID:nBuIwUQ3
>>4じゃないけどさ
カバレッジ100%にしても実装漏れは検出できないって当たり前でしょ…
98 :
2017/02/08(水) 03:33:50.20 ID:EqksEKaR
>>96
じゃあお前への宿題な

他の自動車に後ろから追突されたときはエアバッグは意味が無いことを知りました。
エアバッグによる安全性に意味が無いことを知り、あなたは安全装置をすべて外しました
そしてあなたはエアバッグで助かる事故で死にました(ちゃんちゃん)
99 :
2017/02/08(水) 03:38:50.66 ID:EqksEKaR
馬鹿・・・カバレッジが100%ということはバグがないということだ
普通・・・カバレッジが100%ということはすべての行を実行する程度のテストはしているということだ。


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

自分の間違った考え(カバレッジ100%は完璧)を自分でそれは間違いだって
ツッコミを入れているだけである。マッチポンプ
100 :
2017/02/08(水) 03:39:18.59 ID:nBuIwUQ3
出題しろよ
101 :
2017/02/08(水) 04:48:48.06 ID:q7Bk+Pyw
たかがC0のカバレッジ100%を特別なことだと思ってるバカって、>>4のことだよな?
102 :
2017/02/08(水) 07:54:35.87 ID:oZ8qLhDf
>>98
>>99

なんだ。答えられないのか。おまえクビなw
103 :
2017/02/08(水) 08:23:37.62 ID:J/owSyuZ
>>4の話でLookupTableクラスを分離するというのが「良い設計変更」だとして、じゃあそれを
使用するクラスの内部クラスにしたらその設計は良いままなのか、あるいは悪くなった
ことになるのか、って疑問はあるな。
104 :
デフォルトの名無しさん
2017/02/08(水) 09:34:33.51 ID:3ajnzt+4
>>97
動物が増えてもテスト不要と言っちゃってる >>4 に言えよ
105 :
2017/02/08(水) 10:58:26.85 ID:WP/XTf2I
>>4
> 動物が増えたら?などということを考える必要はない。
はたして、そうだろうか

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

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

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

> なぜならばLookupTableのテストはすでに書いているからだ。
LootupTableのテストは書いていても、data定義(初期化)行はテストできてないね
106 :
2017/02/08(水) 22:49:03.07 ID:EqksEKaR
>>105

> をやってれば、バグを検出できたのに
残念。それを忘れたらバグは検出できませんね
107 :
2017/02/08(水) 23:29:11.39 ID:b6dR+iVQ
くだらないこと言ってないでコード書けってよく言われてるんだろうな。
108 :
デフォルトの名無しさん
2017/02/09(木) 00:22:21.28 ID:lnTHGhne
>>106
この場合は忘れてもカバレッジが教えてくれるだけマシだったんじゃない?コードの見やすさは知らんけど
109 :
2017/02/09(木) 06:51:39.40 ID:IOSaScxB
>>106
テスト設計しないんですか?
110 :
2017/02/09(木) 13:02:15.28 ID:dfCX7ZDm
>>106
テストが不要だということの反論に対して、テストを忘れたらバグを検出できないとか言われても困惑するのみ
111 :
2017/02/09(木) 17:06:47.27 ID:EPpoXydB
> data = {人: 2, 犬: 4, 猿: 4, キジ: 2, 猫: 4}
こんな増えてくと予想できるリストなんかは外部ファイルにしとけよ
後は必要なら勝手にファイルに追加してねって責任を誰かに丸投げできれば重畳
テストもそいつに丸投げできる
112 :
デフォルトの名無しさん
2017/02/09(木) 21:32:56.16 ID:l61bzEJu
テストしにくいコードを書くのがおかしい。
113 :
2017/02/09(木) 21:39:55.38 ID:UTxumv29
残念ながら世間ではおかしいことがまかり通っててそれを修正する必要がある。
114 :
2017/02/09(木) 22:37:41.43 ID:V+qaSj6I
テストし易い部分のコードなんて誰でも書ける
115 :
デフォルトの名無しさん
2017/02/10(金) 00:43:43.40 ID:/WxwB06L
>>114
矛盾
116 :
2017/02/10(金) 14:03:12.42 ID:0nwBBEN6
コードを選ぶようなテストフレームワークが悪い
117 :
2017/02/10(金) 19:11:46.63 ID:+HewTgrG
じゃあ作ろっか
118 :
2017/02/15(水) 20:12:18.71 ID:rWNVJqHz
>>115
矛盾というかジレンマですな。
119 :
2017/02/17(金) 01:13:32.33 ID:ZnfoQYBi
要件や設計に書いてあることをただ満たせばいいのに、
何だテストしにくいコードって。
120 :
2017/02/17(金) 01:34:44.39 ID:EzDq9nSn
>>119
自動テストができないコード
自動テストをやろうとしたら組合せ爆発を起こして
時間がかかりすぎるコードだよ
121 :
2017/02/17(金) 04:11:34.18 ID:cVLy1vhF
>>119
ばーか
122 :
2017/02/17(金) 08:05:23.30 ID:LsFaYFdt
>>119みたいなマがいるから困る

後々の工程や運用段階でバグが見つかっても
困るのはオレじゃないから、とか考えてるんだろうな
123 :
デフォルトの名無しさん
2017/02/17(金) 10:14:12.44 ID:rxbbpEDv
>>119 はいきなりシステムテストレベルを行う人間なんだろうね。

それだと小さいバグ、作り上の問題に気づかない。
124 :
2017/02/22(水) 13:30:52.81 ID:nFPUHBlJ
>>120
組み合わせ爆発は、自動テストが原因じゃないよね。
逆に組み合わせ多数でマニュアルだと時間がかかりすぎて繰り返し実行できないなら、
自動テスト化を考えたほうが良い。
125 :
2017/02/22(水) 20:23:22.44 ID:Ameqiwj8
自動テスト使って開発したこと無いだろお前
組み合わせが多過ぎるなら組み合わせが減るようにバラすのが先だわ
126 :
2017/02/23(木) 10:38:26.31 ID:5OVH7aZj
>>125
全組み合わせだと1億通りなのを、オールペア法や直交表で100通りくらいまでに減らすのは基本
さらにその100通りをマニュアルで実行すると時間がかかるのなら、自動化すべき
ということだよ

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

とか、こんな説明書くの疲れるわー
127 :
2017/02/23(木) 14:42:20.90 ID:iUfvCfTM
やっぱり分かってねえ…
テスト技法の前に設計を何とかしろ
128 :
2017/02/23(木) 14:59:39.53 ID:5OVH7aZj
>>127
あのねぇ・・・
俺は>>120の内容が間違ってると言いたいのだよ・・・
糞設計が原因のテスト困難性の話なんかしてないわ・・・
129 :
デフォルトの名無しさん
2017/02/23(木) 15:11:55.49 ID:sZtROie8
>>128
ほっとけよ、どうせprivateをpublicにするとか言ってた奴だろ
相手を解ってない事にして見下したいだけのやつだよ
130 :
2017/02/23(木) 18:15:47.32 ID:eyTAmQSH
今時、1億通りぐらいで自動化できないとか、どれだけヘッポコなんだろw
131 :
デフォルトの名無しさん
2017/02/23(木) 20:44:47.41 ID:4lIYYkyp
ぼこぼこにされた>>119が噛み付いて回るスレをお楽しみください
132 :
2017/02/25(土) 11:41:05.47 ID:7KoBIFTE
どうした?力技でテストすればいいんじゃないのか?w
58KB

新着レスの表示

★スマホ版★■掲示板に戻る■全部前100次100最新50

名前:E-mail: