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

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

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

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

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

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

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

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

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

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

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

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

**デフォルトの名無しさん** · 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
それにはちょっと異論があるんだけれども、今回は僕が折れましょう
僕と仲直りしますか？

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

>>290
でもおまえ単体テストしたこと無いし
カバレッジの計測もしたことがないから
何も理解してないじゃん（笑）
問題はそこだよね。

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

>>284
開発の段階によって違うんじゃね？最終的な設計ドキュメントには書いてるかな。

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

>>291
問題はそこじゃないです、君は僕と仲直りますかということが問題です

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

僕はいままで手作業による結合テストだけで生き抜いてきた生粋のブラックボックスマンです
なぜそれが可能だったかというと簡単なプログラムしか書いたことがなかったからです
しかし、最近複雑なプログラムを書く機会があり結合テストだけでは不十分であることを実感しました
以上、僕の近況報告です

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

僕は単体テスト書いたことありますよ >>5 で書きました
カバレッジは計測したことないですけどそれは重要ではありません

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

>>293
しません

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

>>292
最終的な設計ドキュメントはコードから生成するものだからね
クラス図にprivateメソッドが書かれていて嬉しいのでしょうかどうなのでしょうか？

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

> 最終的な設計ドキュメントはコードから生成するものだからね
クラス図の話ね。クラス図は（唯一？）コードから生成できる。

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

