カプセル化■プライベートメソッドをテストする方法

**デフォルトの名無しさん** · 2020/07/05(日) 20:47:46.60

■短い回答
プライベートをテストしたい場合は設計に問題があるので、パブリックに変更してテストしましょう

■これに対する（変な人の）驚いた反論

プライベートを一時的にパブリックにして、テストが終わったら
プライベートに戻すなんてやるわけないだろｗ
↑誰もそんなコトしろなんて言ってない

■テスト専門家による回答

t-wadaのブログ
https://t-wada.hatenablog.jp/entry/should-we-test-private-methods

短くまとめると、プライベートなメソッドのテストを書く必要は無いと考えています。

ほとんどのプライベートメソッドはパブリックメソッド経由でテストできるからです。
プライベートメソッドは実装の詳細であり、自動テストのターゲットとなる「外部から見た振る舞い」ではありません。
プライベートなメソッドのテストに関しては、4つの考え方があります。

・パブリックメソッド経由でテストする
・別クラスのパブリックメソッドとする
・テスト対象の可視性を（やや）上げる
・プライベートのまま、リフレクションでアクセスしてテストを書く

パブリックメソッド経由でテストする
多くの場合、そのクラスのパブリックメソッド経由でプライベートメソッドのテストも同時に行えます。テストできているか不安があるならテストカバレッジを確認しましょう。

別クラスのパブリックメソッドとする
プライベートなメソッドのテストを書きたいということは、実はテスト対象の責務が多すぎることを示唆している場合があります。
テストがどうしても書きたい場合は、その責務はテスト対象のプライベートな振る舞いではなく、他の誰かのパブリックな振る舞いなのでしょう。

**デフォルトの名無しさん** · 2020/07/08(水) 21:19:38.42

>>189
あのさぁ、ごまかしてないでちゃんと書こうよ？

最小、最大、中間値のテストやってれば
最小、最大、中間値ではない3のテストなんて不要なんだよって
ちゃんといわないと、あのバカには伝わらないよ？

**デフォルトの名無しさん** · 2020/07/08(水) 23:59:05.09

最小、最大、中間値って聞いたことがないけど
どこかの分野で一般的に使われてるもの？

境界値分析なら
境界値と境界値の内側と外側の3値か
境界値と境界値の外側の2値かどっちかが一般的だと思う

**デフォルトの名無しさん** · 2020/07/09(木) 00:14:35.43

>>191
3と78がそれに当たると申すか？

**デフォルトの名無しさん** · 2020/07/09(木) 00:16:52.90

俺もそう思ってたけど、そもそもスレタイともずれてきてるよねっていう

**デフォルトの名無しさん** · 2020/07/09(木) 00:21:36.93

3と78の伏線が
今、回収されたのか？

**デフォルトの名無しさん** · 2020/07/10(金) 12:24:37.85

詳細を知ってはならないということは、詳細の知識、つまり境界を知ってはならないということ。

「彼らはオブジェクト指向を全く知らない可哀そうな人ではないか？Javaを学ぶべきだ！」などと言う前に、原典に当たろう。

**デフォルトの名無しさん** · 2020/07/10(金) 12:25:53.05

>>195
オブジェクト指向と関係ない話なら、関係ないって書いとけよ

**デフォルトの名無しさん** · 2020/07/10(金) 12:54:55.71

zTLocdwC以外、Javaなんて誰も言ってないけど？何が言いたいんだ？

スレタイはカプセル化って書いてあるしOOPは理解している前提でしょ？
まぁ、明らかにOOPを理解していない人が発狂していたけど。

**デフォルトの名無しさん** · 2020/07/10(金) 14:04:44.56

いや、おそらくわかっていないだろう。

**デフォルトの名無しさん** · 2020/07/10(金) 14:09:26.25

オブジェクト指向のすばらしさを語っている人が、一番オブジェクト指向を知らない。
ゆえに議論が成り立たないという状態ではないだろか。

**デフォルトの名無しさん** · 2020/07/10(金) 14:12:09.99

>>196
隠ぺいとオブジェクト指向は直行する概念ではある。
とはいえ、事実上同時に用いられるので、関係ないとは言えないのではないか。

**デフォルトの名無しさん** · 2020/07/10(金) 15:02:20.85

>>200
そもそも、このスレで誰もオブジェクト指向の素晴らしさなんて語っていない。

