カプセル化の有害性、オブジェクト指向は愚かな考え

**デフォルトの名無しさん** · 2020/06/18(木) 23:47:36.69

カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、オブジェクトの実際の型を隠蔽したりすることをいう。

かつて偏差値の低い学校向けの情報処理系教科書において「カプセル化は大変すばらしいものであり絶対に使うように」と大体的に宣伝された。

一方、カリフォルニア大学バークレー校の有識者を中心とした「インターネットを作った人たち」は「階層化の有害性」として「カプセル化は絶対にやめろ」としている。

https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0)

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

どうやら翻訳は副業らしいなｗ

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

>>688
意見と感想の違いぐらいつけようよｗ

話は簡単じゃないか
t_wadaさんの意見と
お前の感想

説得力があるかどうかだよ

**575** · 2020/07/04(土) 13:18:30.04

とりあえず、落ち着け。
議題がよくわからんが、落ち着け...落ち着くのだ。

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

>>687
いやいや翻訳だけが全実績じゃん
t_wadaさんがprivateメソッドをテストせずにとても
すばらしいシステムを構築していま全世界で使われてますってことないじゃん

翻訳したからまるで本物の執筆者のように思われてあたかも専門家のように思い込まれてるだけで
専門家でもなんでもなくただの翻訳者だよ

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

いいんだよ、元から不毛なネタのスレだw

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

>>690
君が説得力を感じたら意見になり、
説得力を感じなかったら感想になるってだけじゃんそれ
なにそのガバガバな日本語運用

わかりましたでは今から僕が君を説得してみせます、よく聞いてください
privateメソッドはテストするべきです

**575** · 2020/07/04(土) 13:21:53.40

>>693
それもそうか(諦め)
内容は読んでないけど、まぁ、ROMるか。

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

>>692
なんでググらないでウソ書くの？
そうやって他の人を騙そうとしてるでしょ

https://t-wada.hatenablog.jp/entry/clean-code-that-works
職業はコンサルタントであり、プログラマです。最近では技術顧問としてもいくつかの会社を支援しています。
また、自分の自由になる時間には、オープンソースソフトウェアの開発を行っています。
本業はプログラマでありコンサルタントですが、副業としては技術書の出版、具体的には監訳や翻訳に関わっています。

JavaScript でテストを書く際のハードルを大幅に下げるために開発した power-assert は、
Mocha や Jest と組み合わせて使え、 AVA には既に内蔵されており、ありがたいことに世界中で使われるプロダクトまで育ちました。

ひとつ例を挙げるなら、アリババグループで採用頂き、アリペイやアリババクラウドのテストに使われているという話です。

んで、こういう人に比べて、お前はなにかすごいことしたの？

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

>>696
営業努力の賜物やろな、頑張ってるんやなt_wadaさん

僕がなにかしたのかという質問ですが僕はすごいことを発見しました
privateメソッドはテストした方が良いです

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

ほんまt_wadaさん好きやな

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

>>698
t_wadaさん以外にすごい人がいたら教えて下さいw

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

>>699
他人に憧れをいだいて必要以上に持ち上げるのが僕は気持ち悪く感じます
僕はすごい人ですが、君に憧れられるのは気持ち悪いです、なのでごめんなさい

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

振ってしまってなんかごめんなさい

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

他人を必要以上に持ち上げるのって自分に自信がない人がやりがちなので
アドバイスするとしたら色々経験したがいんじゃないかということですね

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

IT掲示板群 ttp://x0000.net/forum.aspx?id=15

学術の巨大掲示板群 - アルファ・ラボ ttp://x0000.net
数学物理学化学生物学天文学地理地学
IT 電子工学言語学国語方言など

