カプセル化■プライベートメソッドをテストする方法
■ このスレッドは過去ログ倉庫に格納されています
■短い回答
プライベートをテストしたい場合は設計に問題があるので、パブリックに変更してテストしましょう
■これに対する（変な人の）驚いた反論
プライベートを一時的にパブリックにして、テストが終わったら
プライベートに戻すなんてやるわけないだろｗ
↑誰もそんなコトしろなんて言ってない
■テスト専門家による回答
t-wadaのブログ
https://t-wada.hatenablog.jp/entry/should-we-test-private-methods
短くまとめると、プライベートなメソッドのテストを書く必要は 無い と考えています。
ほとんどのプライベートメソッドはパブリックメソッド経由でテストできるからです。
プライベートメソッドは実装の詳細であり、自動テストのターゲットとなる「外部から見た振る舞い」ではありません。
プライベートなメソッドのテストに関しては、4つの考え方があります。
・パブリックメソッド経由でテストする
・別クラスのパブリックメソッドとする
・テスト対象の可視性を（やや）上げる
・プライベートのまま、リフレクションでアクセスしてテストを書く
パブリックメソッド経由でテストする
多くの場合、そのクラスのパブリックメソッド経由でプライベートメソッドのテストも同時に行えます。テストできているか不安があるならテストカバレッジを確認しましょう。
別クラスのパブリックメソッドとする
プライベートなメソッドのテストを書きたいということは、実はテスト対象の責務が多すぎることを示唆している場合があります。
テストがどうしても書きたい場合は、その責務はテスト対象のプライベートな振る舞いではなく、他の誰かのパブリックな振る舞いなのでしょう。 車の運転がうまい人は車の危険性を知ってる人
和田メソッドを熟知した人なら和田メソッドの危険性を知ってると思うのだよ
和田メソッドの限界はどこにあるのだろうね
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の習慣は誠に遺憾 自分の説明能力の無さを相手が低脳だからと責任転嫁するヤシ ■ このスレッドは過去ログ倉庫に格納されています