さっきから誰に対して言ってるんだ...。

**デフォルトの名無しさん** · 2020/07/10(金) 15:16:19.83

ポエってるやつがいるな

**デフォルトの名無しさん** · 2020/07/10(金) 16:07:13.59

和田メソッドを称賛してる人たちに決まってるだろ。

**デフォルトの名無しさん** · 2020/07/10(金) 16:35:36.39

和田メソッドって何？

**デフォルトの名無しさん** · 2020/07/10(金) 17:14:49.72

>>1 に書いてあるだろ。

**デフォルトの名無しさん** · 2020/07/10(金) 17:42:15.92

>>1に書いてあるのはただの常識で
和田メソッドなんて特別な名前じゃないよ

**デフォルトの名無しさん** · 2020/07/10(金) 20:12:23.39

常識を疑え、それって和田メソッドじゃないかって

**デフォルトの名無しさん** · 2020/07/10(金) 20:49:58.98

常識じゃん。むしろ、常識を疑うその心を疑え。それって経験不足では？

まぁ、強いて言うのなら、リフレクションを用いてテストは、許してはならない反則行為だと思うがな。
特に、カバレッジテストとかする場合は。

**デフォルトの名無しさん** · 2020/07/10(金) 21:00:54.86

ただ、記事を書いた和田さん？も、記事を読むとその危険性を理解しているみたいだから対立する気はないよ。
黒魔術と言ってるし。

なんで黒魔術なんでしょうねぇ(すっとぼけ)

**デフォルトの名無しさん** · 2020/07/10(金) 21:09:49.17

そりゃC++への嫉妬だろ
C++はそう呼ばれるのに、Javaは何故かそうは呼ばれない、それは何故か？
Javaに欠けているものとは一体……？！

**デフォルトの名無しさん** · 2020/07/10(金) 21:30:17.43

黒魔術って言われ方を誉め言葉だと思ってる馬鹿ってほんとにいるんだな。。

**デフォルトの名無しさん** · 2020/07/10(金) 21:36:39.85

オブジェクトが隠蔽・カプセル化するものだからといってホワイトボックステストまで否定しちゃうのは変な話。

**デフォルトの名無しさん** · 2020/07/10(金) 21:51:04.37

ホワイトボックステストを否定する気はないけど...例えば
>>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メソッドを定義するケース自体、珍しいから、経験則に基づかない発言でもあるが...。

**デフォルトの名無しさん** · 2020/07/10(金) 21:56:59.04

和田メソッドは非常識

**デフォルトの名無しさん** · 2020/07/10(金) 22:02:19.60

和田さんはQueueを実装したことない素人

**デフォルトの名無しさん** · 2020/07/10(金) 22:04:28.86

あー...うん、俺の言い方が悪かったかも。
privateメソッドをテストするというレアケースだから許してくれ。
常識が無い以上、もっと正確に細かく伝えるべきだったな。

ただ、俺の主張(リフレクションは反則
行為)の弱い点を言うと、OOPやDDDの概念を無視した設計には、こちらの主張は当てはまらない。
そう思うと、和田さんのリフレクションをギリギリ許容(？)するような記事の書き方も否定はできん。

なんだかんだで、彼の記事は自分が記事を書くよりは無難にまとめられているとは思う。
まぁ、記事を書いたことないけど。

**デフォルトの名無しさん** · 2020/07/10(金) 22:09:19.05

ユーザーが直接public methodを使うわけじゃなければ
public methodだって実装の詳細

integration test経由で
必要なpublic methodはテストできるんだから
個別にすべてのpublic methodをテストする必要なんてない

というのと似たようなもの
それでいい場合もあればそうじゃない場合もあるというだけ

**デフォルトの名無しさん** · 2020/07/10(金) 22:23:15.71

まあね、処理の複雑さによるのだろうね
hello world程度ならテストさえ必要ないだろうし

**デフォルトの名無しさん** · 2020/07/10(金) 22:31:36.66

>>213
どうするの？っていうそこの何が問題なのかわからん。
必要以上の詳細をテストしてしまうことによってテストが壊れやすくなるという
一般的な話以上のものではないように思うが。

**デフォルトの名無しさん** · 2020/07/10(金) 22:38:32.51

そこで、テスト駆動開発ですよ。
最初にテストケースを定義してそれをパスする
コードを書けばpublicだのprivateだの議論は不要

