■短い回答
プライベートをテストしたい場合は設計に問題があるので、パブリックに変更してテストしましょう
■これに対する（変な人の）驚いた反論
プライベートを一時的にパブリックにして、テストが終わったら
プライベートに戻すなんてやるわけないだろｗ
↑誰もそんなコトしろなんて言ってない
■テスト専門家による回答
t-wadaのブログ
https://t-wada.hatenablog.jp/entry/should-we-test-private-methods
短くまとめると、プライベートなメソッドのテストを書く必要は 無い と考えています。
ほとんどのプライベートメソッドはパブリックメソッド経由でテストできるからです。
プライベートメソッドは実装の詳細であり、自動テストのターゲットとなる「外部から見た振る舞い」ではありません。
プライベートなメソッドのテストに関しては、4つの考え方があります。
・パブリックメソッド経由でテストする
・別クラスのパブリックメソッドとする
・テスト対象の可視性を（やや）上げる
・プライベートのまま、リフレクションでアクセスしてテストを書く
パブリックメソッド経由でテストする
多くの場合、そのクラスのパブリックメソッド経由でプライベートメソッドのテストも同時に行えます。テストできているか不安があるならテストカバレッジを確認しましょう。
別クラスのパブリックメソッドとする
プライベートなメソッドのテストを書きたいということは、実はテスト対象の責務が多すぎることを示唆している場合があります。
テストがどうしても書きたい場合は、その責務はテスト対象のプライベートな振る舞いではなく、他の誰かのパブリックな振る舞いなのでしょう。 クソコード例。こんなコード書いてるやつが、privateのテストで
パブリックに変更してテストするのはおかしいとか言ってる（笑）
lenが配列（笑）理由 int型にはnullが入れられないから（笑）
http://2chb.net/r/tech/1592491656/805
ずれるかもしれないが下のような場合、privateにnullを突っ込んだらヌルポだが
privateをわざわざコード弄ってまで別にテストするようなことは少なくとも
ビジネスソフトでは知ってる限り無い。組み込みとかは知らんし必要ならやれば良いけど。
class ChinTester {
public void testChin(int[] len) {
if (len==null){System.out.println("You are a woman");
return;}
if (len.length<11){ uncS(len);}
else{funcB(len);}
return;}
private void funcS(int[] len){
if (len.length<9){System.out.println("Smallest");
}else{System.out.println("Smaller");}
return;}
private void funcB(int[] len){
if (len.length<14){System.out.println("Medium");}
else if (len.length<16){System.out.println("Bigger");
}else{ System.out.println("Wow!");}
return;}
} 983 名前：デフォルトの名無しさん[] 投稿日：2020/07/05(日) 14:18:27.81 ID:9F15TCk0 [68/74]
正直あの短さでOOかどうかと（スタティックでインスタンス化もないコードだが）言うのは
不毛だけどID:JiRnWiGCの組み込みおじさんのがOO感はあるよ。
で、staticで出されてもprivateのテストがどうかと言う話には全く寄与しないわけだが、
じゃあ逆に、>>805のチンコテストのfuncSとfuncBはどうやってテストするの？
パブリック経由で全パターンと言うことならこれでこの話はおしまい。
パブリック経由でやりましょう。
違うと言うなら具体的にコードでおながいします。 >>5の補足、これはまだプライベートですが
普通はMainクラスにコードをごちゃごちゃ書かないので
judgeLengthを含むクラスを作成します。
そしてmainから呼び出します。
必然的にjudgeLengthメソッドはパブリックになります。 >>6
judgeLengthをpublicにしてよいかどうか、オブジェクトをわけて良いかどうかは微妙なところで
publicにした場合って他のオブジェクトからも参照可能になってしまうので
そこの依存があとあとjudgeLengthの修正をできなくする可能性があるので
privateにするっていうのは他のオブジェクトから依存させないようにして独立させる意味もあるので
テストするためにpublicにしますっていうのは僕はやっぱり反対ですね 僕が書いたように同じオブジェクトにテストコードも書いちゃえば良いと思います
>>7
微妙でもなんでもねーよ
Mainクラスに関係ない処理を入れるな
これは小さいサンプルだが、大きくなった時
Mainクラスに、そんな処理はいってたらおかしいだろ
なんで（大きくなったコードの）その他の部分は別のクラスにあるのに
この処理だけMainクラスにあるんだ？って >>9
Mainクラスと関係ある処理だからMainクラスにあるんじゃよ
Mainクラスからしかアクセスしないからprivateなんじゃよ
テストするためにpublicにするのはおかしいのじゃよ >>10
Mainクラスと関係ある処理だから？
じゃあ名前が悪いよね。
誰が「Mainクラス」と聞いて
その中にある処理を想像できるんだ？ｗ >>11
えっと、前にも言ったけどpaizaはMainという名前じゃないと動かないんだよ
Mainとわけてクラスを作ることもできるけど面倒だからやらなかっただけ
普通のプログラマならpaizaの制約ぐらい知ってるだろうし説明する必要もないと思ってた
君の無知さを想像できなかった僕のミスだ >>12
だから分けろって。設計がおかしいだろ。
Mainクラスにメインの処理を入れるな
設計が悪いって言ってるのになんで理解できない？ プライベートをテストしたいっていうのは
本質的に設計が悪いってことが理解できないやつ
もしくは設計なんてしたことがないやつなんだろう
>>16
君は簡単なロジックしか組む機会がなかった幸せな人だと思うよ
僕は君が羨ましい、幸せな人生を歩んでいるね 僕は下痢便コードをこうするべきって修正したよ
paizaで動くようにMainというクラス名に変えたけどね
paizaだからそうなるよねってみんな理解してくれるものと思ってた
paizaを知らない木偶の坊がクラス名に文句つけてきたとき僕は絶望した
まだやってたのかｗ
>>5みたいな下痢便コードが出てきた時点で
「あっ・・・（察し）」でスレ終了でしょ こうするべきだと思うならやれば良いがな
自分でやりもせず他人に文句いうだけの人間は木偶の坊のそしりを免れないよ
Mainに他のクラスの処理を全て同居させる
全部Mainにあるから呼び出せるよね？と
publicメソッドをprivateメソッドに変更
publicメソッドはMainのみ！
と言い
あぁ、プライベートメソッドのテストができない～と嘆く（笑）
アホなのか？自分でテストできないようにクソ設計に変更して
自業自得じゃんｗ
×>>5みたいな下痢便コードが出てきた時点で
○>>3みたいな下痢便コードが出てきた時点で
すまん訂正 >>24
君はまだMainという名前のレトリックから抜け出せてないように見える
paizaで動かすためにMainという名前にしたってだけだから
実際にはそれなりの名前になるでしょう
privateメソッドは当然クラスと関係あるものになるでしょうということ
Mainという名前に囚われ過ぎておられるように見受けられる
自分だったらこう書くのにって言うのがあるならそれを実践してみるべきかと思われます おそらく設計とは何かを知らずに、
ただ動けばいいと思ってるんだろう
テストしやすく設計するのも
設計の一つ
>>27
Mainを勘違いしてたアホが何抜かしとんねん >>26
だからテストしやすようにjudgeLengthメソッドを含んだ
クラスを作るだけ >>28
勘違いしてませんが？
Main関数とロジックを同居させるなの意味がわかりませんか？ 謙虚になれや
オブジェクト指向とは礼儀作法と心得よ
>>27
Mainクラス云々については単に誤解してると思うけど
このスレの登場人物じゃあ多分おまいが一番マシな感性持ってそうやなｗ このスレの主旨的にはprivateメソッドのテストコードを書きたいんだよね？
書く必要がないって主張は違うよね？
結局のところ何でもあり
僕は単体テストさえやってないからね
スレタイと書いてあることがチグハグで趣旨が解りづらいな。
スレタイに従えば、privateを呼び出したいみたいだが、>>1の発言を見るとprivateの呼び出しは推奨しないように見える。
まぁ、私も推奨しないけど。
という訳で、適当に独り言を語ってみる。
単体テストって、例えば...
Queueという名前のクラスがあって、そのクラスの中に
Enqueue、Dequeue、Peek、Clearメソッドが定義されていたら、それらメソッドを呼び出して、その結果を予想するコード(テストコード)を書いて実行させる方法がオブジェクト指向プログラマーにとって一般的だと思うけど...その際にprivateメソッド(内部実装)をテストコードから呼び出さないといけない理由がわからん。 t-wadaさんがどういう人か調べてみたところ、日本が誇るJavascript使いなんだな。
すると、t-wadaさんの立場ではprivateをテストしないというのは全くもって正しいと思う。
privateでやる事はライブラリを呼び出すだけなので、テストするのは無駄。
しかし、他の言語ではアルゴリズムの実装という仕事があり、アルゴリズムの実装をテストしたいという要求は常に存在する。
例えば多くのパーサーは公開メンバとしてpush()を持つ。
文字をプッシュする関数だ。
めぼしい公開メンバはこの程度しかない。
しかしその裏に100を超える非公開のメンバがあっても驚かない。
非決定性のパーサはその程度のメンバを持つ。
文字をプッシュする公開メンバ一つで、多くの状態、多くのメンバをテストするのは面倒な話で、何方にせよ非公開のメンバ、非公開の状態変数について知識が無ければテストできない。
だったら内部の状態について一切テストしないか、内部の状態を直接テストするか二択となる。
内部の状態についてはブラックボックスとして扱うべきと述べているのがt-wadaさんだが、それでは実装が非常に困難だ。
パーサーの話ついでに、もう一つアイデアを提供しよう。
決定性パーサーでは、還元が行われたとき、外部に影響を及ぼす。
通常この時点で意味動作を行う。
t-wadaさんは、この時に限りテストを行うべきであり、それ以外でテストを行ってはいけないと述べる。
つまり、シフトが行われるときはテストしてはならない。
今どの状態にあるかは外部にかかわりのない事なのでテストとしてはならない。
入力文字として改行を与えるとどの状態に遷移するかテストしてはならない。
これは厳しすぎやしないだろうか？
詳細を知ってはならないということは、どの状態を経てその記号が生み出されたのか知ってはならないということであり、これは非常につらい。
システム利用者がシステム作者に「詳細を検査しちゃだめじゃないか！」と怒っているように見える。
クリスマスプレゼントが何かを知るために箱を振って音を聞くよりも、箱を開けて直接見るほうが早い。
箱を振って「プレゼントはプリキュア」と観測できたとする。
これは果たしてどの程度もっともらしいだろうか？
privateなメソッドの動きが仕様書で定義されてたらテストしなくちゃいけないし書いてなかったら書く必要無い
そしてprivateなメソッドの仕様まで定めた仕様書は俺は見たことない
>>47
うるせーばか。文句を言うために都合の良いデータを調べてきたに決まってるだろ >>50
仕様書には普通アクセス修飾子を何にするかなんて書かないからね
設計書にもそんな細かいこと書かないでしょ 書いてない関数を勝手に作るなんて禁止に決まってるだろ
テストのためだけに関数は作らない
関数を作るのに許可がいるなんてすごいことだからとてもすごいと思いました
>>1にはテストとしか書かれていないけど、記事元はユニットテスト(単体テスト)の話だよね？ >>57
ユニットテスト以外でメソッドのテストなんかするのか？ >>3
このコード出すやつが混じってるんだろ？
議論無駄やん >>59
自分であたかも他のテストがあるように言っておいて変な話だがだが、しないね。
単体テストで不具合を見つけた後、デバッガを使って更にどこにバグの原因が潜んでいるのか分析することはあるけど、それはもはやテストではなくデバッグだしね。 てかさ、タイトルがカプセル化なのに、なんで>>3も>>5もテストコード実行場所とテストコード実行場所が同じ階層に記述されているのさ。 ミス。テストコード実行場所とテスト対象が同じ階層に書かれているのはなんで？だ。
wadaは忘れろ
privateだからテストしなくていいなどという都合のいい法則は存在しない だがprivateだからとテストをしないキチガイは確実に存在するのだ
一意見を急に”理論”とか”法則”とか言う方が頭どうかしてるよ
t-wadaはTDDをわかりやすく解説することに定評があるだけ
ただいろんな会社からテストのコンサルティングで雇われる程度には有能だから
君たちの意見よりは一般には受け入れられやすい
和田理論被害者の会ニューヨーク支部もひつよう。
とてもひつよう。
前スレで王家秘伝のレシピ教えたのに。
誰も活用しないんだな。
>>61
> 単体テストで不具合を見つけた後、デバッガを使って更にどこにバグの原因が潜んでいるのか分析することはあるけど、それはもはやテストではなくデバッグだしね。
単体テストで不具合を見つけた後にするもの＝デバッグ
デバッグの前にする不具合を見るけるもの＝テスト
だろ？
テストの後にするデバッグは、テストではなくデバッグだしねって
あんた何言ってるの？ オブジェクト指向の話をしよう
彡ミ
↓↓↓
彡 ⌒ ミ
(´・ω・`) 頭皮、毛髪に触れるものは全て検査する
>>74
そんな細かいこと気にすんなよ。揚げ足取りめ。
よく単体テストは不具合を見つけるためにやると言われるが、別視点の考え方もあるって話だ。
ここでは些細な話だったな。 >>74
> テストの後にするデバッグは、テストではなくデバッグだしねって
> あんた何言ってるの？
テストの後にするデバッグはデバッグでしかないと思いますけど、どこに突っ込みを入れたいのですか？ >>77
↓ここにツッコミを入れたい
> それはもはやテストではなくデバッグだしね。 >>60
そうそれ
あれ書く奴とは1byteたりとも意見交換したくないわ >>78
(テストとデバッグは違う作業だと思うのだが) もしかすると、バグの原因を調査する作業はテストに含まれるかどうかって話かな？
>>81
当たり前だろ？
テストではなくデバッグだしねっていうのが意味わからんって言ってる
テストはテストだろ 突っ込みどころねーじゃんw
それなのに喧嘩腰で突っ込んで周囲に突っ込まれただけか。
privateメソッドのチェックもできない奴は出荷すんぞ
privateのチェックって具体的にどうやるの？
Queueというクラスをテストするケースを例に教えて。
queue = Queue()
queue.push(17)
asserEqual( queue.length, 1)
a = queue.pop()
assertEqual( a, 17)
assertEqual( quele.length, 0)
だいたいこんなもんだろ。
>>88
おお、俺もそんなのイメージしてた。
そんなコードでpublic経由でprivateを呼び、ついでにカバレッジテストとか済ませる感じかな。
...だったらいいのだが、なーんか、このスレの人達の言動を見ていると怪しいんだよな。
88は別に問題ないけど。 カバレッジテストをするかどうかは、ケースバイケース。どちらでもいいとして、一番気にしているのは、そもそも>>1の記事主に批判的な人はオブジェクト指向を理解しているのか？という点。
怪しいというのは、そこね。 >>85
デバッグはテストじゃなくてデバッグだしねと言われても当たり前としか言えないし、
デバッグの前にやるテストはテストだしねで終わりだろ？ >>91
言いたいことは何となく理解できる。
「私以外はみんな馬鹿」
ってことだろ？
つまりキミの主な言語はJava。 どうやら図星だったようですね。
Javaではありがちなんですよ。
>>91
とまぁ、>>92みたいな低能が蔓延るスレで世間の常識は通用しないってことが証明されちゃったわけだ。
立ち去るがいい。 >>92
何がいいたいの（笑）
俺を馬鹿にしたいのかな？でも文章がそうなってないな。 >>95
馬鹿にしてない。
馬鹿に付ける薬はない。 オブジェクト指向はダメなんじゃないか？というのが前スレの趣旨で、非公開のメンバは何のためにあるの？テストどうするの？という話になった。
それに対する回答が「非公開のメンバはブラックボックスとして扱いテストしてはならない」という和田メソッドが示された。
それに対して「入力に使われる一つのメンバしかもたないパーサ」という実例を挙げ、「文字列を入力され構文木を返すような状態機械のテストが非常に困難」という話が出た。
この場合、内部を観測できないのであれば、すべての入力の組み合わせ（受理できない入力もテストするなら、それは無限である）に対して、すべての取りうる構文木のセットを検査しなければならない。
つまりそれは太陽系よりもはるかに広く、銀河の向こうまでテストするということである。
それに対して「オブジェクト指向を知らない」などと抜けたことを言うので、「Java！」という結論が出された。
> それに対する回答が「非公開のメンバはブラックボックスとして扱いテストしてはならない」という和田メソッドが示された。
正確には
・パブリックメソッド経由でテストする
・別クラスのパブリックメソッドとする
・テスト対象の可視性を（やや）上げる
・プライベートのまま、リフレクションでアクセスしてテストを書く
まとめ
繰り返すと、プライベートなメソッドや関数をテストする必要は無いと考えています。
プライベートなメソッドは、実装の詳細であるからです。
実装の詳細ならむしろテストが必要だと思うのだけど
なんで詳細だからテストしなくて良いのだろう
t_wada被害者の会に僕も入会させてください
>>99
公開メンバは文字を入力するpush()のみと示されてるだろ。
複数の文字を入力して構文木を得る、ごくありふれた状態機械の話だよ。
公開メンバは一つしかない。
ほらテストしてみろ。 >>98
> それに対して「入力に使われる一つのメンバしかもたないパーサ」という実例を挙げ、「文字列を入力され構文木を返すような状態機械のテストが非常に困難」という話が出た。
> この場合、内部を観測できないのであれば、すべての入力の組み合わせ（受理できない入力もテストするなら、それは無限である）に対して、すべての取りうる構文木のセットを検査しなければならない。
それはパブリックメソッドでも同じこと
内部を観測して、すべての入力の組み合わせをテストしないといけないから >>101
> ほらテストしてみろ。
テストしてもいいが、先にパブリックメソッドの場合の例を書いてくれ
それと同じことをやればいいだけなんだが 単体テストっていう言い方がまずいのかも
インターフェーステストとインプリメンテーションテストに分けるのが良い気がします
言い張るんだったら、ほんとに和田メソッド被害者の会作っちゃうよ？
会員200万人目指しちゃうよ？
いいの？
>>105
先にパブリックメソッドの場合に
どうするかを答えてくれないか？ >>105
言いたいことわかってくれるあなたは、PythonとかC#とかC++ですね？ 自作自演ｗ
105 名前：デフォルトの名無しさん[] 投稿日：2020/07/07(火) 15:11:55.03 ID:zTLocdwC [8/9]
言い張るんだったら、ほんとに和田メソッド被害者の会作っちゃうよ？
会員200万人目指しちゃうよ？
いいの？
107 名前：デフォルトの名無しさん[] 投稿日：2020/07/07(火) 15:12:43.34 ID:zTLocdwC [9/9]
>>105
言いたいことわかってくれるあなたは、PythonとかC#とかC++ですね？ >>110
そんなどうでもいいものばっかりにレスしてないで、
先にパブリックメソッドの場合に
どうするかを答えてくれないか？ Javaは色々研究して提唱してえらいなあと思う部分もあるんだけど、すぐに宗教化してしまうからな。
そこがJava！なんだよな。
どうも都合が悪かったようだな
俺のレスに答えられずひたすら関係ない話を始めた
でも俺が設立するからには、普通じゃダメなんだよ。
俺がやるからには、和田メソッド被害者の会長が和田さん。
ここまでやってこそ本物だと思うんだよね。
まず、和田さんを説き伏せなきゃ。
いいだしっぺが説き伏せるそうです。
実際に行動を起こせるか見てみましょう
いきなり他人だよりです（笑）
自分から知らせに行く勇気もないようですね
ではまずいいだしっぺから
なぜパブリックメソッドにすると
すべての入力の組み合わせをテストしなくてよくなるのか？
C1カバレッジって言葉知ってますかね？
訂正、すべての入力の組み合わせは2カバレッジだった
>>87
一般的にはQueueはprivateのメソッドも単純なロジックしか持たないから
public経由のテストで十分な場合が多いかもしれないけど
それがあらゆる状況に当てはまるわけではない
例えばgrowableなring bufferでqueueを実装するとして
バッファを拡大させるロジックに独自の最適化をいろいろと施してるような場合、
各種分岐に応じたメモリコピーの方法だったり、それに応じたメモリの初期化状態の確認だったり
privateなhead/tailポインタへのアクセスだったり、
public経由だけでは確認できないテストをしたほうがいい場合がある >>123
訂正
一般的にはQueueはprivateのメソッドも単純なロジックしか持たないから
public経由のテストで十分な場合が多いかもしれないけど
それがあらゆる状況に当てはまるわけではない
もしpublic経由のテストで不十分な場合、それはメソッドの責務が大きいと考えられる
リファクタリングして複数のクラスに分離するのが正しい対応
そうすれば自然publicメソッドとなりテストが可能になる キミも和田メソッドの被害者なんだよ。
可哀そうに。
和田さん本人だとしても、被害者であることに変わりはないんだよ。
ごちゃごちゃうるさい
privateメソッドのテストやれよ
キチガイ
和田メソッド被害者の会、会員募集中。
和田さんも入会して良いんだヨ。
>>123
君は信頼できる
実装をよくわかってる人だ 可視性狂信者ってのはどうしようもないね。テストさえ犠牲にし始める。
>>95
今さらだけど、前スレのタイトル(今より酷い)から察せると思うが、あなたの想像を越えるお馬鹿さんがいるから、常識を持つあなたはここから逃げた方がいいよと、お前どっちの味方だよ風に言いたかった。 って、何でもないです。
(アンカが自分に向いていたと勘違いしてたとか言えねぇ)
>>130
むしろ、こんな気違いに絡まれる和田さんカワイソ >>128
君の言うテストって何？
しかも、君は>>87の質問に答えてないよね？
具体例示してよ。 >>137
は？いいからprivateメソッドのテストやれよ オブジェクト指向を理解している人間の言うprivateをテストせよ/テストするべきではない と、 オブジェクト指向を理解していない人間のprivateをテストせよ/テストするべきでない は論争のレベルが全然違う。
大学生同士の論争と小学生同士の喧嘩くらい違う。
お前はどっちだ？>>138 >>139
ごちゃごちゃうるさい
privateメソッドのテストをやれ ここで話を整理するけど
privateメソッドだからテストしないとか言ってるやつはキチガイ
早く死んでね
具体例もなく、privateのテストやれと言われてもできねーよ、バーカ。
うんうん
わかってない人もいるみたいだからもう一度ここで仕切り直しさせてほしい
privateメソッドだからテストしないとか言ってるやつはキチガイ
早く死んでね
わかったかな？
頭皮に触れるものは全て検査する
彡ミ
↓↓↓
彡 ⌒ ミ
(´・ω・`) 使ってるシャンプー、肌に合ってるかい？
［ケハエール］
彡 ⌒ ミ
(´・ω・`) 確認もせず使うのは馬鹿だ
>>143
> privateメソッドだからテストしないとか言ってるやつはキチガイ
だれそれ？
privateメソッドはpublicメソッド経由でテストすると
言ってる人しかいないけど？ >>147
それテストできてねーからｗ
publicから t=0のときだけprivateの処理が欲しかったとするじゃん？
そのままじゃpublicは仕様でt=0のときしかそのprivateメソッドを呼ばないんだから
そのpublicからしかテストしないんじゃt≠0のときのテストできねーじゃん
やんねーのかよ？
ある時改修で別のpublicメソッドからt=3のときにprivateメソッドを呼ぶことになったらt=0しかテストやってなかったら
普通は怒り狂うもんだよ
っていうか絶対ブッ殺す >>149
> そのままじゃpublicは仕様でt=0のときしかそのprivateメソッドを呼ばないんだから
つまり、publicがt=0のときprivateメソッドを呼ぶんですよね？
publicがt=0のテストをすれば、privateのテストしてるじゃないですかｗ > ある時改修で別のpublicメソッドからt=3のときにprivateメソッドを呼ぶことになったら
> t=0しかテストやってなかったら
仕様が変わったのならt=3のときのテストを追加しましょう
>>149はホント意味不明だな
最初の仕様・・・t=0のときしかprivateメソッドの処理をしない
t=3のときは？→「privateメソッドの処理をしない」場合の結果が正しい
改修・・・t=3のときにprivateメソッドの処理をすることになった
「privateメソッドの処理をした」場合の結果が以前と異なるという仕様になった
では新しい仕様のテストを書きましょう
これだけなんだがなぁ
前と正しい答えが違うのに、テストを修正しないの？ >>151
おかしくない？
privateメソッドの仕様は変わってないよ
お前はガラクタをこさえたから説明のできない行動を取らなければならない 設計書かコメントに
このメソッドはt=0のときしかテストしていません!
って書いてあるの？
お前のソースって
悪いけど見たことねーや
滅茶苦茶バカだしもういいかな？
レスしなくて
>>153
だから変わったpublicメソッドをテストしろよ
変わってないならprivateメソッドに何の問題もないだろ
それとも何か？お前すべての取りうる値でテストしろと言ってんのか？
この関数は数値を二倍してくれる関数である。
今まで4を入れてこの関数を呼び出していた。
今度5を入れるようになったから5を入れた場合はどうなるかテストする必要がある
今度は6を、7を、8を・・・って新しい引数で呼び出すために
そのテストが必要なんか？ああん？ >>154
> このメソッドはt=0のときしかテストしていません!
お前は t=全ての整数 でテストしろっていってるってことでいい？ は？最小-1、最小、中間、最大、最大+1通すだろフツー
だが、お前のやり方ではどうやっても通すことはできないんだよ
こんな簡単なテストすら不可能
早く死ねよ
これがお前の限界なんだよ
っていうかここまで自分の間違いを認めない意味はなんかあるの？
これぜってー仕事でお前の主張が通る現場ねーぞガチで
メソッドにt=0のときしかテストしてませんって書いてあるもの納品するか？
ナメてんじゃねーよ
>>157
> は？最小-1、最小、中間、最大、最大+1通すだろフツー
・t=3のどこが、最小-1、最小、中間、最大、最大+1なんだよｗ
「今回」新しく仕様が変わって、t=3 などというものが登場したんだろ
なら「今回」テストを追加するだけの話だろ
それとも何か？ t=3がいままでprivateを呼ばなかったのに
t=3のテストをお前はするんか？どういった理由で？ >>159
> っていうかここまで自分の間違いを認めない意味はなんかあるの？
お前のことだろ。
> これぜってー仕事でお前の主張が通る現場ねーぞガチで
お前のことだろ。 bdixmHftはQueueという言葉とオブジェクト指向という言葉が理解できずに発狂した説
詳細に関する知識が無ければ検査できないなら、公開メンバを介して検査するのと、非公開メンバを直接検査するのは同じことですよ。
これが理解できないなら、もはや議論の意味が無いでしょう。
そもそも自身が推奨する和田メソッドさえ理解できていないって事ですから。
アンクルボブの理論に対する賛否両論から議論を始めるべきなのかもしれない。
>>149
そもそも、public経由のテストで網羅できないレベルのprivateメソッドなんてクラス内部に定義するなゴミ。
別クラスに分けろ。 和田さんはアンクルボブを理論のベースにしています。
和田理論否定派はアンクルボブ理論を理解したうえで和田理論に異議を述べています。
和田理論信仰者は、そもそもアンクルボブって何？状態です。
だから議論が成り立っていないのです。
詳細に関する知識を持ってはならないというのが和田理論の根幹です。
private、publicという字面にこだわるのは単なる信仰心にすぎません。
神を信じますか？ハイ信じます。
神を見ましたか？ハイ見ました。
こういうことです。
和田理論を素直に受け入れられるのは、プログラミングとはAPIを呼び出すことであり、決してアルゴリズムを実装することではないからですよ。
つまり、システム利用者がシステム作者に対して小言を言うような状態です。
詳細を検査したら駄目じゃないか！詳細は呼び出せればいいんだよ！
>>167
「アンチ和田」がかってに命名したもの（笑） 「和田理論」も同じな。「アンチ和田」はなにか理由があって
命名しているんだろう。常識的なことを名前をつけることで
特別な方法だと錯覚させる手かな？
アンクルボブをロバートと読み替えても通じますし
僕が納得したところでお前は何も困りません
>>159
相手は >>3 の下痢便コード書いた人だよ
まともなプログラム書けない人だから相手にするだけ無駄だよ 関数が取りうる値で全てでテストしろと言ってるアホがいるスレはここですか？
今回78という値で関数を呼び出すことになった
78という値を与えた時、ちゃんと動くかテストしているかね？
だってさ（笑）
privateメソッドのテストを具体的にどうやるのか未だに分からん。
そもそも、public経由のメソッド呼び出しで網羅できない巨大privateメソッドの正しい動作なんて定義できるの？
巨大なメソッド自体が悪じゃね
あとテストってinoutを確認するんじゃないの？
outいっぱいしてたらもうそれ完全害悪じゃね
ステートメントの入力により無限通りの構文木が出力されるパーサ？
なんだそれ？
>>179
最小、最大、中間値ぐらいしか言ってないのにそうやって曲解しないと負けちゃいそうなの？ そもそも、privateメソッドを定義すること事態、滅多にないよ。
というか、自分のソース見たら無かった。
このスレの過去の発言を見ると誤解を招きそうだから補足するけど、別に内部処理をpublicにしたからprivateは無いという意味じゃないからね？
元からpublicメソッドとprivate変数しかない。
>>181
巨大なメソッドをprivateメソッドに分割しても、その分割したメソッドを個別にテストできなけりゃ
分割してないのと同じじゃね？ >>183
↓って書いてますが？ 3と78でなにか違いがあるんですか？
> ある時改修で別のpublicメソッドからt=3のときにprivateメソッドを呼ぶことになったら
> t=0しかテストやってなかったら >>186
そういうこと。巨大なメソッドがあったらそれを
一つのメソッドと、そこから使われるユーティリティメソッドに分割する
ユーティリティメソッドはできる限り汎用的なインターフェスにする（たとえ一箇所でしか使われていなくても）
ユーティリティメソッドはそれ単体でテストする
そうすれば巨大なメソッドのコード量が減る >>187
そここだわってるのお前だけじゃん
最小、最大、中間値のテストやった？
って聞かれてるときに3でも78でも駄目なのはバカでもわかるだろ？ｗ >>189
あのさぁ、ごまかしてないでちゃんと書こうよ？
最小、最大、中間値のテストやってれば
最小、最大、中間値ではない3のテストなんて不要なんだよって
ちゃんといわないと、あのバカには伝わらないよ？ 最小、最大、中間値って聞いたことがないけど
どこかの分野で一般的に使われてるもの？
境界値分析なら
境界値と境界値の内側と外側の3値か
境界値と境界値の外側の2値かどっちかが一般的だと思う
俺もそう思ってたけど、そもそもスレタイともずれてきてるよねっていう
詳細を知ってはならないということは、詳細の知識、つまり境界を知ってはならないということ。
「彼らはオブジェクト指向を全く知らない可哀そうな人ではないか？Javaを学ぶべきだ！」などと言う前に、原典に当たろう。
>>195
オブジェクト指向と関係ない話なら、関係ないって書いとけよ zTLocdwC以外、Javaなんて誰も言ってないけど？何が言いたいんだ？
スレタイはカプセル化って書いてあるしOOPは理解している前提でしょ？
まぁ、明らかにOOPを理解していない人が発狂していたけど。
オブジェクト指向のすばらしさを語っている人が、一番オブジェクト指向を知らない。
ゆえに議論が成り立たないという状態ではないだろか。
>>196
隠ぺいとオブジェクト指向は直行する概念ではある。
とはいえ、事実上同時に用いられるので、関係ないとは言えないのではないか。 >>200
そもそも、このスレで誰もオブジェクト指向の素晴らしさなんて語っていない。
さっきから誰に対して言ってるんだ...。 >>1に書いてあるのはただの常識で
和田メソッドなんて特別な名前じゃないよ 常識じゃん。むしろ、常識を疑うその心を疑え。それって経験不足では？
まぁ、強いて言うのなら、リフレクションを用いてテストは、許してはならない反則行為だと思うがな。
特に、カバレッジテストとかする場合は。
ただ、記事を書いた和田さん？も、記事を読むとその危険性を理解しているみたいだから対立する気はないよ。
黒魔術と言ってるし。
なんで黒魔術なんでしょうねぇ(すっとぼけ)
そりゃC++への嫉妬だろ
C++はそう呼ばれるのに、Javaは何故かそうは呼ばれない、それは何故か？
Javaに欠けているものとは一体……？！
黒魔術って言われ方を誉め言葉だと思ってる馬鹿ってほんとにいるんだな。。
オブジェクトが隠蔽・カプセル化するものだからといってホワイトボックステストまで否定しちゃうのは変な話。
ホワイトボックステストを否定する気はないけど...例えば
>>88のコードを借りるけど
> queue = Queue()
> queue.push(17)
> asserEqual( queue.length, 1)
> a = queue.pop()
> assertEqual( a, 17)
> assertEqual( quele.length, 0)
こんなノリでprivateだったメソッドをpublicにしたり、リフレクションを使って呼び出すとする。
queue.内部実装()
...で、これでカバレッジテストに合格しちゃったらどうするの？
Queueというクラスはテストに合格したと見なすの？
テストってテスト項目に合否判定を出す作業だと思うのだが、内部実装の呼び出しで合否判定を変えるなんてチートは駄目だと思う。
そもそも、privateメソッドを定義するケース自体、珍しいから、経験則に基づかない発言でもあるが...。 あー...うん、俺の言い方が悪かったかも。
privateメソッドをテストするというレアケースだから許してくれ。
常識が無い以上、もっと正確に細かく伝えるべきだったな。
ただ、俺の主張(リフレクションは反則
行為)の弱い点を言うと、OOPやDDDの概念を無視した設計には、こちらの主張は当てはまらない。
そう思うと、和田さんのリフレクションをギリギリ許容(？)するような記事の書き方も否定はできん。
なんだかんだで、彼の記事は自分が記事を書くよりは無難にまとめられているとは思う。
まぁ、記事を書いたことないけど。
ユーザーが直接public methodを使うわけじゃなければ
public methodだって実装の詳細
integration test経由で
必要なpublic methodはテストできるんだから
個別にすべてのpublic methodをテストする必要なんてない
というのと似たようなもの
それでいい場合もあればそうじゃない場合もあるというだけ
まあね、処理の複雑さによるのだろうね
hello world程度ならテストさえ必要ないだろうし
>>213
どうするの？っていうそこの何が問題なのかわからん。
必要以上の詳細をテストしてしまうことによってテストが壊れやすくなるという
一般的な話以上のものではないように思うが。 そこで、テスト駆動開発ですよ。
最初にテストケースを定義してそれをパスする
コードを書けばpublicだのprivateだの議論は不要
だれかこの開発方法やってる？
>>220
privateだとテストケース書けないじゃん >>219
不合格になるはずのテストに合格してしまうのが問題なんだよ。
>>220
テスト駆動開発は社内でも聞いたことがあるけど、実践はしてない。
まぁ、自分自身、詳細は知らない。後で調べるか。 >>213
> ...で、これでカバレッジテストに合格しちゃったらどうするの？
テストはテストコードを見ないで
OKってでたからOKだ
ってやるもんじゃないよ
テストコードはレビューするものだ
通ったからOKじゃなくて、通るのは当たり前で
テストコードを見て正しくテストされてることを確認する
テスト結果のOKが「エビデンス」なのではなくテストコードが「エビデンス」
動作してることを証明するスクリーンショット（笑）と同じもの
「エビデンス」は見て確認しなければいけない >>221
テストケースがあるもの＝publicメソッドで
privateは中で必要に応じて作るもの
メソッドにしてもいいしメソッドにしなくてもいい
テストケース書けないなら関数にせずにそのまま埋め込めよ
publicメソッドのテストケースが問題ないなら
中の詳細なテストなんかいらんだろ
メソッドにしてないかもしれないし >>224
テストケースが書けないってだけでインライン展開するんすか？
構造化プログラミングを愚弄する狼藉っすよ
遠山の金さんの桜吹雪を拝むことになりますよ privateではなくてパッケージプライベートにした方がええのかもわからんね
それで破綻するならパッケージの設計がよろしくないということで
>>227
テストケースが書けるならばpublicにすればいいだろ？
テストケースがある＝仕様が明確になってる証拠 なんでテストケースが作れるのに、publicにしないのかわからん
privateでかっこいいメソッドなんだろうがよ!
いや、俺実はpublic staticしか作らんけど
>>222
正直、開発自体をテスト工藤開発で終えるのはキツいと思うけど、
コーディング→動作確認→デバッグ→リファクタリングの
プログラマー個人の短いサイクルでのトライ&エラーには結構使えるんじゃないかと思う。
カバレッジ100%のテストケースは作る工数とメンテが大変だからそこまでする必要はないと思うけど、
そこそこのカバレッジでプログラマーが個人で高速に開発を回せるのは強い。
カバレッジ100%目指すのは単体テストの時だけで十分 和田メソッドによると「非公開メンバをテストすると品質が下がるので絶対するな！」
意識が高くなりすぎて幽体離脱した感のある和田メソッドをよろしく！
>>22
いや、その「不合格になるはず」のところがわからん。
呼べないはずの内部実装が呼べちゃったってこと？ >>241
合否判定が変わる例ってこんな感じじゃない？
不当に不合格になる例
queue = Queue()
queue.push(17)
asserEqual( queue.length, 1)
a = queue.pop()
queue.内部実装()
assertEqual( a, 17) ←不合格
assertEqual( quele.length, 0)
※ユーザーが呼べるメソッドを呼んだら、なんか破綻したケース
あるいは網羅テストをやってて、不当に合格する例
for(i = 0 ; i<127;i++){
queue.内部実装(i)
}
内部処理{
switch(条件)
以下略
}
条件分岐を全て網羅したから合格。
はおかしい。
queue.pushやpopの呼び出しで合格できなかった網羅テストを内部実装を直接呼び出して合格って変な話。
という意味では？ >>242
でもカバレッジって落ちないぜ以上の意味を取るのって無理じゃね？ >>242
いや、ますますわからん。
そのタイミングで内部実装()呼んでもaの値は変わらんと思うが？
pop()の前に呼ぶんだとしたらなんでそんなテストを書くんだという話になるし。
異なる操作をしたならassert条件が変わるのは当たり前。 >>244
前者は私のミス
>>243
ごめん、カバレッジやったことないから間違っていたら謝る
うーん、この解釈を間違えた感 >>242
まずテストの考え方が違うんだよ。
全ての組み合わせをテストする完全な網羅テストは時間的に不可能
その他のテストも数によっては現実的に不可能となることが多い
通常カバレッジ100%というのは命令網羅テストにすぎない
だが命令網羅テストをやってれば完璧かと言うかそうではない
じゃあどれをやればいいんだよ！？と思うかもしれないが、どれをやるかじゃない
何をやれば自分が作ったものが正しく動くと自信が持てるかなんだよ
現実的に実現可能であるというルールを加えれば、完璧なテストなんてできやしない。
内部実装を直接呼び出して合格したとしても、
それで正しく動くと自信が持てるなら、それで全然かまわないんだよ。
ただしテストする以上、内部実装の仕様を明確にしなきゃテストのレビューはできなくなる。
内部実装の仕様が明確になったならpublicにして問題ない。
おまけだが、pubicメソッドのテストでもprivateメソッドのテストでも
カバレッジを計測するなら、それはホワイトボックステストだからな
なんか間違ってる人がいるようだから 結局クラス分けするなりしてpublicにする部分を多くする、
テストと使用する局面で可視性を変える
の二つしかないわけで、プログラム機能でどうこうする話じゃない。
使う奴が理解して使うという話以上にはならん。
「privateメソッドがテストできないんですがどうしたらいいですか？」という疑問に対して、
なんとかしてテストする方法を編み出すのではなく「privateメソッドはテストしなくていい！」という
逆転の発想というかバッサリ感が中二受けしたんだと思う。
>>248
逆転の発想じゃなくて普通の発想じゃね？
privateなんだから だって可視性とテストするしないの関係は自明じゃないじゃん。
それが関係あるなら外部にexportする関数以外はテストしなくていいことになるんじゃね？
>>231
教えてしんぜよう
アクセス修飾子は仕様が明確になってることを表すものではないからだ publicにしたら全然関係ないパッケージからもアクセスされてしまうからね
不必要な依存を発生させることになってしまう、密結合が促進されるね
そういう意識のない人間が >>3 のような下痢便コードを書いてしまうんだね >>252
アクセス修飾子は仕様が明確になってることを表すなんて言ってないよ
仕様が明確になってるならpublicでいいと言ってるだけ >>253
> publicにしたら全然関係ないパッケージからもアクセスされてしまうからね
全然関係ないパッケージ = テストコード
アクセスできてなにか問題あるの？ >>254
言ってるじゃん、アクセス修飾子とメソッドの仕様が明確になってるかは無関係 >>255
何いってんのお前
テストは同じパッケージにするのが基本だろ
テストしたこと無いの？ テストから呼び出せるのが問題なんじゃなくて
関係ないパッケージから呼び出されて密結合になるのが問題だと言ってる
だからパッケージプライベートなら良いだろうと言ってるわけ
>>256
言ってないよ？
外部からアクセスしないならprivate。
でも仕様がはっきりしてるならpublicにしていい。
facebookでもプライベートな話は他人に見せる必要がないからprivateだけど
別に他人に見せてもいいならpublicにしてもいいよね
それと一緒 パッケージプライベートだと同じパッケージからならアクセスして良いというメッセージを
開発者に伝えてしまうから望まない依存を生んでしまうリスクはある
どのオブジェクトからも参照されたくない場合もあるからな、やはりprivateをテストできない
言語が遅れてるだけなのだろうね
>>257
> テストは同じパッケージにするのが基本だろ
Java以外で、同じパッケージとはなんのことで
そうするとどうなるんですか？ >>260
外部からアクセスしないけれども仕様がはっきりしてるからpublicにするのはありえないってことですよ
なぜならば密結合になってしまうから >>261
privateをテストできる言語っていうのは
単に全てpublicになっているのと一緒
アンダースコアで、これはアクセスできるけど
privateという意味ですよと言ってるのと何も変わらないよ >>264
アンダースコア？
そうなの？ 全部の言語がそんな仕様なの？
それは知らなかったなー >>263
仕様がはっきりしてるからpublicにするんじゃなくて
仕様をはっきりさせれば、publicにしてもよいと言ってるだけ
理由がなければprivateのままでもいい。どちらでもいい。
テストしたい＝理由。理由があるならpublicにしていい。
> なぜならば密結合になってしまうから
テストコードから仕様がはっきりしないprivateをテストすること＝密結合
密結合を避けるためにも、公開されたインターフェースにするのが正しい RustやGoはprivateもテストできるよって言ってる人いたから
最近の言語ではprivateもテストできるんだーって思ってたけど
命名規則でアクセス修飾子の代わりを果たしてるんだってことだったの？ それは知らなかったなー
>>267
仕様がはっきりしててもpublicにしてはいけないからprivateなんだよ
テストが依存することを密結合とは言わないよ privateにあくせすできる言語でも
テストするならどちらにしろ仕様をはっきりさせないといけない
そうしないとテストコードがあったからといって
これが正しく仕様を満たしているのか？なんてわからない
さすがです >>3 の下痢便コード書くだけありますね
何言ってるのかさっぱりわからない >>3のコードを書いたのは別の人。
そもそも>>3のコードをクソコードと言って
このスレにコピペしたのが俺 >>275
そうすると君はMainを勘違いしてた人か、僕と仲直りしますか？ 同じ人が同じこと言ってるだけのスレ
でもそんなスレも良いですよね
たとえばこの先Javaが進化したとしてテストオブジェクトのみを特別視して
テストオブジェクトからのみprivateにアクセスできるようになったとすると
テストオブジェクトをオブジェクト指向の枠組みで捉えるならば
オブジェクト指向としては破綻してる
Javaは受け入れないだろうね、Microsoftがdelegateを提案したときも
interfaceという仕組みがあるんだからdelegateは邪道だと言って蹴ったからなあ
実益に叶うという理由で根本的なところまで作り変えることができるのは
Microsoftだろうなあ、Javaの前にC#が対応しそうな予感はある
いまの言語仕様での最適解は >>5 ですね
これ書いた人は天才だと思いますよ
何気ないことだけれどもコードの隅々にまで神経が行き届いていて
美しく整備されて堅牢なコードです、オブジェクト指向の限界を示したと言って良いですね >>248
逆転の発想じゃなくて都合のいいことを信じたい馬鹿の発想だろ テストコードは設計の外にあるものだからクラスの可視性とか直接関係ないだろ。
ふつう、設計書のクラス図にテストクラスを書いたりはしない。
>>281
クラス図にprivateメソッドを書きますか？ クラス内を調査してprivateメソッドを列挙して
同クラス内のprivateメソッドをテストするコードを列挙して
カバレッジを計測するツールがあればみんな幸せになれそうですね
カバレッジ計測ツールがprivateメソッドには今の時点で対応してないって
だけでprivateメソッドのテスト自体は >>5 のように書けますから
ツールの開発が遅れてるだけなのかも知れませんね >>285
もしかしてお前カバレッジの意味がわかってないんじゃね？
publicメソッドの中からprivateメソッドが呼び出された時
privateメソッドの行は実行された＝カバレッジとして計測される
ってことは知ってますよね？ 世の中にある全てのカバレッジ計測ツールは
privateメソッド内の実行した行を測定できるのですが
>>285を見る限り何もわかってない気がしますねｗ >>286
僕は単体テストやったこと無い
カバレッジの計測もしたことないからわからない
僕は知りません >>289
それにはちょっと異論があるんだけれども、今回は僕が折れましょう
僕と仲直りしますか？ >>290
でもおまえ単体テストしたこと無いし
カバレッジの計測もしたことがないから
何も理解してないじゃん（笑）
問題はそこだよね。 >>284
開発の段階によって違うんじゃね？最終的な設計ドキュメントには書いてるかな。 >>291
問題はそこじゃないです、君は僕と仲直りますかということが問題です 僕はいままで手作業による結合テストだけで生き抜いてきた生粋のブラックボックスマンです
なぜそれが可能だったかというと簡単なプログラムしか書いたことがなかったからです
しかし、最近複雑なプログラムを書く機会があり結合テストだけでは不十分であることを実感しました
以上、僕の近況報告です
僕は単体テスト書いたことありますよ >>5 で書きました
カバレッジは計測したことないですけどそれは重要ではありません >>292
最終的な設計ドキュメントはコードから生成するものだからね
クラス図にprivateメソッドが書かれていて嬉しいのでしょうかどうなのでしょうか？ > 最終的な設計ドキュメントはコードから生成するものだからね
クラス図の話ね。クラス図は（唯一？）コードから生成できる。
正直、詳細なクラス図は、設計図の中で一番不要だと思ってる。
必要なのはソースコードと完全に一致してるクラス図ではなく
クラス概要図・関連図とでも言うべきだろう
主要なメソッドとそれぞれのクラス関係がわかればいい
目的はなにかを考えればその結論にたどり着くはず
>>297
保守する人にとってはあった方がいいと思ってる。 単体テストという言葉の曖昧さがpublic派か、private派かの分裂の原因です
publicメソッドはオブジェクトのインターフェイスなので
publicメソッドをテストすることをインターフェイステストというべきです
オブジェクト指向で、インターフェイスが関わるのはオブジェクトのコラボレーションが行われるときです
一方でprivateメソッドはpublicメソッドが作られるのと同じか、もしくはそれ以前に作られます
publicメソッドが正しく動作することの前提としてprivateメソッドが正しく動作することがあるので
privateメソッドをテストすることをインプリメンテーションテストという言うべきです
privateメソッドを使用するのは同じオブジェクト内のメソッドなので、オブジェクトのコラボレーションとは直接の関係がありません
単体テストと言っても対象のメソッドによって、テストが必要な時期が異なるわけです
privateのテストはクラスが作られる前に行われますし、publicのテストがクラスは作られた後に行われます
あとはコストの話です、結合テストがすべて通るなら単体テストは必要ありませんし本番稼働がすべてうまくいくならテスト自体必要ありません
後の工程で発覚するほど手戻りが大きくなりコストが膨らむので段階を追ってテストしていきましょうというのが基本的な考え方です
privateのテストをすることによってpublicのテストの手戻りが少なくなることはあるんです
privateのテストはやったほうが良いです。
>>301
保守する時はコードから生成できるので完璧なのはいらない
だから本当に必要なのはクラス概要図だろう
図としてみたい場合、メソッドすべてがずらずら書かれていても邪魔なだけ
ましてやprivateなんていらない。
図としてみたい場合、本当に見たいのは関連だろう？ >>302
> 単体テストという言葉の曖昧さが
それ以前に、おまえ単体テストしたこと無いし
カバレッジの計測もしたことがないから
何も理解してないじゃん（笑）
問題はそこだよね。 頑張って書いた、これはもう論文と言って良いのでは
僕はプログラミングのテストについて博士号もらっても良いのでは
少なくともこのスレではテストに一番詳しい
>>304
僕は >>5 で単体テスト書きましたよ
君はカバレッジ計測ツールを使用して理解した気になってるだけのアホです 288 返信：デフォルトの名無しさん[] 投稿日：2020/07/11(土) 12:15:29.92 ID:JFnadz6+ [26/35]
>>286
僕は単体テストやったこと無い
カバレッジの計測もしたことないからわからない
僕は知りません 君はレトリックな部分に引きづられる傾向があるから
もう少し客観的に遠目でものを見るようにしたが良いかも
僕はJavaしか知らないと言ったけどC#に関するあっと言わせるような知識と考察を垣間見せたでしょ
僕の知性あふれる想像力は君の経験を凌駕する
ツールに習熟して使いこなすのも大事だけど、頭を使って状況を分析して打開する力も大事
僕は後者の方が優れている、君と僕が手を組めば最強になれる
僕と仲直りしてくれますか？
TDD信奉者がprivateメソッドのテストは必要ないと主張するのは当たり前
TDDは一般的にpublicメソッドを最小”ユニット”として書き始めるから
privateメソッドが作られるのはテストが通る状態を維持したままリファクタリングして
一部をprivateメソッドに抽出した場合だけ
だからprivateメソッドのテストを書く必要がない
privateメソッドじゃなくHelperクラスのpublicメソッド等に抽出した場合も同じ
HelperクラスをpublicなAPIとして公開するのでなければ別途テストを追加する必要は基本的にない
北朝鮮行ったことあるか？
日本の町並みには看板があるだろ？
「パナソニック」とか「コカ・コーラ」とかだよな。
北朝鮮でこれに該当するのはスローガンの看板だから。
社名や商品名の看板は一切ない。
「ウリナラをキノコの国にしよう！」←裏の意味は無くそのままの意味らしい。
「苦難の行軍！」
「白頭の革命精神！」
和田メソッドに通じるものがあるよな。
>>317
他のスレで書いたけど「例え」は物事をわかりやすく説明するために使うもの
何かを批判するために「例え」を使うのは悪手。なぜなら
「例え」で批判してるのは「例え」に使ったものだから
お前が批判してるのは北朝鮮であって
和田さんや「レガシーコード改善ガイド」の
ベストプラクティスの批判にはなっていない 話をしようかと言い、本の内容をコピペしただけとかゲンナリするよね
たとえ批判されても自分が言ったわけじゃないから問題ないわけですね
スネ夫メソッドと名付けましょう
本に書いてあることを自分なりに実践してみた結果大失敗して
和田メソッドは役に立たなかったとかそういう話が聞きたい
実践した結果コードがきれいになり
テストがしやすくなったよ
車の運転がうまい人は車の危険性を知ってる人
和田メソッドを熟知した人なら和田メソッドの危険性を知ってると思うのだよ
和田メソッドの限界はどこにあるのだろうね
TDDが向かないプログラムもあるとは本に書いてあるけど
それが具体的にどういう状況か、どういうプログラムかは示されないからよくわからない
僕はTDDの限界はpublicを前提とするところにあるのじゃないかと漠然と思ってる
まだぼんやりとして言語化できる段階にない
ググってみたけどTDDに否定的な考え方は世界的にあるみたいね
まるで○○は危険でしょうと言うだけで
何が危険かわかってない人のような言い方だなｗ
>>325
> まだぼんやりとして言語化できる段階にない
当たり前
↓
288 返信：デフォルトの名無しさん[] 投稿日：2020/07/11(土) 12:15:29.92 ID:JFnadz6+ [26/44]
>>286
僕は単体テストやったこと無い
カバレッジの計測もしたことないからわからない
僕は知りません >>327
ではTDDの場合どうなのか？
Private Methods, Test Driven Development, and Good Design
https://www.infoq.com/news/2008/01/private-methods-tdd-design/
> Why to test private method? Most of TDDers would answer instantly: don’t do it.
プライベートのテストをする理由？
ほとんどのTDDersはこう答える。「するな」
和田メソッド（笑）が言っていることとTDDは完全に一致してるな
まあ実際にはTDDが最初にあって和田さんは
それに同意して、TDDの話をしてるんだから当然なんだが >>329
僕は頭を使うことによって君の経験はすでに超越してるよ
君はただツールを使ったことがあるってだけのただのアホ > 実践した結果コードがきれいになり
> テストがしやすくなったよ
君の感想はこれだけ
あとは引用コピペを繰り返してるだけ
君の経験は浅すぎて僕の参考にならない
>>334
でもお前の発言はなにもないじゃんｗ
壊れたレコードのように和田はだめ（理由なし）和田はだめ（理由なし）を
繰り返してるだけ。今度はTDDはだめっていうんですかね？ｗ >>336
僕は、和田はダメと一度も言ってない
僕のレスを全部読み直してみて
君は頭が働かないどころか勘が鈍い >>337
まるで和田メソッド（TDDの常識的な手法）に
限界があるような言い方してるじゃんｗ
自分が何も知らないのに、限界があるんじゃないかという
疑いをかけるのはだめ。 世の中に銀の弾丸は無いからね
何事にも限界はあるでしょ、一般論だよ
IQ低い人はすぐ被害妄想いだくから面倒
>>340
一般論だからこそ、TDDの批判にはならないんだよ。 つまり
「お前の意見に言いたいことがある。一般論として人はだれでも間違える（ドヤァ）」
といっても意見にたいして、何かを言ってることにはならないのと同じね。
ちなみに僕は常識に価値があるとも思ってない
京都大学では真実は少数派に宿るっていう言葉が使われてるよ
>>342
疑いをかけられたんだーﾑｷｰって反応してる君がおかしいってこと >>344
じゃあ京都大学ではその言葉は多数派だから真実にはならないね（笑） >>345
だから「TDDには」疑いをかけられてないと言ってる。
お前は一般論を言っただけ >>347
そうだよ、僕は一般論をいっただけ
一つ指摘しておくと君は日本語を使ってる
わかるかな、僕のこの高度な皮肉が >>348
皮肉かどうかはどうでもいいな
少なくともお前はバカだということ
議論してるふりをしてるだけ > >>337
> まるで和田メソッド（TDDの常識的な手法）に
> 限界があるような言い方してるじゃんｗ
>
> 自分が何も知らないのに、限界があるんじゃないかという
> 疑いをかけるのはだめ。
疑いをかけられてないと思ってる人間が疑いをかけるのはだめとは言わんでしょう 君は疑いをかけられてると思っていた
僕は一般論だよと言った
君は疑いをかけられてないと言い出した
僕はそんなの当たり前だろということを示すために君は日本語を使ってると
当たり前のことを言って皮肉った
という流れだったんだ
もうお互い大変でしょう、僕と仲直りしましょうか？
君にアホと言ったのは謝るよ、君が僕にバカと言ったのは忘れるよ
僕は心の広い知的なイケメンです
和田メソッドの真骨頂は、バグを作り込まなければテストする必要が無いことにある。
テストは甘え、甘えがある限りバグは無くならない。
つまり、テストしない仕組みづくりこそが和田メソッドである。
クソみたいな議論ばっかに見えるがプログラム技術板の中ではわりかしまともな方になってるぞ。
>>355
参考までにまともだと思うレス番教えてくれ それは恐ろしい話だけど、このスレにもちらほらいるね。
そういう人に、どういう被害を受けたかを説明できればね（笑）
結局、被害の内容を言えないんだから、被害はなかったということ
オウム真理教の信者は被害者でもあり加害者でもある。
上の方でも書いたけど「例え」は何かを批判するときに使ってはだめ
「それは別の話で関係ない」という簡単な一言が完璧な反論になってしまうから
和田メソッドの信者は被害者でもあり加害者でもある。
しかしその理由は何一つ言えない。中身が無いからだ。
>>366
なるほど、つまりTDDはテストが開発を駆動するという考え方で
テストによって実装や設計が導かれるということなのだけれども
設計過剰だったり設計不足だったりする
設計は本来ドメインに関する知識から導かれるものなので
入力、出力を決めたら自動的に最適な設計が見つかりますなんて
そんな都合の良いことが起こるわけもなくTDDは現代では否定されていて
単体テストよりもシステムテストを重視したほうが製品の品質はあがるわけですな 説明に対して全く聞く耳を持たず、和田経典に書いてあると繰り返すだけだから、宗教的なナニカ扱いされてる。
t-wadaがお勧めする和田メソッド。
騙されたやつ多いのでは。
>>367
> TDDは現代では否定されていて
どこで否定されてるの？さらっとウソを付かないように。
どうせすぐに俺がバラすんだから意味ないよ（笑） どこで否定されてるのとか、これまでのみんなの説明が全くの無駄。
和田さんには和田さんの経典があり、みんなの意見には耳を貸さない。
だから宗教と言われてる。
前スレですばらしい分析を見たなあ
897+1 ：デフォルトの名無しさん [↓] ：2020/07/05(日) 11:28:59.86 ID:YdQ981ul
>>870
新しい理論や手法を提唱する人には良くあることだと思うけど、その理論はある前提、ある側面では正しいけど、常に無条件に適用することは正しくないと本人は分かっていて、敢えてそういうことはわざわざ詳しくは説明しない。自分の論が有用な物だと主張したいがため、嘘はつかない範囲で相手が勝手に誤解してすごいと思わせるような物言いをする。
で、その理論に感銘を受けた人の一部が、理論の表面的な効能だけをありがたく受け取って問題点や前提条件などは正しく理解しないまま、受け売りの知識を他所で披露する。
そこで議論になると、本質をちゃんと理解してないまま自説を擁護しようとするから、無理が生じたり話が噛み合わなかったりする。
という流れでイマココなのかなと思う。 >>372
昔の言い方でいうところの「東大話法」というやつですね… >>372
素晴らしい分析？ それはTDDに関しての分析じゃないよ
その文章はTDDに関して何一つ言及していない。 >>371
ここに和田さんはいないんだから、意見を聞かないはずだという逃げの言葉で
お前の意見を言わないのはおかしい。
他人が意見を聞くかは関係なく、
お前の意見を言えばいい。
言えないなら、反論するすべがないというのがお前に対する結論だ。 >>375
イイエ居ます。
みんな説明してます。
見えないことにするなら、みんなの書き込みが無駄です。
和田メソッドはカルト宗教の様相を呈してきた。 和田さんはこのスレに居ないと書き込んでるのが御本人かもしれない。
失速したな
TDDはプロトタイピングと組み合わせると良いかもね
テスト書かずに概ね正確に動作するコードを書いた後に
ブラッシュアップする目的でTDDを使って書き直す感じ
TDDを布教する人が何回も同じコード書いてうまくなっていくように
書き捨てたコードの数だけTDDは洗練されるんじゃなかろうかと
和田さんじゃなくてTDDの話をしよう
詳しい人いないの？
テスト書くタイミングについてなら少しだけ。
わりとだら～と書いて関数なりクラスなり切り出したタイミングで書く感じ。
テストから書くってのは普通の人には難易度高い気がするわ。
最終的なプログラムの詳細設計がパッと頭に浮かぶ人ならテストから書けるんだろうけど
プロトタイプぐちゃぐちゃ作って、やっと構造が決まって、とりあえず動くもの作った後でリファクタリング、な俺には無理だなぁ
>>390
そういうやり方にこそTDD的なアプローチが有効だと思うが >>390
構造が決まった時に設計が始まるんじゃないのか? 相変わらずオブジェクト指向信じて
頑張ってるJavaプログラマさん達に
お伺いしたいんだけどさぁ
Javaでオブジェクトをsystem.out.printしても
変な文字列出てくるだけでオブジェクトの中身見れないよね？
これってあんたらの好きな「カプセル化」のせいでしょ？
これ新人にはめっちゃ不人気でみんなJavaディスってんだよね。
一方JavaScriptやPythonは
オブジェクトをconsole.logするとオブジェクトの中身
全部一目瞭然に見れるし▶ボタンで折りたたみとかも出来
ちゃうわけよ。
Pythonは折り畳めないけどそれでも見やすいよ。
こんな簡単な揺るがぬ真実を説明するのに
「コンストラクタ」とか「ポリモーフィズム」とか
「メソッド」「インタフェース」「継承」
「オーバーライド」こんなクソみたいな単語を一切使わなくても
簡単に説明できるわけ。
これでJavaScriptやPythonはイケてる言語で
Javaやオブジェクト思考は糞だって事が分かったね。
誰でも簡単に理解できるよね。
わかりやすいREPLが使える言語のほうが学習効率が高いのは確かだが
標準でオブジェクトの中身がprintされるかどうかはカプセル化とは関係ない
p obj
Ruby なら、これでインスタンスの内容が分かる
この時に、Object ID みたいな謎の文字が表示されて困る場合は、
Object#inspect をオーバーライドして、好きな内容に変える
これは、たいていの言語の「Effective 何々」という本に書いてある。
まず最初に、表示メッセージを分かりやすいように、オーバーライドしろって
>>397
> Javaでオブジェクトをsystem.out.printしても
> 変な文字列出てくるだけでオブジェクトの中身見れないよね？
JavaScriptのオブジェクトは連想配列
というわけで、Javaで連想配列を作ってprintしてみた
https://paiza.io/projects/OnW9KR89v5m-CY5JXIV2tw
> これってあんたらの好きな「カプセル化」のせいでしょ？
オブジェクトをprintしたときはそのオブジェクトのtoStringメソッドが呼ばれる
これは「ポリモーフィズム」のおかげ
toStringメソッドはObjectクラスで宣言されている
すべてのオブジェクトはObjectクラスを「継承」しているため
toStringメソッドを「オーバーライド」して任意の値を返却できる
「カプセル化」は関係ない
> 一方JavaScriptやPythonは
> オブジェクトをconsole.logするとオブジェクトの中身
> 全部一目瞭然に見れるし?ボタンで折りたたみとかも出来
> ちゃうわけよ。
すてきなデバッガです PythonやJavaScriptがイケてる言語であることは間違いない
Javaよりも開発者多いのじゃないかな
PythonはAIで使われているし大学の授業でも使われていて
それまでC言語で教えてた内容をPythonで教えるようにしたら
学生の成績が飛躍的に上がったという話がある
人間の認知能力に最適な言語
JavaScriptはWebのクライアントでもサーバでも使われていて
日進月歩で進化している最も熱い言語
Javaは昔はオブジェクト指向一筋の堅物みたいな感じだったけど
最近はラムダ式やStream、CompletableFutureの導入など
どちらかというと関数型の方に傾倒していて、オブジェクト指向と関数型の
良いとこ取りをしようとしてる
そもそも単体で平置き出来る関数が出来るまでバカみたいに長い年月が掛かったからその間に他の言語に抜かされていった
オブジェクト指向もテストの文脈で語られるようになって、
だいぶ胡散臭い馬鹿が減ったと思う。
胡散臭くない小奇麗なバカは減って無い、ってことだな
>>405
「体で平置き出来る関数」ってどんなの？ TDDに限定するならともかく、一般論として「テストの文脈で」語ろうとするのは
逆にそっちの方が胡散臭いなぁ。
class/object instance scopeにあるmethodではない関数または関数objectのことではないかいな
「平置き出来る関数」なんてどこの村で通じる方言なん？
文脈でわかると思うけどね
自分の辞書にないからわからないというやつはただのアホ
慎吾ママが両手を広げて「おっはー」と言ったらおはようの意味だとわかるし
貴乃花親方がドアを開けて「あーす」と言ったらおはようございますの意味だとわかるだろ
「平置きできる関数」がわからない人は自分が八角理事長だと自覚したが良い
他人と議論をしようと言う時に文脈でしかわからない言葉を使うな無能が
>>421
文脈がわからない人間が議論に参加するべきではないと思うの
他人の言葉には寛容に、自分の言葉は厳密にが会話の基本
議論は会話の積み重ねなんだから会話の基本ができない人間は議論ができない人
他人の言葉に厳しい態度とっても良いことなんて無いよ プログラムでもそうだよね
メソッドを宣言するときは引数はできるだけ広い型
戻り値はできるだけ狭い型
にすることで他のオブジェクトと協調しやすいプログラムができる
なんでもかんでもインターフェイス使おうとするJavaの習慣は誠に遺憾
自分の説明能力の無さを相手が低脳だからと責任転嫁するヤシ
>>422
> 自分の言葉は厳密にが会話の基本
いやだよばーかｗ
俺の言葉は寛容にだ。平置きでわからんやつが悪い
お前は俺の言葉に寛容になれな。 自分の理解能力の無さを相手が無能だからと責任転嫁するココナツ
>>427
僕は平置きでわかる派ですよ
完全に理解した で、結局のところ
Javaで「単体で平置きできる関数」って何なの？
コードで示してくれるといいんだか
>>430
単体でおける関数ってわかりますよね？
それを平置きするんですよ 無限ココナツ
Stream.generate(() -> "coconut").forEach(System.out::println);
変数にセット可能、引数として渡すことができる、戻り値にセットできる
これが平置き三原則
Javaはクラスに包んで間接的に置くしかない
これが最大の欠陥
用語はともかくラムダ式のことだと分かってスッキリした
第一級函数のことかと思ったよ俺は
馬鹿は1つしかモノを知らないから適当に言っても1つの意味にしかならないが他人はお前よりモノを知ってるから第一級函数なのかラムダ式なのかそれとも自分が知らない別の概念なのか判断できないんだよ
結局単にラムダ式のことを言おうとしてたん？
それだけのことをなぜ平置きとか言い出しちゃったのかなｗ
見苦しいからもうこれ以上レスいらんぞ
単体で置ける関数のことを単体関数と言い、それを平置きして式化したものが平置き式
ラムダ式なんて西洋かぶれのバズワードを使わなくても説明できるのができるプログラマ
みーっけた！
こうゆう関数併記するスタイルの事じゃないの？
プログラミングのお題スレ Part18
http://2chb.net/r/tech/1594702426/124
https://github.com/katahiromz/3D
function add_line(x0, y0, z0, x1, y1, z1) {
}
function set_pos(x, y, z) {
}
function set_dir(dx, dy, dz) {
}
function walk(delta) {
}
function turn_dir(dx, dy, dz) {
}
function turn_angle(angle) {
}
function init() {
}
function koch(degree, step) {
}
function draw() {
}
function animate() {
} フォルダに平積みする事か？
A.class
B.class
C.class
D.class
E.class
本の平積みと同じ意味だよ
平にするって所を強調したいんだ
ポリモーフィズムって押し付けなんだよね
汎用的な機能を提供する
与える引数だけが戻り値を決めるような
純粋な関数を1つくればDRYになっていいものを、
何らかの意図を持った特化した関数を
幾つも定義しなければならない
意味がわからない。
インスタンスには極力状態を持たせない方が
圧倒的にバグが少ない
UI制御の状態ならGUI上だけで
本当に重要な状態ならDB上やセッションとかで
持つくらいで大体は事足りる
クラスのフィールドなんてほとんど使わんよ
引数と戻り値
配列 連想配列をとことん突き詰めれば
大抵の事はなんでも出来る。
これが構造化プログラミング
>>451
それが設計意図がキチンとドキュメントにまとまっていれば
こうなったときに引数増やすしか無いかとかわかるんだけど
だいたいドキュメント書かないバカがノリで作ったようなポリモだから
頭にくるんだよね
作ったやつのおバカなドヤ顔に拳をブチ込んでその場で正座させながらドキュメント書かせたい >>451
単純にモジュール切り分けテクニックの一つなだけだよ。
変な切り分けすればそりゃ可読性悪くなるわ。
オブジェクト指向をいつでもすべしみたいな馬鹿が誤解をひろめたのがいかんだけで有用なテクニックの一つではある。 ドキュメントとセットでの運用なら、
それ自体では完結してない、つまりは欠陥品ってことでしょ
ドキュメントの有無や書いた奴の頭の程度で決定したりはしない
>>455
visualstudioがWordやExcelと連携してくれれば楽なのにね ソリューションエクスプローラーなんて芋っポイのやめてWordの項目一覧でいいよ
そこの項目に対応したソースを記述すればいい
ソリューションエクスプローラのCMakeターゲットビュー見てみろよ。
そんなこと言えなくなるだろ。
それはちょっと違うかもしれないな。
プログラミング言語は自然言語と比較して非常に制約がきつく、それは機械が読めるほどだ。
自然言語で書くよりもプログラミング言語で書く方が誤解の余地が少ない優れた文書になるのではないか。
data Status = Dead | Alive
you == not Alive
お前はもう死んでいる
>>455
プログラムで表現しずらいものをドキュメントで補うんだよ。
SIerに提出するような糞アリバイドキュメントばっかりつくってると理解できないだろうけれど。 プライベートメソッドのドキュメントを作るんだろ？
欠陥品じゃん
プライベートだろうとパブリックだろうと、構造がコードでわかりにくけりゃ作るよ。
そういう表面的なことでしか判断できないのは頭が悪い証拠だと思うよ。
要するに馬鹿にはプログラミングさせるなということだな
馬鹿が書くと変なものをprivateにしてしまって大混乱
プライベートメソッドをテストせざるを得なくなる
普通は表面的＝形式的なモンで判断するんでしょこの業界
だって形式しかねーもん
構造図みたいなのはプログラム内には書けないから
それは文章化しておくしかないから仕方がない
