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

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

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

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

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

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

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

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

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

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

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

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

**デフォルトの名無しさん** · 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の話をしてるんだから当然なんだが

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

How to unit test private methods in BDD / TDD?
https://stackoverflow.com/questions/1583363/how-to-unit-test-private-methods-in-bdd-tdd

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

Don’t Test Private Methods
https://dzone.com/articles/dont-test-private-methods

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

>>329
僕は頭を使うことによって君の経験はすでに超越してるよ
君はただツールを使ったことがあるってだけのただのアホ

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

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

君の感想はこれだけ
あとは引用コピペを繰り返してるだけ
君の経験は浅すぎて僕の参考にならない

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

スネ夫の限界
僕は出来杉君

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

>>334
でもお前の発言はなにもないじゃんｗ
壊れたレコードのように和田はだめ（理由なし）和田はだめ（理由なし）を
繰り返してるだけ。今度はTDDはだめっていうんですかね？ｗ

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

>>336
僕は、和田はダメと一度も言ってない
僕のレスを全部読み直してみて
君は頭が働かないどころか勘が鈍い

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

もう人のフンドシで相撲をとるのはやめろ

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

>>337
まるで和田メソッド（TDDの常識的な手法）に
限界があるような言い方してるじゃんｗ

自分が何も知らないのに、限界があるんじゃないかという
疑いをかけるのはだめ。

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

世の中に銀の弾丸は無いからね
何事にも限界はあるでしょ、一般論だよ
IQ低い人はすぐ被害妄想いだくから面倒

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

もっと知性あふれる人と知的な会話をしたいなー

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

>>340
一般論だからこそ、TDDの批判にはならないんだよ。

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

つまり

「お前の意見に言いたいことがある。一般論として人はだれでも間違える（ドヤァ）」

といっても意見にたいして、何かを言ってることにはならないのと同じね。

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

ちなみに僕は常識に価値があるとも思ってない
京都大学では真実は少数派に宿るっていう言葉が使われてるよ

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

>>342
疑いをかけられたんだーﾑｷｰって反応してる君がおかしいってこと

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

>>344
じゃあ京都大学ではその言葉は多数派だから真実にはならないね（笑）

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

>>345
だから「TDDには」疑いをかけられてないと言ってる。
お前は一般論を言っただけ

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

>>347
そうだよ、僕は一般論をいっただけ
一つ指摘しておくと君は日本語を使ってる

わかるかな、僕のこの高度な皮肉が

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

>>348
皮肉かどうかはどうでもいいな
少なくともお前はバカだということ
議論してるふりをしてるだけ

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

> >>337
> まるで和田メソッド（TDDの常識的な手法）に
> 限界があるような言い方してるじゃんｗ
>
> 自分が何も知らないのに、限界があるんじゃないかという
> 疑いをかけるのはだめ。

疑いをかけられてないと思ってる人間が疑いをかけるのはだめとは言わんでしょう

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

>>350
日本語が理解できてないねｗ

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

君は疑いをかけられてると思っていた
僕は一般論だよと言った
君は疑いをかけられてないと言い出した
僕はそんなの当たり前だろということを示すために君は日本語を使ってると
当たり前のことを言って皮肉った

という流れだったんだ

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

もうお互い大変でしょう、僕と仲直りしましょうか？
君にアホと言ったのは謝るよ、君が僕にバカと言ったのは忘れるよ
僕は心の広い知的なイケメンです

**デフォルトの名無しさん** · 2020/07/12(日) 08:15:23.41

和田メソッドの真骨頂は、バグを作り込まなければテストする必要が無いことにある。

テストは甘え、甘えがある限りバグは無くならない。

つまり、テストしない仕組みづくりこそが和田メソッドである。

**デフォルトの名無しさん** · 2020/07/12(日) 09:15:09.92

クソみたいな議論ばっかに見えるがプログラム技術板の中ではわりかしまともな方になってるぞ。

**デフォルトの名無しさん** · 2020/07/12(日) 09:33:56.05

>>355
参考までにまともだと思うレス番教えてくれ

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

>>354
デマ禁止な

**デフォルトの名無しさん** · 2020/07/12(日) 15:39:00.55

和田メソッド被害者の会結成しなくては。

**デフォルトの名無しさん** · 2020/07/12(日) 16:03:31.03

本当の被害者は自分が被害を受けたと自覚していない

**デフォルトの名無しさん** · 2020/07/12(日) 16:04:35.47

それは恐ろしい話だけど、このスレにもちらほらいるね。

**デフォルトの名無しさん** · 2020/07/12(日) 16:04:37.33

そういう人に、どういう被害を受けたかを説明できればね（笑）
結局、被害の内容を言えないんだから、被害はなかったということ

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

オウム真理教の信者は被害者でもあり加害者でもある。

**デフォルトの名無しさん** · 2020/07/12(日) 16:47:10.65

上の方でも書いたけど「例え」は何かを批判するときに使ってはだめ
「それは別の話で関係ない」という簡単な一言が完璧な反論になってしまうから

**デフォルトの名無しさん** · 2020/07/12(日) 17:15:44.85

和田メソッドの信者は被害者でもあり加害者でもある。

**デフォルトの名無しさん** · 2020/07/12(日) 18:31:40.10

しかしその理由は何一つ言えない。中身が無いからだ。

**デフォルトの名無しさん** · 2020/07/12(日) 18:43:30.23

眉唾理論。

**デフォルトの名無しさん** · 2020/07/12(日) 18:53:56.08