だれかこの開発方法やってる？

**デフォルトの名無しさん** · 2020/07/10(金) 22:54:55.64

>>220
privateだとテストケース書けないじゃん

**デフォルトの名無しさん** · 2020/07/10(金) 23:26:01.49

>>219
不合格になるはずのテストに合格してしまうのが問題なんだよ。

>>220
テスト駆動開発は社内でも聞いたことがあるけど、実践はしてない。
まぁ、自分自身、詳細は知らない。後で調べるか。

**デフォルトの名無しさん** · 2020/07/11(土) 00:18:29.78

>>213
> ...で、これでカバレッジテストに合格しちゃったらどうするの？

テストはテストコードを見ないで
OKってでたからOKだ
ってやるもんじゃないよ

テストコードはレビューするものだ
通ったからOKじゃなくて、通るのは当たり前で
テストコードを見て正しくテストされてることを確認する

テスト結果のOKが「エビデンス」なのではなくテストコードが「エビデンス」
動作してることを証明するスクリーンショット（笑）と同じもの
「エビデンス」は見て確認しなければいけない

**デフォルトの名無しさん** · 2020/07/11(土) 00:21:18.34

>>221
テストケースがあるもの＝publicメソッドで
privateは中で必要に応じて作るもの
メソッドにしてもいいしメソッドにしなくてもいい

テストケース書けないなら関数にせずにそのまま埋め込めよ
publicメソッドのテストケースが問題ないなら
中の詳細なテストなんかいらんだろ
メソッドにしてないかもしれないし

**デフォルトの名無しさん** · 2020/07/11(土) 00:34:45.26

何回繰り返すのこの流れww

**デフォルトの名無しさん** · 2020/07/11(土) 00:40:55.17

何度でもだ！

**デフォルトの名無しさん** · 2020/07/11(土) 00:42:45.65

>>224
テストケースが書けないってだけでインライン展開するんすか？
構造化プログラミングを愚弄する狼藉っすよ
遠山の金さんの桜吹雪を拝むことになりますよ

**デフォルトの名無しさん** · 2020/07/11(土) 00:43:07.74

遠山の和田さん

**デフォルトの名無しさん** · 2020/07/11(土) 00:45:42.66

privateではなくてパッケージプライベートにした方がええのかもわからんね

**デフォルトの名無しさん** · 2020/07/11(土) 00:53:34.50

それで破綻するならパッケージの設計がよろしくないということで

**デフォルトの名無しさん** · 2020/07/11(土) 01:01:26.38

>>227
テストケースが書けるならばpublicにすればいいだろ？
テストケースがある＝仕様が明確になってる証拠

**デフォルトの名無しさん** · 2020/07/11(土) 01:06:55.98

なんでテストケースが作れるのに、publicにしないのかわからん

**デフォルトの名無しさん** · 2020/07/11(土) 01:42:00.39

https://encrypted-tbn0.gstatic.com/images?q=tbn%3AANd9GcTboCDgKcAdRNVwzxZWd6r45jypRuoKCBL21A&;usqp=CAU

**デフォルトの名無しさん** · 2020/07/11(土) 02:18:29.03

privateでかっこいいメソッドなんだろうがよ!

いや、俺実はpublic staticしか作らんけど

**デフォルトの名無しさん** · 2020/07/11(土) 02:41:27.63

>>222
正直、開発自体をテスト工藤開発で終えるのはキツいと思うけど、
コーディング→動作確認→デバッグ→リファクタリングの
プログラマー個人の短いサイクルでのトライ&エラーには結構使えるんじゃないかと思う。

カバレッジ100%のテストケースは作る工数とメンテが大変だからそこまでする必要はないと思うけど、
そこそこのカバレッジでプログラマーが個人で高速に開発を回せるのは強い。

カバレッジ100%目指すのは単体テストの時だけで十分

**デフォルトの名無しさん** · 2020/07/11(土) 02:42:42.87

>>235
せやかて

**デフォルトの名無しさん** · 2020/07/11(土) 06:05:52.59

t-wada氏の推奨する和田メソッド。

**デフォルトの名無しさん** · 2020/07/11(土) 06:15:18.08

和田メソッドによると「非公開メンバをテストすると品質が下がるので絶対するな！」

**デフォルトの名無しさん** · 2020/07/11(土) 07:08:50.24

>>238
それどこに書いてあるの？