>>296
(´・ω・`)

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

正直、詳細なクラス図は、設計図の中で一番不要だと思ってる。
必要なのはソースコードと完全に一致してるクラス図ではなく
クラス概要図・関連図とでも言うべきだろう

主要なメソッドとそれぞれのクラス関係がわかればいい
目的はなにかを考えればその結論にたどり着くはず

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

>>297
保守する人にとってはあった方がいいと思ってる。

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

単体テストという言葉の曖昧さがpublic派か、private派かの分裂の原因です

publicメソッドはオブジェクトのインターフェイスなので
publicメソッドをテストすることをインターフェイステストというべきです
オブジェクト指向で、インターフェイスが関わるのはオブジェクトのコラボレーションが行われるときです

一方でprivateメソッドはpublicメソッドが作られるのと同じか、もしくはそれ以前に作られます
publicメソッドが正しく動作することの前提としてprivateメソッドが正しく動作することがあるので
privateメソッドをテストすることをインプリメンテーションテストという言うべきです
privateメソッドを使用するのは同じオブジェクト内のメソッドなので、オブジェクトのコラボレーションとは直接の関係がありません

単体テストと言っても対象のメソッドによって、テストが必要な時期が異なるわけです
privateのテストはクラスが作られる前に行われますし、publicのテストがクラスは作られた後に行われます

あとはコストの話です、結合テストがすべて通るなら単体テストは必要ありませんし本番稼働がすべてうまくいくならテスト自体必要ありません
後の工程で発覚するほど手戻りが大きくなりコストが膨らむので段階を追ってテストしていきましょうというのが基本的な考え方です

privateのテストをすることによってpublicのテストの手戻りが少なくなることはあるんです
privateのテストはやったほうが良いです。

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

>>301
保守する時はコードから生成できるので完璧なのはいらない
だから本当に必要なのはクラス概要図だろう

図としてみたい場合、メソッドすべてがずらずら書かれていても邪魔なだけ
ましてやprivateなんていらない。
図としてみたい場合、本当に見たいのは関連だろう？

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

>>302
> 単体テストという言葉の曖昧さが

それ以前に、おまえ単体テストしたこと無いし
カバレッジの計測もしたことがないから
何も理解してないじゃん（笑）
問題はそこだよね。

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

頑張って書いた、これはもう論文と言って良いのでは
僕はプログラミングのテストについて博士号もらっても良いのでは
少なくともこのスレではテストに一番詳しい

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

>>304
僕は >>5 で単体テスト書きましたよ
君はカバレッジ計測ツールを使用して理解した気になってるだけのアホです

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

僕はツールを使ったことはないけど、頭を使うからね

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

288 返信：デフォルトの名無しさん[] 投稿日：2020/07/11(土) 12:15:29.92 ID:JFnadz6+ [26/35]
>>286
僕は単体テストやったこと無い
カバレッジの計測もしたことないからわからない
僕は知りません

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

>>308
>>5 では書きましたよ

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

君はレトリックな部分に引きづられる傾向があるから
もう少し客観的に遠目でものを見るようにしたが良いかも

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

僕はJavaしか知らないと言ったけどC#に関するあっと言わせるような知識と考察を垣間見せたでしょ
僕の知性あふれる想像力は君の経験を凌駕する
ツールに習熟して使いこなすのも大事だけど、頭を使って状況を分析して打開する力も大事
僕は後者の方が優れている、君と僕が手を組めば最強になれる
僕と仲直りしてくれますか？

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

TDD信奉者がprivateメソッドのテストは必要ないと主張するのは当たり前

TDDは一般的にpublicメソッドを最小”ユニット”として書き始めるから
privateメソッドが作られるのはテストが通る状態を維持したままリファクタリングして
一部をprivateメソッドに抽出した場合だけ
だからprivateメソッドのテストを書く必要がない

privateメソッドじゃなくHelperクラスのpublicメソッド等に抽出した場合も同じ
HelperクラスをpublicなAPIとして公開するのでなければ別途テストを追加する必要は基本的にない

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

和田メソッドよろしく！

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

>>312
なるほどね

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

和田さんの話にも飽きたので、レガシーコード改善ガイドという本の話でもしようか？
https://bmf-tech.com/posts/%E3%83%AC%E3%82%AC%E3%82%B7%E3%83%BC%E3%82%B3%E3%83%BC%E3%83%89%E6%94%B9%E5%96%84%E3%82%AC%E3%82%A4%E3%83%89

・クラスのメソッドがprivateだったとき
　　・publicメソッドを通じたテストが可能か検討する
　　　　・publicメソッドを通じたテストを行うことで実際のコードと同じ方法によるテストが保証できる
　　・上記が可能でない場合
　　　　・そのprivateメソッドはpublicにすべき
　　　　　　・大抵の場合はそのクラスが多くのことをやりすぎている、再設計が必要であることを意味している
・privateメソッドをpublicメソッドにすることについて悩む点
　　・メソッドが単なるユーティリティで、呼び出し側が気にかけるものでない
　　　　→そのメソッドを別クラスに移せないか検討する
　　　　→クラスのインターフェースに余分なpublicメソッドがあることは許容可能
　　・呼び出し側がそのメソッドを直接使った場合、そのクラスの他のメソッドの結果に悪影響を及ぼす可能性がある
　　　　→そのメソッドを別クラスに移し、移動先のクラスでpublicにする
・良い設計とはテストが可能であり、悪い設計はテストが不可能

まあ言ってることはほとんど同じなんだけどなｗ

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

https://maku.blog/p/p6awy3z/#%E7%AC%AC10%E7%AB%A0-%E3%81%93%E3%81%AE%E3%83%A1%E3%82%BD%E3%83%83%E3%83%89%E3%82%92%E3%83%86%E3%82%B9%E3%83%88%E3%83%8F%E3%83%BC%E3%83%8D%E3%82%B9%E3%81%A7%E5%8B%95%E3%81%8B%E3%81%99%E3%81%93%E3%81%A8%E3%81%8C%E3%81%A7%E3%81%8D%E3%81%BE%E3%81%9B%E3%82%93

第10章このメソッドをテストハーネスで動かすことができません

テストしたいメソッドが private である
・private メソッドをテストしたい場合、そのメソッドは public にすべきである。
・public メソッドにすべきかどうかで悩んでしまう場合、大抵は、そのクラスが多くのことを行いすぎであり、
修正すべきことを意味している（1つのクラスが複数の責務を持ってしまっている）。
・よい設計はテスト可能であり、テスト可能でない設計は悪い設計である。

・この方法は、メソッドを単純に public 化するのと本質的には変わらないので微妙な対応方法だが、リファクタリングすべき箇所の目印となる。
・Java などの言語ではリフレクションによって private メソッドのテストを記述することはできるが、
根本的な依存関係の問題を先延ばしにしているだけである。その種のごまかしをすると、
コードがどの程度悪くなっているのかに気付きにくくなってしまう。

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

北朝鮮行ったことあるか？

日本の町並みには看板があるだろ？
「パナソニック」とか「コカ・コーラ」とかだよな。

北朝鮮でこれに該当するのはスローガンの看板だから。
社名や商品名の看板は一切ない。
「ウリナラをキノコの国にしよう！」←裏の意味は無くそのままの意味らしい。
「苦難の行軍！」
「白頭の革命精神！」

和田メソッドに通じるものがあるよな。

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

>>317

他のスレで書いたけど「例え」は物事をわかりやすく説明するために使うもの
何かを批判するために「例え」を使うのは悪手。なぜなら
「例え」で批判してるのは「例え」に使ったものだから

お前が批判してるのは北朝鮮であって
和田さんや「レガシーコード改善ガイド」の
ベストプラクティスの批判にはなっていない

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

和田メソッドは時代遅れの遺物。

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

t-wada氏がお勧めする和田メソッド。

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

話をしようかと言い、本の内容をコピペしただけとかゲンナリするよね
たとえ批判されても自分が言ったわけじゃないから問題ないわけですね
スネ夫メソッドと名付けましょう

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

本に書いてあることを自分なりに実践してみた結果大失敗して
和田メソッドは役に立たなかったとかそういう話が聞きたい

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

実践した結果コードがきれいになり
テストがしやすくなったよ

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

>>323
さようか

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

車の運転がうまい人は車の危険性を知ってる人
和田メソッドを熟知した人なら和田メソッドの危険性を知ってると思うのだよ
和田メソッドの限界はどこにあるのだろうね
TDDが向かないプログラムもあるとは本に書いてあるけど
それが具体的にどういう状況か、どういうプログラムかは示されないからよくわからない
僕はTDDの限界はpublicを前提とするところにあるのじゃないかと漠然と思ってる
まだぼんやりとして言語化できる段階にない

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

ググってみたけどTDDに否定的な考え方は世界的にあるみたいね

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

TDDはともかく、和田メソッドはダメでしょう。

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

まるで○○は危険でしょうと言うだけで
何が危険かわかってない人のような言い方だなｗ

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

>>325
> まだぼんやりとして言語化できる段階にない

当たり前
↓

288 返信：デフォルトの名無しさん[] 投稿日：2020/07/11(土) 12:15:29.92 ID:JFnadz6+ [26/44]
>>286
僕は単体テストやったこと無い
カバレッジの計測もしたことないからわからない
僕は知りません

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

>>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の話をしてるんだから当然なんだが