>>366
なるほど、つまりTDDはテストが開発を駆動するという考え方で
テストによって実装や設計が導かれるということなのだけれども
設計過剰だったり設計不足だったりする
設計は本来ドメインに関する知識から導かれるものなので
入力、出力を決めたら自動的に最適な設計が見つかりますなんて
そんな都合の良いことが起こるわけもなくTDDは現代では否定されていて
単体テストよりもシステムテストを重視したほうが製品の品質はあがるわけですな

**デフォルトの名無しさん** · 2020/07/12(日) 18:54:49.46

説明に対して全く聞く耳を持たず、和田経典に書いてあると繰り返すだけだから、宗教的なナニカ扱いされてる。

**デフォルトの名無しさん** · 2020/07/12(日) 19:04:08.64

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

騙されたやつ多いのでは。

**デフォルトの名無しさん** · 2020/07/12(日) 19:10:42.57

>>367
> TDDは現代では否定されていて

どこで否定されてるの？さらっとウソを付かないように。
どうせすぐに俺がバラすんだから意味ないよ（笑）

**デフォルトの名無しさん** · 2020/07/12(日) 19:20:59.87

どこで否定されてるのとか、これまでのみんなの説明が全くの無駄。

和田さんには和田さんの経典があり、みんなの意見には耳を貸さない。

だから宗教と言われてる。

**デフォルトの名無しさん** · 2020/07/12(日) 19:22:03.23

前スレですばらしい分析を見たなあ

897+1 ：デフォルトの名無しさん [↓] ：2020/07/05(日) 11:28:59.86 ID:YdQ981ul
>>870
新しい理論や手法を提唱する人には良くあることだと思うけど、その理論はある前提、ある側面では正しいけど、常に無条件に適用することは正しくないと本人は分かっていて、敢えてそういうことはわざわざ詳しくは説明しない。自分の論が有用な物だと主張したいがため、嘘はつかない範囲で相手が勝手に誤解してすごいと思わせるような物言いをする。
で、その理論に感銘を受けた人の一部が、理論の表面的な効能だけをありがたく受け取って問題点や前提条件などは正しく理解しないまま、受け売りの知識を他所で披露する。
そこで議論になると、本質をちゃんと理解してないまま自説を擁護しようとするから、無理が生じたり話が噛み合わなかったりする。
という流れでイマココなのかなと思う。

◆QZaw55cn4c · 2020/07/12(日) 19:58:09.07

>>372
昔の言い方でいうところの「東大話法」というやつですね…

**デフォルトの名無しさん** · 2020/07/13(月) 00:50:54.57

>>372
素晴らしい分析？それはTDDに関しての分析じゃないよ
その文章はTDDに関して何一つ言及していない。

**デフォルトの名無しさん** · 2020/07/13(月) 00:54:17.24

>>371
ここに和田さんはいないんだから、意見を聞かないはずだという逃げの言葉で
お前の意見を言わないのはおかしい。

他人が意見を聞くかは関係なく、
お前の意見を言えばいい。

言えないなら、反論するすべがないというのがお前に対する結論だ。

**デフォルトの名無しさん** · 2020/07/13(月) 01:12:00.86

>>1 がアスペのスレ

**デフォルトの名無しさん** · 2020/07/13(月) 01:12:57.80

和田メソッドの弊害

**デフォルトの名無しさん** · 2020/07/13(月) 01:36:28.61

と繰り返えすだけ

**デフォルトの名無しさん** · 2020/07/13(月) 06:26:53.87

>>375
イイエ居ます。
みんな説明してます。
見えないことにするなら、みんなの書き込みが無駄です。

和田メソッドはカルト宗教の様相を呈してきた。

**デフォルトの名無しさん** · 2020/07/13(月) 07:01:21.00

和田メソッドのせいで日本のITが10年遅れた。

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

和田メソッドって単なるTDDだぞ？

**デフォルトの名無しさん** · 2020/07/13(月) 08:39:56.06

イイエ違います。
和田メソッドは宗教です。

**デフォルトの名無しさん** · 2020/07/13(月) 08:41:17.44

和田さんはこのスレに居ないと書き込んでるのが御本人かもしれない。

**デフォルトの名無しさん** · 2020/07/14(火) 13:34:51.74

ステマスレ。

**デフォルトの名無しさん** · 2020/07/16(木) 12:32:21.61

失速したな
TDDはプロトタイピングと組み合わせると良いかもね
テスト書かずに概ね正確に動作するコードを書いた後に
ブラッシュアップする目的でTDDを使って書き直す感じ

**デフォルトの名無しさん** · 2020/07/16(木) 12:34:19.44

TDDを布教する人が何回も同じコード書いてうまくなっていくように
書き捨てたコードの数だけTDDは洗練されるんじゃなかろうかと

**デフォルトの名無しさん** · 2020/07/16(木) 13:59:03.56

和田メソッドのせいで失われた日本ITの20年。

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

和田さんじゃなくてTDDの話をしよう
詳しい人いないの？

**デフォルトの名無しさん** · 2020/07/16(木) 15:51:48.48

テスト書くタイミングについてなら少しだけ。
わりとだら～と書いて関数なりクラスなり切り出したタイミングで書く感じ。
テストから書くってのは普通の人には難易度高い気がするわ。

**デフォルトの名無しさん** · 2020/07/17(金) 02:41:00.28

最終的なプログラムの詳細設計がパッと頭に浮かぶ人ならテストから書けるんだろうけど
プロトタイプぐちゃぐちゃ作って、やっと構造が決まって、とりあえず動くもの作った後でリファクタリング、な俺には無理だなぁ

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

>>390
そういうやり方にこそTDD的なアプローチが有効だと思うが

**デフォルトの名無しさん** · 2020/07/17(金) 20:03:07.08

>>390
構造が決まった時に設計が始まるんじゃないのか?