**デフォルトの名無しさん** · 2020/07/11(土) 07:51:10.03

意識が高くなりすぎて幽体離脱した感のある和田メソッドをよろしく！

**デフォルトの名無しさん** · 2020/07/11(土) 07:55:47.65

>>22
いや、その「不合格になるはず」のところがわからん。
呼べないはずの内部実装が呼べちゃったってこと？

**デフォルトの名無しさん** · 2020/07/11(土) 09:06:32.32

>>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の呼び出しで合格できなかった網羅テストを内部実装を直接呼び出して合格って変な話。

という意味では？

**デフォルトの名無しさん** · 2020/07/11(土) 09:23:48.86

>>242
でもカバレッジって落ちないぜ以上の意味を取るのって無理じゃね？

**デフォルトの名無しさん** · 2020/07/11(土) 09:26:28.69

>>242
いや、ますますわからん。
そのタイミングで内部実装()呼んでもaの値は変わらんと思うが？

pop()の前に呼ぶんだとしたらなんでそんなテストを書くんだという話になるし。
異なる操作をしたならassert条件が変わるのは当たり前。

**デフォルトの名無しさん** · 2020/07/11(土) 09:35:57.08

>>244
前者は私のミス

>>243
ごめん、カバレッジやったことないから間違っていたら謝る

うーん、この解釈を間違えた感

**デフォルトの名無しさん** · 2020/07/11(土) 09:55:21.63

>>242
まずテストの考え方が違うんだよ。

全ての組み合わせをテストする完全な網羅テストは時間的に不可能
その他のテストも数によっては現実的に不可能となることが多い
通常カバレッジ100%というのは命令網羅テストにすぎない
だが命令網羅テストをやってれば完璧かと言うかそうではない

じゃあどれをやればいいんだよ！？と思うかもしれないが、どれをやるかじゃない
何をやれば自分が作ったものが正しく動くと自信が持てるかなんだよ
現実的に実現可能であるというルールを加えれば、完璧なテストなんてできやしない。

内部実装を直接呼び出して合格したとしても、
それで正しく動くと自信が持てるなら、それで全然かまわないんだよ。
ただしテストする以上、内部実装の仕様を明確にしなきゃテストのレビューはできなくなる。
内部実装の仕様が明確になったならpublicにして問題ない。

おまけだが、pubicメソッドのテストでもprivateメソッドのテストでも
カバレッジを計測するなら、それはホワイトボックステストだからな
なんか間違ってる人がいるようだから

**デフォルトの名無しさん** · 2020/07/11(土) 09:55:24.65

結局クラス分けするなりしてpublicにする部分を多くする、
テストと使用する局面で可視性を変える
の二つしかないわけで、プログラム機能でどうこうする話じゃない。
使う奴が理解して使うという話以上にはならん。

**デフォルトの名無しさん** · 2020/07/11(土) 10:23:35.92

「privateメソッドがテストできないんですがどうしたらいいですか？」という疑問に対して、
なんとかしてテストする方法を編み出すのではなく「privateメソッドはテストしなくていい！」という
逆転の発想というかバッサリ感が中二受けしたんだと思う。

**デフォルトの名無しさん** · 2020/07/11(土) 10:26:24.09

じゃあ編み出してどうぞ

**デフォルトの名無しさん** · 2020/07/11(土) 10:36:26.55

>>248
逆転の発想じゃなくて普通の発想じゃね？
privateなんだから

**デフォルトの名無しさん** · 2020/07/11(土) 10:53:54.57

だって可視性とテストするしないの関係は自明じゃないじゃん。
それが関係あるなら外部にexportする関数以外はテストしなくていいことになるんじゃね？

**デフォルトの名無しさん** · 2020/07/11(土) 11:13:39.51

>>231
教えてしんぜよう
アクセス修飾子は仕様が明確になってることを表すものではないからだ

**デフォルトの名無しさん** · 2020/07/11(土) 11:16:43.36

publicにしたら全然関係ないパッケージからもアクセスされてしまうからね
不必要な依存を発生させることになってしまう、密結合が促進されるね
そういう意識のない人間が >>3 のような下痢便コードを書いてしまうんだね

**デフォルトの名無しさん** · 2020/07/11(土) 11:18:39.33

>>252
アクセス修飾子は仕様が明確になってることを表すなんて言ってないよ
仕様が明確になってるならpublicでいいと言ってるだけ