simulationライブラリで純粋な関数式プログラミングをする
ttp://x0000.net/topic.aspx?id=3631-0
UIライブラリ (C#, 2D) を作ったよ
ttp://x0000.net/topic.aspx?id=3688-0
連続と離散を統一した！
ttp://x0000.net/topic.aspx?id=3709-0
4Dエンジン（画像有り）
ttp://x0000.net/topic.aspx?id=3677-0
matrixのライブラリ
ttp://x0000.net/topic.aspx?id=3711-0
ある強力なFor関数
ttp://x0000.net/topic.aspx?id=3630-0
SQLライブラリ
ttp://x0000.net/topic.aspx?id=3675-0

☆ VMを書いた(C#) * x86ではない!
ttp://up.x0000.net/files/TSimulang.zip
☆ malloc / free を実装してみた (C#)
ttp://up.x0000.net/files/TMallocTest.zip

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

根拠が聞けるかなと思ったターンで
他人の引用を持ってきて権威に頼っただけである場合
議論は終了である
続ける価値がないから

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

いえ、自分と同じ意見を言ってる人を持ってきただけなので
話は続いてますよ？

でもなぜか、話の続きをやめてしまっているのです。
なぜでしょうね（笑）

**デフォルトの名無しさん** · 2020/07/04(土) 14:09:00.83

プログラム板でコード使って語りもしない時点で両者どちらも無能
プログラマならコードで主張

**デフォルトの名無しさん** · 2020/07/04(土) 14:17:35.76

>>706
有能さんあざーす！コードどこ？

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

privateメソッドとしてどの程度複雑なことをやらせるか、privateメソッドをどの程度使うかについて、感覚の違う2つのスタイルがあるんじゃないか？

一方の極は、privateメソッドには極めて単純なことしかさせず、少しでも複雑な内容なら（他のヘルパークラス等の）publicメソッドに切り出すスタイル。
「privateはpublic経由でのみテストする（直接はテストしない）」という方針を採る場合には、privateメソッドの内容は非常にシンプルな内容に限らざるを得ないし、逆にそうしないと>>555指摘の組み合わせ爆発の問題を回避できない。
>>624と>>649で紹介されている議論や、>>588はこの立場なんだろう。
このスタイルでは、下記のスタイルでは1つのprivateメソッドで処理できる内容を、複数のクラスに属するメソッドの協調関係で処理することになる。
これを適切な機能分化がされていると肯定的に捉えるか、必ずしも汎用性があるわけではない小さなヘルパークラスが増えることになり、見通しが悪くなると否定的に捉えるかは考え方によるだろう。

もう一方の極は、privateメソッドだからといって、内容をシンプルに限らなければいけない必然性はないというスタイル。>>589は、こちらの立場なんだろう。
このスタイルでは、public経由でprivateのテストをするというのは現実的ではないから、privateメソッドでも直接テストの対象とすることが必要になる。言語機能の関係でprivateを直接テストすることが難しい場合には、テストのやり方に工夫が必要になる。
メリット・デメリットは前記のスタイルの反対。

こんなふうに整理できるんじゃないかと思うが、どうだろう。

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

>>707
主張したいことがあるんでないの？
それを示すコードもあるやろ？

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

>>709
でも僕無能だからコードないよ
君有能だからコードあるよ
早く出すよ

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

>>710
俺は別にプログラムのこのスレタイについて主張したいことないからなあw
君はプログラマでプログラムについて何か主張したいんだろ？

**デフォルトの名無しさん** · 2020/07/04(土) 14:23:09.56

privateメソッドだからテストしないとか言ってるやつはキチガイ
早く死んでね

**デフォルトの名無しさん** · 2020/07/04(土) 14:23:22.38

>>711
関係ないよ、早くコード出すよ

**デフォルトの名無しさん** · 2020/07/04(土) 14:23:44.26

早くコードだすよ！

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

>>714
あーこっちがきちがいだったかw
触れないようにするわ

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

ｗｗｗ

**デフォルトの名無しさん** · 2020/07/04(土) 14:33:12.47

このように、コードを使わず偏った主張するやつはだいたい頭がおかしい
この板ではこうやって簡単にこういう奴をあぶり出しできるんよな

**デフォルトの名無しさん** · 2020/07/04(土) 14:34:10.41

>>717
君、コード出してないよ
コード出すよ

**デフォルトの名無しさん** · 2020/07/04(土) 14:34:57.85

早　く　コ　ー　ド　出　す　よ　！

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

>>719
^^

**デフォルトの名無しさん** · 2020/07/04(土) 14:56:58.97

>>708
> privateメソッドとしてどの程度複雑なことをやらせるか、privateメソッドをどの程度使うかについて、感覚の違う2つのスタイルがあるんじゃないか？

privateとかpublicとか関係なく、複雑なことをやらせるなよ
関数はせいぜい一画面程度（50行）ぐらい、大半は20行以下にするもんだ

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

はいはいどうせt_wadaがそう言ってたんだろ

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

>>722
また「人」の話かよｗ

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

権威ある専門家が言ってることだから間違ってます
俺は認めませーんって。どういう気持で言ってるんだろうねｗ

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

俺は「そいつは権威ある専門家だ！」って指摘しただけで
勝ったつもりにはなれないなぁ（笑）

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

t_wadaはなんて言ってるんだよ！

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

t_wada原理主義

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

必死だなｗ

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

今までたくさんのキチガイPGを見たが
privateメソッドだからテストしないとか言ってるやつだけは許さない
テメーの金玉はここで潰す

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

ごりごりーごりごりー
そうだ！すりつぶした粉で大根餅作ろうよ！

**575** · 2020/07/04(土) 15:11:12.87

>>729
問題なのは、そのprivateの挙動をどうやって確認するのかって話なのかな？

単体テスト？総合テスト？それとも実装中しながらのデバッグ作業の話？

正直、未だにどこで揉めているのかわかりません。
誰か議題教えて。

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

>>731
> 正直、未だにどこで揉めているのかわかりません。

自転車置き場

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

>>731
1. public、privateに限らずコードはシンプルにするべき
2. シンプルであるなら、privateはpublicメソッド経由でテストできる
3. publicメソッド経由でやったらprivateがろくにテストできないというなら設計が間違ってる
4. 設計上の問題はバグと言ってもいい。バグなんだから直せ

ここまではあってる

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

>>731
設計書見ろよゴミカス
書いてないなら死にまくれ

**575** · 2020/07/04(土) 15:21:35.25

>>734
なんで、スレの流れに沿って説明しただけの俺がゴミカス呼ばわりされるのかもわからん。何このスレ。
>>576 >>578でも俺の意見ですらない部分に的外れな回答がつくし。

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

動けばOKって考えてる人がどれだけ多いかだな
テストを自動化するという考えがない
シンプルな設計をするという発想がない
動けば設計に問題はないと考えている

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

>>735
Welcome to Underground

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

>>733
あってるの1だけじゃないかw

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

叩き台つくった（´・ω・｀）
https://ideone.com/1XhPwl

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

なんかやべえ流れになってるな
とりあえずつっこんどくと
1. unitテストの定義に世界共通の定義など存在しない
2. unitテストという単語はプロジェクト用語であり、プログラム用語ではない
3. マーティンはunitテストという単語と自動テストの単語わけたらいいんじゃない？と提案してる。xunit
4. publicとprivateはクラス設計のため、もっと言えばクラス間の責任範囲のために存在している
5. xunitテストのためだけにprivateをpublicにするのは誤り。本当にやりたければリフレクションでもすればいい
6. c2カバレッジ100%するかどうかは分野次第
7. 我々は十分なシステムを作るのが目的である。完璧なプログラムを作ることが目的ではない。そして十分な利益を獲得することが目的でもある

**575** · 2020/07/04(土) 15:57:07.88

ちなみに、的はずれって100%君のことね。まぁ、そんなの今更どうでもいいか。

実際、クラスをどんな風にテストするのか興味あるね。

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

やだよ組み込みが普通だと思ってる人との会話なんかしたくない

**575** · 2020/07/04(土) 16:32:24.22

そんなー。

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

>>735
なんだ早く死ねよ

**575** · 2020/07/04(土) 16:36:24.03

まぁ、Android開発(アセンブラレベルからJavaアプリレベル)をやってるから、たぶん、大丈夫なはず。

組み込み=staticおじさんのレッテルが貼られがちだけど、
私はstaticおじさんじゃないんだけどなー...。
まぁ、アセンブラレベルの階層になると、オブジェクト指向要素なんて微塵もないけど。

**575** · 2020/07/04(土) 16:37:37.70

>>744みたいな知的障害者が時々沸くのはなんで？

**575** · 2020/07/04(土) 16:46:14.68

もういいや。アホくさ。こんなスレ覗いたのが間違いだったな。
人生を無駄にした気分だ。
このスレを覗く時間を使って別して作業してた方が有意義だったよ。

>>744
君はID変えながら死ね死ね連呼しているみたいだけど、気を付けた方がいいよ。あばよ、中身がない死ぬべき技術者さん。

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

プ板、と言うか専門板なんてそれぞれの話題を餌にマウント取り合ったり罵り合ったりする所だから。
相手にしたら負け。

**デフォルトの名無しさん** · 2020/07/04(土) 17:09:48.00

言語の制約によって思考が制約されてる典型例

カマッてくれる人が量産されて>>1が喜んでる

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

privateメソッドのテストしないとか言ってるカスとまともに会話するメリットないだろ

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

まあテストやるって言ってもこれくらい意見が違って揉め事になるってのは
結構普通だったりするからそういう勉強にはなってるんでないの。

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

このスレの結論

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

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

別クラスのパブリックメソッドとする
プライベートなメソッドのテストを書きたいということは、実はテスト対象の責務が多すぎることを
示唆している場合があります。テストがどうしても書きたい場合は、その責務はテスト対象の
プライベートな振る舞いではなく、他の誰かのパブリックな振る舞いなのでしょう。テスト対象の
プライベートメソッドを「クラスの抽出」や「メソッド/関数の移動」を使って、テスト対象の
コラボレータのパブリックメソッドとして抽出し、普通にパブリックメソッドとしてテストしましょう。

テスト対象の可視性を（やや）上げる
例えば Java では、同一のパッケージからのみアクセスできる可視性があり（正式名称ではありませんが
「パッケージプライベート」と呼ばれます）、テストを同一パッケージに配置することでテストから
アクセスできるような設計を行うことがあります。（ただし、この質問の場合は JavaScript なので、この手段はとれません）

プライベートのまま、リフレクションでアクセスしてテストを書く
リフレクションは最後の手段であり、強力な手段でもあります。プロダクトコードに手を入れることが
できない状況や、レガシーコード（テストコードの無いコード）に対する「仕様化テスト（Characterization Test）」を
書いているような状況では、リフレクションは唯一の、かつ強力な手段になります。プライベートメソッドに
テストを書くことのデメリットを理解しつつ、黒魔術の強力さを堪能しましょう。
（ただし、この質問の場合は JavaScript なので、この手段はとれません。JavaScript は比較的緩い言語ですが、クロージャの情報隠蔽は非常に強固です）

まとめ
繰り返すと、プライベートなメソッドや関数をテストする必要は無いと考えています。プライベートなメソッドは、実装の詳細であるからです。

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

>>752
三行以上は読んでもらえないから工夫が必要。

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

ガワだけのクラスが出来上がるな

#include <iostream>
using namespace std;

class Test{
private:
int methodPrivate(const int x)const{
return 2*x;
}
public:
int method(const int x)const{
return methodPrivate(x);
}
};

int main() {
Test test;
cout << test.method(3) << endl;
return 0;
}

この調子で全部のメソッドにペアになるprivateメソッド作って徹底的に隠蔽してしまえば、相手から調査されることはない

そして上流の方から指定されているメソッドはスッカラカン
実質的に何もしない
名前があるだけ

この技法をprivate開発と名付けよう
相手側に技術が流出することがない

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

>>752
×このスレの結論
◯ぼくの主張の結論

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

>>755
間違えた
×ぼくの主張の結論
◯ぼくがまとめた、偉い人が書いた本の受け売り情報

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

本人の経験が感じられなくて薄っぺらいんだよなあ

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

僕の高い知性と豊富な経験に基づく主張を聞いて欲しい
privateメソッドはテストした方がいい

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

>別クラスのパブリックメソッドとする
>プライベートなメソッドのテストを書きたいということは、実はテスト対象の責務が多すぎることを
>示唆している場合があります。テストがどうしても書きたい場合は、その責務はテスト対象の
>プライベートな振る舞いではなく、他の誰かのパブリックな振る舞いなのでしょう。テスト対象の
>プライベートメソッドを「クラスの抽出」や「メソッド/関数の移動」を使って、テスト対象の
>コラボレータのパブリックメソッドとして抽出し、普通にパブリックメソッドとしてテストしましょう。
これだけは意味ある意見ではあるな。他はカスみたいな理由だが。

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

カバレッジ測定ツール高いし持ってないので、private直接テストしたい。

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

>>759
>>プライベートなメソッドのテストを書きたいということは、実はテスト対象の責務が多すぎることを
>>示唆している場合があります
わかる

>>コラボレータのパブリックメソッドとして抽出し、普通にパブリックメソッドとしてテストしましょう。
これは選択肢の一つであって常にそうすべきなわけではないんだよね
クラスの分割基準とテストを書く書かないの基準は別だから

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

プライベートだとテストしにくいので、パブリックメソッドとして抽出し、普通にテストしましょう
これが本音

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

https://i.imgur.com/FG4MVEW.jpg

**デフォルトの名無しさん** · 2020/07/05(日) 00:43:13.75

プライベートがテストできるということはホワイトボックスなわけでユニットテスト段階でしょ。
そもそもプライベートをテストするにはソース自体書き換えないと呼べないじゃん。

ソース自体書き換えてテストするようなことはビジネスの世界ではあんまり無いしテストと
なったらブラックボックスが普通。

てかもはやテストの話でカプセル化やOO関係ないな。

**デフォルトの名無しさん** · 2020/07/05(日) 01:18:10.47

ホワイトやブラックについて語るのは時期が悪いというか、国家を危険にさらす可能性さえあるからね。

もう少し社会情勢に気を配ろうよ。

**デフォルトの名無しさん** · 2020/07/05(日) 01:32:28.51

昔のホームページにはサイタマップというものがあった。

**デフォルトの名無しさん** · 2020/07/05(日) 02:04:25.24

埼玉県民にはそこらへんの草でも食わせておけ

**デフォルトの名無しさん** · 2020/07/05(日) 02:11:14.07

>>764
> ソース自体書き換えてテストするようなことはビジネスの世界ではあんまり無いしテストと

まさかpublic・privateメソッドのテストをテスト工程でやる、
public・privateメソッドを書いた人と別の人がやるって思ってないか？

public・privateメソッドを実装中に、その作ったもののが正しく動くかどうか
public・privateメソッドのソースを書いた人が、書いてる段階でテストするんだから
当然ソースを書いて（書き換えて）テストするに決まってるじゃん

お前は、その後の（統合）テスト工程でソースコードを変えてテストとか言ってるだろｗ

**デフォルトの名無しさん** · 2020/07/05(日) 02:46:27.47

>>768
なんなのその口調気持ち悪い。

大規模開発だとテスト工程を別の人間が何度もやるのは当たり前だよ。
デベロッパ個人のテストはコーディングの範疇なのでもちろん個人ではやるが
それほど大事ではない。

組み込みで車のブレーキ制御とかは全く別の話だろうがOOとかカプセル化とは
基本かけ離れた分野。

**デフォルトの名無しさん** · 2020/07/05(日) 02:48:43.07

テストしない理由を考えるのは。

**デフォルトの名無しさん** · 2020/07/05(日) 02:50:28.66

>>769
> 大規模開発だとテスト工程を別の人間が何度もやるのは当たり前だよ。

大規模開発だとpublicやprivateメソッドのテストを別の人がやるって？
テストコード専用に書く人でもいるのかよｗ
それはどこの話だ？事例の一つぐらい持ってきてから言え

**デフォルトの名無しさん** · 2020/07/05(日) 02:51:54.42

>>771
某アメリカ製のパッケージとかだな。

むしろテストコード専門に書く人いないのかよ。じゃあOOとかカプセル化とか
必要なほどの規模じゃないか体制がおかしいな。

**デフォルトの名無しさん** · 2020/07/05(日) 02:53:01.58

> 某アメリカ製のパッケージとかだな。

だから事例は？

**デフォルトの名無しさん** · 2020/07/05(日) 02:54:30.54

ユニットテストのコードを他の人が書いて、どうやってTDDをやるのか不思議なんだがｗ

先にテストコード書く人がテストコードだけ書いて、
これに通るように実装しろ！
これがTDD（テスト駆動開発）だ！
とか言ってる所とかでもあるんか？

事例を持ってきてくれ

**デフォルトの名無しさん** · 2020/07/05(日) 02:56:40.99

だからユニットテスト自体が少なくともビジネス分野では大事じゃないと
上にも書いてあるが。

事例なんか出せるわけないだろ。中の人なんだから。

**デフォルトの名無しさん** · 2020/07/05(日) 02:58:40.47

製品についてネットに書き込むときは、法務と企画のハンコ必要なので。

**デフォルトの名無しさん** · 2020/07/05(日) 02:59:12.87

ちなみに法務俺、規格俺だけど。

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

今関わってる製品とかソース10万ファイルくらいあってそれぞれのファイルに
分岐なんか少なくとも数十から数百はあると思うが、その数百万から数千万、下手したら
億の分岐を全部全パターンテストするの？

テストなんてそのあとファンクショナルやってリグレッションやってアクセプタンスやって
ってあるのに、ユニットテスト「だけ」でそれでしょ？

サグラダ・ファミリアかな？

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

>>775
中の人だから事例が事例を出せないってことは、
お前の会社以外でやってないってことだろｗ

**デフォルトの名無しさん** · 2020/07/05(日) 03:04:01.72

正しいとか正しくないとかどうでも良いので、privateのテストをさせてほしいものですね。

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

>>778
> 今関わってる製品とかソース10万ファイルくらいあってそれぞれのファイルに
> 分岐なんか少なくとも数十から数百はあると思うが、その数百万から数千万、下手したら
> 億の分岐を全部全パターンテストするの？

それユニットテスト関係ないよね？

手動で全パターンをテストするの？
答えはお前自身が言えるはずだよね？

**デフォルトの名無しさん** · 2020/07/05(日) 03:06:25.42

ユニットテストなんかしてねーよ
ソース修正するたびに、
億の分岐全パターン手動テストしてるんだよ！

って言ってほしいな？
まだかな？

**デフォルトの名無しさん** · 2020/07/05(日) 03:13:56.54

けんか腰は知能が高いと言われるム板に似合わないんだよな。
ユーモアを交えて会話するべきだと思います。

**デフォルトの名無しさん** · 2020/07/05(日) 04:06:24.23

>>779
知ってる限りGAFAでもERP各社あたりでもやってないけどね。

試しに（ドイツだが）SAPあたりにカバレージどれだけですかって聞いてみれば？
何それ美味しいの？だよ。

まあこういう人は何言っても無駄だし下手に事実いうと発狂するからもう相手は
おしまい。

**デフォルトの名無しさん** · 2020/07/05(日) 04:11:13.84

ではGoogleの事例

https://feb-acchan.hat
enablog.com/entry/2018/03/11/214344

現状について
Googleでは、420万ほどのテストが存在して、1日1億5千万テストケース
実行されていて(150million test execution/dayだからあってますよね？)、
1テストケースあたり35回実行されているらしいです。

そして、これらがすべて自動テストであり、手動テスト率が驚異の0％！
ただし、UX系のテストは手動だそうです。
UIのテストなどは自動化できるが、UXはさすがにまだ人手とのことで、
人の感覚などが関係するUXテストがAIによってテスト可能で人の仕事が無くなるといった日はまだ到来していません。

自動テストですが、毎テストごとに420万テストケースを実行しているわけではなく、
全テストケースを実行するのは一定の間隔で、普段は修正に対して依存があるテストだけを実行しているそうです。

**デフォルトの名無しさん** · 2020/07/05(日) 04:13:30.65

Googleの考え方

https://www.publickey1.jp/blog/11/post_144.html

テスターはデベロッパーがテストできるようにするのが仕事
このようにEngineering Productivityのメンバーのレポートラインと
所属を分けることのメリットを、Whittaker氏は次のように書いています。
ここにグーグルの品質管理の大事なポイントがあるようです。

一般にテストは製品開発の最後の段階で行われることが多く、製品チーム／開発チームの
中にテストチームを抱えても、テストフェーズ以外は手持ちぶさたになってしまうため、
多くの開発組織ではテストチームは製品チーム／開発チームとは別に存在し、
必要なときに登場してテストを行う、というケースがほとんどです。

====以下重要＝＝＝＝

ところがグーグルではEngineering Productivityに属する、テストのノウハウを持ち支援を
行うエンジニアたちは、前述のように各製品チームに所属しています。

そう、グーグルではテストチームではなく、製品チームが自身で品質管理を負っている。
各デベロッパは自身でテストすることを期待されている。テスターの仕事は、自動テストの
インフラを確立することと、それによってデベロッパ自身がそれをプロセスの中で実行できるようにすること。
テスターはデベロッパーがテストできるようにするのだ。

各製品チームは、Engineering Productivityのメンバーの支援を受けつつ、自分たちの責任で
テストを行わなければならない、ということがグーグルのテストを行う際のポリシーのようです。

**デフォルトの名無しさん** · 2020/07/05(日) 04:14:26.63

https://www.publickey1.jp/blog/11/post_144.html

Whittaker氏はさらに次の記事「How Google Tests Software - Part Two」で、
エンジニアに与えられる3つの役割についても触れています。

Softweare Engineer in Test（SET）
テストのしやすさ（Testability）にフォーカスした役割。デザインレビューをし、
品質やリスクをチェック。コードをテストしやすいようにリファクタリングする。
ユニットテストや、テストフレームワーク、自動テストも書く。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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

「コードをテストしやすいようにリファクタリングする。」

っていうのがまさにprivateでテストしたいのに
public経由でテストできない

ならばテストしやすいようにリファクタリングしましょうって話になってる