**デフォルトの名無しさん** · 2020/07/11(土) 11:19:08.47

>>253
> publicにしたら全然関係ないパッケージからもアクセスされてしまうからね

全然関係ないパッケージ = テストコード
アクセスできてなにか問題あるの？

**デフォルトの名無しさん** · 2020/07/11(土) 11:20:35.92

>>254
言ってるじゃん、アクセス修飾子とメソッドの仕様が明確になってるかは無関係

**デフォルトの名無しさん** · 2020/07/11(土) 11:21:19.03

>>255
何いってんのお前
テストは同じパッケージにするのが基本だろ
テストしたこと無いの？

**デフォルトの名無しさん** · 2020/07/11(土) 11:22:19.30

テストから呼び出せるのが問題なんじゃなくて
関係ないパッケージから呼び出されて密結合になるのが問題だと言ってる

**デフォルトの名無しさん** · 2020/07/11(土) 11:22:42.09

だからパッケージプライベートなら良いだろうと言ってるわけ

**デフォルトの名無しさん** · 2020/07/11(土) 11:25:32.87

>>256
言ってないよ？

外部からアクセスしないならprivate。
でも仕様がはっきりしてるならpublicにしていい。

facebookでもプライベートな話は他人に見せる必要がないからprivateだけど
別に他人に見せてもいいならpublicにしてもいいよね
それと一緒

**デフォルトの名無しさん** · 2020/07/11(土) 11:26:14.03

パッケージプライベートだと同じパッケージからならアクセスして良いというメッセージを
開発者に伝えてしまうから望まない依存を生んでしまうリスクはある
どのオブジェクトからも参照されたくない場合もあるからな、やはりprivateをテストできない
言語が遅れてるだけなのだろうね

**デフォルトの名無しさん** · 2020/07/11(土) 11:26:21.59

>>257
> テストは同じパッケージにするのが基本だろ

Java以外で、同じパッケージとはなんのことで
そうするとどうなるんですか？

**デフォルトの名無しさん** · 2020/07/11(土) 11:27:14.70

>>260
外部からアクセスしないけれども仕様がはっきりしてるからpublicにするのはありえないってことですよ
なぜならば密結合になってしまうから

**デフォルトの名無しさん** · 2020/07/11(土) 11:27:56.48

>>261
privateをテストできる言語っていうのは
単に全てpublicになっているのと一緒

アンダースコアで、これはアクセスできるけど
privateという意味ですよと言ってるのと何も変わらないよ

**デフォルトの名無しさん** · 2020/07/11(土) 11:28:00.37

>>262
Javaの話ですよ

**デフォルトの名無しさん** · 2020/07/11(土) 11:28:48.86

>>264
アンダースコア？
そうなの？全部の言語がそんな仕様なの？
それは知らなかったなー

**デフォルトの名無しさん** · 2020/07/11(土) 11:29:55.28

>>263
仕様がはっきりしてるからpublicにするんじゃなくて
仕様をはっきりさせれば、publicにしてもよいと言ってるだけ
理由がなければprivateのままでもいい。どちらでもいい。
テストしたい＝理由。理由があるならpublicにしていい。

> なぜならば密結合になってしまうから
テストコードから仕様がはっきりしないprivateをテストすること＝密結合
密結合を避けるためにも、公開されたインターフェースにするのが正しい

**デフォルトの名無しさん** · 2020/07/11(土) 11:30:13.81

RustやGoはprivateもテストできるよって言ってる人いたから
最近の言語ではprivateもテストできるんだーって思ってたけど
命名規則でアクセス修飾子の代わりを果たしてるんだってことだったの？それは知らなかったなー

**デフォルトの名無しさん** · 2020/07/11(土) 11:30:22.00

>>265
Java以外を知らないんですか

>>266
Java以外を知らいんですかｗ

**デフォルトの名無しさん** · 2020/07/11(土) 11:30:59.34

>>268
ああ、人から聞いただけなのねｗ

**デフォルトの名無しさん** · 2020/07/11(土) 11:31:27.48

>>267
仕様がはっきりしててもpublicにしてはいけないからprivateなんだよ
テストが依存することを密結合とは言わないよ

**デフォルトの名無しさん** · 2020/07/11(土) 11:31:51.16

>>269
知らないよ

>>270
そうだよ

**デフォルトの名無しさん** · 2020/07/11(土) 11:32:06.66

privateにあくせすできる言語でも
テストするならどちらにしろ仕様をはっきりさせないといけない

そうしないとテストコードがあったからといって
これが正しく仕様を満たしているのか？なんてわからない

**デフォルトの名無しさん** · 2020/07/11(土) 11:35:07.08

さすがです >>3 の下痢便コード書くだけありますね
何言ってるのかさっぱりわからない

**デフォルトの名無しさん** · 2020/07/11(土) 11:36:54.90

>>3のコードを書いたのは別の人。

そもそも>>3のコードをクソコードと言って
このスレにコピペしたのが俺

**デフォルトの名無しさん** · 2020/07/11(土) 11:38:14.80

>>275
そうすると君はMainを勘違いしてた人か、僕と仲直りしますか？

**デフォルトの名無しさん** · 2020/07/11(土) 11:39:33.67

同じ人が同じこと言ってるだけのスレ
でもそんなスレも良いですよね

**デフォルトの名無しさん** · 2020/07/11(土) 11:47:13.10

たとえばこの先Javaが進化したとしてテストオブジェクトのみを特別視して
テストオブジェクトからのみprivateにアクセスできるようになったとすると
テストオブジェクトをオブジェクト指向の枠組みで捉えるならば
オブジェクト指向としては破綻してる

Javaは受け入れないだろうね、Microsoftがdelegateを提案したときも
interfaceという仕組みがあるんだからdelegateは邪道だと言って蹴ったからなあ

実益に叶うという理由で根本的なところまで作り変えることができるのは
Microsoftだろうなあ、Javaの前にC#が対応しそうな予感はある

**デフォルトの名無しさん** · 2020/07/11(土) 11:52:27.04

いまの言語仕様での最適解は >>5 ですね
これ書いた人は天才だと思いますよ
何気ないことだけれどもコードの隅々にまで神経が行き届いていて
美しく整備されて堅牢なコードです、オブジェクト指向の限界を示したと言って良いですね

**デフォルトの名無しさん** · 2020/07/11(土) 11:55:21.12

>>248
逆転の発想じゃなくて都合のいいことを信じたい馬鹿の発想だろ

**デフォルトの名無しさん** · 2020/07/11(土) 12:00:30.64

テストコードは設計の外にあるものだからクラスの可視性とか直接関係ないだろ。
ふつう、設計書のクラス図にテストクラスを書いたりはしない。

**デフォルトの名無しさん** · 2020/07/11(土) 12:02:06.50

書いてもいいかなとは思う

**デフォルトの名無しさん** · 2020/07/11(土) 12:06:30.88

>>281
そうなんだよねー

**デフォルトの名無しさん** · 2020/07/11(土) 12:09:38.93

>>281
クラス図にprivateメソッドを書きますか？

**デフォルトの名無しさん** · 2020/07/11(土) 12:11:12.25

クラス内を調査してprivateメソッドを列挙して
同クラス内のprivateメソッドをテストするコードを列挙して
カバレッジを計測するツールがあればみんな幸せになれそうですね

カバレッジ計測ツールがprivateメソッドには今の時点で対応してないって
だけでprivateメソッドのテスト自体は >>5 のように書けますから
ツールの開発が遅れてるだけなのかも知れませんね

**デフォルトの名無しさん** · 2020/07/11(土) 12:12:35.29

>>285
もしかしてお前カバレッジの意味がわかってないんじゃね？

publicメソッドの中からprivateメソッドが呼び出された時
privateメソッドの行は実行された＝カバレッジとして計測される

ってことは知ってますよね？

**デフォルトの名無しさん** · 2020/07/11(土) 12:15:06.18

世の中にある全てのカバレッジ計測ツールは
privateメソッド内の実行した行を測定できるのですが
>>285を見る限り何もわかってない気がしますねｗ

**デフォルトの名無しさん** · 2020/07/11(土) 12:15:29.92

>>286
僕は単体テストやったこと無い
カバレッジの計測もしたことないからわからない
僕は知りません

**デフォルトの名無しさん** · 2020/07/11(土) 12:16:06.22

>>288
だから>>285みたいな的はずれなことを言ってるんだねｗ

**デフォルトの名無しさん** · 2020/07/11(土) 12:17:45.08

>>289
それにはちょっと異論があるんだけれども、今回は僕が折れましょう
僕と仲直りしますか？