クソコードとは何か

**デフォルトの名無しさん** · 2021/01/30(土) 17:33:05.78

このスレはクソコードとは何かを考えるスレです。

・親クラスが子クラスに依存する処理を持つコード
例...社員クラスを継承した正社員クラスと派遣社員クラスがあり、社員クラスが正社員クラスの知識を持つ状況

・staticにするべきではないモデルにまでstaticにする人
例...社員クラスのメソッドを全てstaticにしたり、社員クラスにシングルトンパターンに相応するものを適用する人

等、クソコードを見た時に「あっ、これクソコードだ」って認識する根拠を挙げていきましょう。

**デフォルトの名無しさん** · 2021/02/18(木) 19:30:22.47

>>395
それで？
仕様書通りであると説明できたん？

**デフォルトの名無しさん** · 2021/02/18(木) 20:13:35.08

>>421
何度も言ってるが
仕様書通りのテストコード（or テスト手順書）になってるかはレビューで確認する
その点ではテストコードも手動テストの手順書も差はない

差があるのは
テストコードの通りにコンピュータが実行したか（実行したと保証される）
テスト手順書のとおりに人間が実行したか（実行したと保証されない）
この点で、手動テストは劣っている

>>421
なにか言い返す言葉があるならどうぞ

**デフォルトの名無しさん** · 2021/02/18(木) 20:54:43.88

>>420
インスタンス化しとるやーん

USBに共通する処理をコンポジションで切り出してれば1箇所の修正で済むよね

シングルトンにするメリットがある前提ならそのコードの形だけでクソコードだとは思わないな

**デフォルトの名無しさん** · 2021/02/18(木) 21:58:25.07

>>422
え？コードレビューの他にテストコードのレビューやるの？
何がよかったんだっけ？

**320** · 2021/02/18(木) 22:15:10.24

反応してくれるやつがおっただけでも嬉しいわ（ヽ´ω｀）

**デフォルトの名無しさん** · 2021/02/18(木) 22:24:23.85

>>412
ワイはそれをあると言っている
インスタンス化された個数こそがそのクラスの価値だと言っている
抽象クラスやインタフェースについてはこの主張では扱わない
アホらしいと思うのなら聞き流してくれていい

**デフォルトの名無しさん** · 2021/02/18(木) 22:27:00.40

>>404
単体テストがどうのこうのってもう心底どうでもいいよなｗ
俺もそれの結論について興味が持てない

**デフォルトの名無しさん** · 2021/02/18(木) 22:30:19.90

>>420
インスタンス化を封じて苦しくなってくるのあるよなｗ
最初のうちはそれでよさそうに思えるんだけどね

**デフォルトの名無しさん** · 2021/02/18(木) 22:55:26.26

>>426
インスタンス化された個数と
インスタンス化される箇所の個数は全然違うと思うんだが？

コード上では1箇所でしかインスタンス化されないがリクエスト毎にインスタンス生成されるクラスとか

**デフォルトの名無しさん** · 2021/02/18(木) 23:10:12.48

ごめんね下のほうの意味が本来言いたかったこと
実行時のことは考えず単にコード上での評価

**デフォルトの名無しさん** · 2021/02/18(木) 23:35:55.78

>>430
そうすると何か特殊な前提を置いてるかインスタンス化する箇所という言葉の定義が全く違うかだな

インスタンス化がnewしたりファクトリメソッドを呼ぶ事だとしたら
Webでもモバイルでもデスクトップでもコード上の1箇所でしかインスタンス化されないクラスが結構な割合で存在するほうが普通

わかりやすいところで言えばコントローラクラスやアプリケーションクラス

**デフォルトの名無しさん** · 2021/02/19(金) 02:02:43.04

>>420
USB io = USB.create(port1)で物理的なUSBが重複する可能性があり、排他制御が必要ならそうすると思うよ。
USB io = new USB(port1)で個別にインスタンス作って、マルチスレッド・マルチプロセスで動くなら必要ないけど
自然的なコンストラクタでメンバー変数は初期化されることに意味があるだけで、それ以外の構築初期化を
しようとしたらファクトリーメソッドが必要になる。もちろんnewの後にメンバーメソッドを毎回自分で
呼び出して初期化しても良いわけだけど、ま、言いたいことは確かに安易な設計でシングルインスタンスは
避けるべきだけど、近代的なクラス型の言語によるメンバーの隠蔽とファクトリーメソッドは無関係

**デフォルトの名無しさん** · 2021/02/19(金) 02:35:10.05

>>424
> え？コードレビューの他にテストコードのレビューやるの？

当たり前だろ
お前コードレビューをするのは当然として、
お前、テスト手順書のレビューしないのか？
だからお前がやったテストはいつも抜けがあるんだろうがｗ
すいません、テストが漏れてましたじゃねーよ、いっつもいっつも

**デフォルトの名無しさん** · 2021/02/19(金) 02:43:27.34

>>433
じゃあテストコードのテストもいるよね？

**デフォルトの名無しさん** · 2021/02/19(金) 02:59:07.17

>>434
お前の真似をすると
テスト手順書のテストもいるよね？

当然、答えは「はい」になるよねｗ

**デフォルトの名無しさん** · 2021/02/19(金) 06:52:05.98

>>434
いらない、レビューで足りる
理由は>>255に書いてある

**デフォルトの名無しさん** · 2021/02/19(金) 07:43:49.70

>>435
え？設計書のテストが？
テストコードってもんにしたから特有の手順が増えちゃってるんだろ

**デフォルトの名無しさん** · 2021/02/19(金) 07:48:43.11

設計書
→コード→テスト
→テスト手順書→レビュー
で済むはずが
設計書
→コード→テスト
→テストコード
→レビュー
→テスト
になってるんだろ
テストコードがソースコードである以上テストしないわけにはいかんだろ

**420** · 2021/02/19(金) 07:59:08.25

>>423
伝わりにくくてすまん
紛らわしい言い方だったか

>>428
分かってくれてありがとう

**デフォルトの名無しさん** · 2021/02/19(金) 08:24:00.57

クソ言語とは
PHP、Swift、Python
JavaScriptも昔はかなりクソだったが完全に復活した
Obj-CはSwiftに取って代わられることは無かった、コード効率が良すぎる

**デフォルトの名無しさん** · 2021/02/19(金) 08:51:26.62

>>438
レビューのあとの「テスト」ってビルドボタンを押す度に走るテストのこと？
それとと、gitとかにcommitする度に走るテストのこと？

作業をカテゴリ分けすると増えているように見えるだけで、作業量は減っているように見えるが

途中からこのスレ来たから、流れがわかっていない

**デフォルトの名無しさん** · 2021/02/19(金) 08:52:42.54

>>441
おｋ
半年Romれ

**デフォルトの名無しさん** · 2021/02/19(金) 08:54:08.49

>>438

あと、よく見ると手順が間違ってる
> 設計書
→コード
→テストコード
→レビュー（？）
→テスト（自動化）
if 自動化のテストにすべて合格したら
→結合テスト以降のテスト
だよ

**デフォルトの名無しさん** · 2021/02/19(金) 09:01:26.16

>>442
あっ（察し）
失礼しました（退場）

**デフォルトの名無しさん** · 2021/02/19(金) 10:36:32.08

>>438
> 設計書
> →コード→テスト
> →テスト手順書→レビュー
もうこの時点で意味不明w
普通は
1) 設計書 ⇒ コード（⇒ レビュー）
2) 設計書 ⇒ テスト手順書 ⇒ レビュー
3) 手動テスト（工数大）
だろ
で、自動テストなら
1) 設計書 ⇒ コード
2) 設計書 ⇒ テストコード ⇒ レビュー
3) 自動テスト（工数ほぼ "0"）
要するにテストコードは計算機に対するテスト手順書だから手間は変わらんよ
むしろプログラマーだと仕様書よりコード書く方が楽と思う奴もいっぱいいるしw
あとどっちもテストと書いてるけど手動テストと自動テストでは工数が全く違うから同じ「テスト」という言葉でごまかすなよ
なおテストコードはデバッグが必要と主張するなら>>255にちゃんと反論しろ

**デフォルトの名無しさん** · 2021/02/19(金) 10:53:49.57

テストコードは暇なら書くレベルの価値しかない。
テスト仕様書に漏れがない事が最も重要。
実データで実動作で検証するのが納品条件。

**デフォルトの名無しさん** · 2021/02/19(金) 11:02:12.72

実機繋がってないと無意味なテストにしかならんの多いのよな

**デフォルトの名無しさん** · 2021/02/19(金) 11:29:00.52

>>438
> テストコードがソースコードである以上テストしないわけにはいかんだろ
だからいらない
馬鹿なのかな？
テストコードのテストなんてお前したことないだろ？
世の中の誰もしたことないわｗ
そんなものありはしないんだから

> 設計書
> →コード→テスト
> →テスト手順書→レビュー
> で済むはずが

だめでしょ？レビューが正しいかをテストしなきゃｗｗｗ

**デフォルトの名無しさん** · 2021/02/19(金) 11:45:25.31

>>448
まて、そのレビューは本当に大丈夫なのか？
レビューが適切かどうかも検証しよう（名案）

**デフォルトの名無しさん** · 2021/02/19(金) 11:47:16.24

間違えた
レビューが正しいかのテストが適切かどうかもテストしよう
だった

**デフォルトの名無しさん** · 2021/02/19(金) 11:50:29.27

レビューした結果もちゃんと記録しないといけないからな
レビューの結果をドキュメントとして残すなら
そのドキュメントのレビューも必要になる
当然の帰結だ

**デフォルトの名無しさん** · 2021/02/19(金) 11:52:44.73

単体テストの範囲でこんな凝った仕組みいらんよ
一番やりたい結合は今度セッティングのが時間かかるんで

**デフォルトの名無しさん** · 2021/02/19(金) 12:21:07.58

「結合テストはすごく時間がかかる」

え？なんで？

「単体テストでやるべきことも
全部結合テストで手動でテストやってるからさ！」

↑馬鹿じゃね？

**デフォルトの名無しさん** · 2021/02/19(金) 12:30:35.44

敢えて皆と同じくらいテストコードの書き方を知ってる自分が弁護するけど

class クソクラス
　頻繁に仕様が変わるメソッド
　　クソコード
　不具合が生じると仕様が変わるメソッド
　　クソコード
　思考停止でプライベート変数のgetter
　　思考停止の変数リターン
　思考停止でプライベート変数のsetter
　　思考停止の変数代入

みたいなクラスを単体テストするところを考えてみよう

他の皆の無駄じゃない主張は疑いもなく事実だろうけど、テストコードは無駄という主張はある意味では事実なのだと思う

これは...扱うコードの質の違いが生んだ悲劇
そう、事故だったんだ

テストコード厨呼ばわりについては...うん（諦め）

**デフォルトの名無しさん** · 2021/02/19(金) 12:34:28.76

>>454
テストコードが無駄なケースでは
手動テストも無駄になる

頻繁に仕様が変わるメソッドがあったとして
手動テストをしたら時間の節約になるとでも？
ああ、テストしないってことね（笑）

プロの仕事じゃねーよ

**デフォルトの名無しさん** · 2021/02/19(金) 12:43:07.19

>>455
> ああ、テストしないってことね（笑）
たぶん、彼の言う手動テストは俺らの言う「テストしない」のレベルだと思う
ややこしいのは主張している本人は「テストしたつもり」になっている点

**デフォルトの名無しさん** · 2021/02/19(金) 12:54:53.31

>>455
TDD前提で語ってた
クソコードのテストコードを書こうとしたら、直ぐに設計は是正されないとだぞ

**デフォルトの名無しさん** · 2021/02/19(金) 13:02:30.29

まず、クラス設計する際にテストコードみたいなコードを書いたりしない？
クラス利用者から見たクラスの使い勝手を確かめる意味で

で、何度も試行錯誤して、素晴らしいクラスモデルができたらテストコードを書いて、その後、実装をして...
この作業プロセスができていないから単体テストは無駄だという主張が生まれたと思っていた

**デフォルトの名無しさん** · 2021/02/19(金) 13:19:31.43

>>458
abstractクラス<T>から頭の中で書いてるよ、それで十分
テストコードが必要なケースは、mockableAPIから全ケース流す時くらい、実データだとめんどくさいから

**デフォルトの名無しさん** · 2021/02/19(金) 14:03:37.42

>>456
そうなんだよな。テストしたつもりになってるんだろうなって思うよ

「手動テストでテストできる！
リリース前に、人を大量に集めて人海戦術でテストするんだ！」

なんて言われたら、バグ出たらどうするの？って聞きたくなる

「バグを直して（そこだけ）テストするだけじゃないか！」っていうだろうな
たぶん、そこだけしかテストして無くて全体の再テストをしないだろう
最後にもう一回テストすればいい？　いやいやバグはなくならないんだから
最後なんてありえないだろ

時間がないときは小さいバグは運用でカバーとかいってリリースするんだろ？
そしてあとから修正するんだろ？再テストするだろ？
何回小さいバグを修正する？そのたびに人を大量に集めて人海戦術でテストする？
どんだけ時間とコストがかかるんだよ？

たぶんその答えは
「小さいバグの修正なんだから、たぶん他に影響してないはずだ。動いていればヨシっ」
なんだろ？

プロの仕事じゃねーよ

自動テストしてるプロジェクトでは、一日数回のリリースと全テストを行うことだってある
このスピードに手動テストでは追いつけない

**デフォルトの名無しさん** · 2021/02/19(金) 14:39:19.79

自動テストじゃほとんど何もできない。
日本語/フォント間違えてるとか色違うとかカクカク動くとか。

**デフォルトの名無しさん** · 2021/02/19(金) 14:45:40.28

しばらくぶりに見たプロジェクトの自動テストが通らないことぐらい
開発現場じゃ常識なんだよ!（パプリカ：DCmini）

**デフォルトの名無しさん** · 2021/02/19(金) 14:48:09.77

>>461
> 日本語/フォント間違えてるとか色違う

それはクリティカルなバグじゃないですねｗ
正しくデータが処理されることをテストしたことありますか？
どうやってやりましたか？

**デフォルトの名無しさん** · 2021/02/19(金) 14:49:14.42

>>462
> しばらくぶりに見たプロジェクトの自動テストが通らないことぐらい
それを手動テストして動いたら面白いなｗ

まあよくあるよね。本当はバグってるのに
表面上は動いてるように見えちゃう
だから手動テストは駄目なんだよ

**デフォルトの名無しさん** · 2021/02/19(金) 14:55:40.06

>>463
直接変数に値入れればいいじゃん
コード変わったらまたやる
毎回テスト回すとか無駄

**デフォルトの名無しさん** · 2021/02/19(金) 15:01:38.27

直接変数に値入れるとは？
まさかデバッガ経由でやってんの？
デバッガを使うと挙動が変わるからテストにならない

**デフォルトの名無しさん** · 2021/02/19(金) 15:01:59.28

テストは本番用ビルドでやるのが鉄則

**デフォルトの名無しさん** · 2021/02/19(金) 15:03:42.70

>>466
mockかデバッガーで十分です

**デフォルトの名無しさん** · 2021/02/19(金) 15:06:22.55

客を自動テストして欲しいわ、言うことコロコロ変わるからw

**デフォルトの名無しさん** · 2021/02/19(金) 15:20:06.23

判定させたら99.99%がクソレスだった件

**デフォルトの名無しさん** · 2021/02/19(金) 16:24:05.46

>>468
mockやデバッガーでどうやって
何千ものテスト項目を実行するの？ｗ

**デフォルトの名無しさん** · 2021/02/19(金) 17:47:03.42

要件を確定させずレスバってプログラマどころじゃないな
しかも平日の昼間から真っ赤ってまともじゃないの自己紹介しているようなもの

**デフォルトの名無しさん** · 2021/02/19(金) 17:47:13.51

自分はアプリ開発と組み込み開発の経験があるけど、Web開発って単体テストやらんの？

Webは、Python+Django、node、古いPHPの入門書を読んだ程度にしか触れないからリアル開発事情に興味がある（開発経験が無い）

**デフォルトの名無しさん** · 2021/02/19(金) 18:57:54.50

web開発ってユーザーが入力欄に何を入れてくるかの組み合わせが
膨大になるから、テストも困難になるな。

**デフォルトの名無しさん** · 2021/02/19(金) 18:58:00.55

単体テストをやらないのはSIerだよ

ああ、いや、エクセルに単体テスト報告書を書くとか
そういう意味でなら単体テストをやってるよｗ
テストコードを書かない手動テストのことをSIerは単体テストって言ってる

**デフォルトの名無しさん** · 2021/02/19(金) 19:01:29.71

ああ、わかりやすいのが見つかった。これがSIerのいう単体テスト（手動テスト）

【Web系最高って言うけと゛本当なの？】siの５次請けから離脱したエンシ゛ニアか゛話してみた

https://www.slideshare.net/yuukinakajima794/websi-67526868#8
8. てすとほうほう winshot、エクセル、人間スクショ一枚取り忘れただけでも
テストがやり直しになるプレッシャーと進捗表.xls との戦いテスト結果.xlsが
不要なのでめんどくささがない開発者が目で見ておｋ

https://www.slideshare.net/yuukinakajima794/websi-67526868#12

12. ソース修正とかテストバグが出た！→単体テスト障害報告書.xlsを書く→
必要に応じて単体テストケース.xlsを直す→上司にお話して単体テスト障害報告
書を確認して貰う→テストをするバグが出た！→直す→必要に応じてテストパターンを
増やす→テストするあまりに、あまりにめんどくさい、進捗表.xlsには障害数も書くのでバグゼロは困るらしい

**デフォルトの名無しさん** · 2021/02/19(金) 19:04:03.28

田中勇←口だけテストコード大好き変態老人
技術力はゼロwww

**デフォルトの名無しさん** · 2021/02/19(金) 19:19:27.73

>>476
まあそういうテストが必要なフェイズは確かにあるが、その前に自動テスト入れるべきではある。

**デフォルトの名無しさん** · 2021/02/19(金) 19:33:50.76

>>478
どちらにしろ手動テストするなら
全部、手動テストでやっても同じ
テスト時間も変わらない

と思ってるらしいよｗ

**デフォルトの名無しさん** · 2021/02/19(金) 20:27:04.98

>>476
URLの闇が深すぎて怖い

**デフォルトの名無しさん** · 2021/02/19(金) 20:45:17.65

>>473
Ruby on Rails では、minitest/RSpec という2種類のテストフレームワークがある。
単体/システムテストの2つある

Rails 6 からは、環境を丸ごとコピーして、並列テストもできる

TDD では、テストが仕様書。
Excel で管理したりしない

**デフォルトの名無しさん** · 2021/02/19(金) 21:59:46.75

>>454
それ扱うコードの質の違いが問題じゃないだろ
テストコードの変更が必要になるのは「頻繁に仕様が変わる」のが原因で当然手動テストでもテスト手順書の変更が必要になるだろ
根本がわかってなさ過ぎ

**デフォルトの名無しさん** · 2021/02/19(金) 22:05:12.15

>>481
おお、なんかスピード感あって楽しそうだな
TDDいいよね！本業の組み込み自社開発でも導入した
何で長年気が付かなかったのか不思議なレベル

この手のノウハウは組み込みより圧倒的にWebの方が進んでるから、俺にとっては上位レイヤーの開発ノウハウが新鮮に感じる

**デフォルトの名無しさん** · 2021/02/19(金) 22:07:51.51

やっぱり単体テストでそこまで用意する意味ねぇって
時間がかかってるのデバイス周り出し及びじゃねぇよコレ

**デフォルトの名無しさん** · 2021/02/19(金) 22:08:44.56

結合入ってから頑張ろうよ

**481** · 2021/02/19(金) 22:31:54.64

伊藤淳一などが翻訳してる「Everyday Rails - RSpecによるRailsテスト入門」は有名な本

テストに関しては、ソニックガーデンの伊藤淳一の動画・Qiita などを読めばよい

**デフォルトの名無しさん** · 2021/02/20(土) 00:24:53.76

>>484
デバイスはモックを使いましょう
ソフトウェアのテストをするのに
本物のデバイスは必要ありません

**デフォルトの名無しさん** · 2021/02/20(土) 01:40:17.33

>>487
いや、それだとレスポンスも早過ぎるしリトライも起きないから何のテストにもなってない
あと何よりデバイス出ないから返ってきて欲しい値を手動で設定するとか苦痛過ぎる
ソフトでset○○って入れた値が次のget○○に反映されるみたいなとこまで作れないやろ

**デフォルトの名無しさん** · 2021/02/20(土) 01:44:19.60

何のためにモック使ってるんだ？
素人かなぁ

レスポンスの時間を自由に変えられるのがモックの利点だし
リトライする状態を自由に再現できるのもモックの利点だし
デバイスから帰ってきてほしい値を自由に設定できるのもモックの利点

うーん、わかってない人が、意味不明な答えをしてる状態だｗ

まずそもそもモックはお前が行った問題点を解決するための
ものだということを知りましょう

**デフォルトの名無しさん** · 2021/02/20(土) 01:45:23.84

まあ正確にはスタブだけどね
みんなごっちゃにして使ってるから俺もごっちゃにして使ってるｗ

**デフォルトの名無しさん** · 2021/02/20(土) 01:48:18.86

組み込みでは単体テストよりも実機テストが鬼門
どのプロジェクトでも最初は自動化を夢見ても、実現できたプロジェクトは少ない

自動化ぶん回してたら発熱して煙出てたり電源不足で再起動しちゃったり他の開発機器のノイズ拾ってコケまくったり・・・

**デフォルトの名無しさん** · 2021/02/20(土) 01:54:30.04

MartinFowlerのMocksAre n't Stubsなど、テストでのモックとスタブに関するさまざまな記事を
読みましたが、それでも違いはわかりません。モックvsスタブ=行動テストvs状態テストと言われ
ますし、ライフサイクルが違うと言われますが、それでも違いはわかりません。
先輩がいつもモックモックモック言うので、すこし嫌になりました。

**デフォルトの名無しさん** · 2021/02/20(土) 02:12:02.30

>>491
組み込みのハードの部分が多いのかソフトの部分が多いのか
ハードの部分が多いなら、そりゃソフトウェアのテストじゃなくてハードウェアのテストだ

だが組み込みでもソフトウェアは多いだろ？
そっちはハードウェアなしでテストできる

めんどくさいからソフトウェア部分も
ハードウェア使ってテストするんだよ
時間がかかってしょうがない

っていうのならソフトウェア部分も
ハードウェア使ってじゃないとテストできないのなら
そりゃそうだろうよとしかｗ

**デフォルトの名無しさん** · 2021/02/20(土) 02:24:18.76

>>489
いやーやめた方がいい

値1つとってもそう単純じゃない
例えばある値を3.223から増加量0.005で7まで変化させたいと
その時6.997で装置は処理を止めましたと
これはソフトからしたらクソでも多分バグじゃねぇんだわ
じゃあ、増加量0.001にしたら7になるのかと？
今度は6.995で止まったと
まだ足せんじゃん足せよゴミカスと言いたいが
デバイスのハード的なもんを無理矢理デジタルに直してるようなのはこんなのが限界のときあるんだわ
精度も条件によって変わったりね
多分ハードの値って一つ一つこういう変な癖があって何でもかんでもうまくはいかないと思うよ

ってなるとやっぱり重要なのって結合なんだよね
デバイスと絡んだ値があるとこはすんなりいかないことが多い

**デフォルトの名無しさん** · 2021/02/20(土) 02:32:10.26

>>493
落ち着け、後半日本語めちゃくちゃだぞ・・・

**デフォルトの名無しさん** · 2021/02/20(土) 02:33:03.30

>>494
それ実機でテストする段階にならないとわからないことなの？

COCOAみたいなのもあるし実機テストは必須だとは思うが
それ以前にインターフェース仕様に準じたテストしといたほうがよくない？

**デフォルトの名無しさん** · 2021/02/20(土) 02:35:06.23

>>496
そこに金くれる会社ねーな
よくあることだし
でもやってみないと具合がわからん

**デフォルトの名無しさん** · 2021/02/20(土) 02:37:16.94

>>492
マーチンさんはその記事を出すのが遅かったよねｗ
モックという言葉が広く普及してしまった後だった
rspec界隈？ではテストダブルという言葉を使って言葉を整理しようとしたが
一部でのみ使われて広く普及していない

俺的には、ダミーの値を返すオブジェクトがスタブ
スタブの反対はスパイで、スパイは呼び出された回数や引数を記録しておいて
あとで検証できるもの
スタブとスパイをあわせてモックとしたほうが良かった気がするな

世間的には、スタブ vs モック（スパイはモックの高機能版）と考えればいいよ
スパイは後から検証できるように便利なオブジェクトになってるが
モックはそんな機能がない、もしくは低機能。
だから「テスト対象のコード」から「モック」を呼び出した時に渡されたデータの検証ぐらいしかできない
またスパイもモックも結局はダミーの値を返さないとテスト対象は動かないので多くの場合スタブの機能も兼ねてる

スタブ・・・テスト対象がスタブを呼び出し、スタブはダミーの値を返すだけ
モック・・・テスト対象がモックを呼び出し、その内容をテストする＋スタブ（必須ではないが多くの場合必要）
スパイ・・・テスト対象がスパイを呼び出し、その内容を記録しておいて後からテストする＋スタブ（必須ではないが多くの場合必要）

テストダブル・・・上記の総称

**デフォルトの名無しさん** · 2021/02/20(土) 02:41:28.39

>>494
> いやーやめた方がいい
やめた方がいい理由は？

> 値1つとってもそう単純じゃない
> 例えばある値を3.223から増加量0.005で7まで変化させたいと
> その時6.997で装置は処理を止めましたと
> これはソフトからしたらクソでも多分バグじゃねぇんだわ

バグじゃないなら、その値でテストするだけのこと
お前は、6.997でテストしたか？ 6.995でテストしたか？
してないよな。だって装置が都合よくそんな値で止まってくれないんだから

ハードウェアを使って手動でテストすると 6.995 や 6.997 で止めるのが難しいから
テストの時間がかかる。そういう場合にモックを使うと 6.995 や 6.997 の値を作り出すことができる

単体テストであればデバイスの値を自由に作ることができる

**デフォルトの名無しさん** · 2021/02/20(土) 02:44:52.28

>>497
> でもやってみないと具合がわからん

やってみれば具合がわかるだろ
そしたらそれをテストコードにするだけだろ

おまえはやってみて、その場でコード修正して終わりか？
リグレッションテストはしないのか？当然するよな

別の機種のための修正が、別の機種で不具合を起こす場合
Aでうまく行かない→修正
Bでうまく行かなくなった→修正
Aでまたテストして→修正
Bでも大丈夫かな？→修正

って機種を何度も変更して、同じテストを何度も「手動」で繰り返すんだろ？

テストコードにしてれば、この繰り返しを
自動でできるって言ってるんだよ

**デフォルトの名無しさん** · 2021/02/20(土) 06:09:56.09

>>477
それ誰？

**デフォルトの名無しさん** · 2021/02/20(土) 09:25:13.41

>>499
ええ、いくつ値あると思ってんねん
その一つ一つにデバック用動作つけんの？無理っしょ？

**デフォルトの名無しさん** · 2021/02/20(土) 09:49:08.60

>>502
はっきり言えよ。たくさん値があって大変だから
手動テストではテストしませんって

テストしてないんだろ？いくつ値あると思ってんねん（笑）

**デフォルトの名無しさん** · 2021/02/20(土) 09:55:55.93

クソコードとは何か

**デフォルトの名無しさん** · 2021/02/20(土) 10:00:30.75

テストが手動でテストをするのに膨大な時間がかかるコード

**デフォルトの名無しさん** · 2021/02/20(土) 10:03:35.37

>>503
え？モックとか言うやつの話っしょ？

**デフォルトの名無しさん** · 2021/02/20(土) 10:04:35.86

むしろこういう複雑な動作されるのはそもそも単体じゃないじゃん

**デフォルトの名無しさん** · 2021/02/20(土) 10:06:03.68

>>506
だからお前はモックを使わないで
全部手動で膨大な時間をかけてやるんだって話してるんでしょ？

あ、テストしてないんだっけ？ｗ
プロの仕事じゃないなぁ

**デフォルトの名無しさん** · 2021/02/20(土) 10:07:47.77

>>507
複雑なのはたくさん値があってその組み合わせが膨大だから
手動テストも、その組み合わせをテストしないといけない
時間がかかって現実的だからテストしないって言ってる？
手動テストはテストをしないこと・・・意味がわからんｗ

**デフォルトの名無しさん** · 2021/02/20(土) 10:24:31.88

>>498
ありがとうございます。だけどプロトコルバッファーなどgRPCで生成されるコードにもStubって使うので
もう全部Stubで広義的にはいいじゃんって思います。付加機能があったり、ライフサイクルが複雑であって
テストコードの話に限定できてメインソースじゃない単語だと「モック」と言われてるような気もします。
先輩が見てるといけないので、先輩が嫌いな訳じゃないです、モックモックモックいうのはイライラするので
やめてほしいです。ここで「手動テストは○○○（否定表現）」を連呼する人が先輩に似てます。

**デフォルトの名無しさん** · 2021/02/20(土) 10:32:54.85

「手動テストは時間がかかる」
これは否定表現じゃないからセーフだなｗ

**デフォルトの名無しさん** · 2021/02/20(土) 10:37:02.86

もうこの際だからハッキリ言うと、先輩、それ誰も知ってるから鬼の首を取ったように言われても
ぼくらは困惑ばかりです。正直ウザいです。みんなから嫌われてます

**デフォルトの名無しさん** · 2021/02/20(土) 10:49:31.96

でもそこまで作って尚まだ単体テストなんだぜソレｗ
ぜってーねーよｗ
もう繋げてテストしようよｗ
無駄だよｗ

**デフォルトの名無しさん** · 2021/02/20(土) 10:51:50.41

なんだ？今まであれだけ言い返してたのに
今度は何も言い返してないではないかｗ

**デフォルトの名無しさん** · 2021/02/20(土) 10:56:54.38

キチガイの巣窟スレ

**デフォルトの名無しさん** · 2021/02/20(土) 13:03:05.75

もう流れ追うのも面倒になってる奴多いやろこれｗ
当人同士は必死になっちゃってるんで引けないだろうけど
あとワイの研究結果を勝手に報告するで(｀・ω・´)ｷﾘｯ
適当なソースが思い浮かばなかったんでopenjdkのソースを調査したよ

$ grep --include='*.java' -hroE "new +[^<\( \[]+" jdk-master/src | sed -E 's/new +//g' | sort | uniq -c | sort -nr | head -n 30
5039 String
4884 IllegalArgumentException
3231 Object
3099 ArrayList
2465 byte
2186 int
1718 HashMap
1563 IOException
1548 StringBuilder
1513 UnsupportedOperationException
1465 NullPointerException
1263 RuntimeException
1170 IllegalStateException
976 HashSet
　　：（以下略）

結論：Stringクラスはワイ理論ではもっとも再利用性の有る優れたクラス

**デフォルトの名無しさん** · 2021/02/20(土) 13:04:05.48

一応参考までに省略部分も張っとくわ

924 InternalError
886 {@code
755 XColor
742 AssertionError
737 Dimension
710 char
697 Rectangle
632 instance
610 File
594 value
486 DerOutputStream
466 Vector
436 double
408 PrivilegedAction
394 InvalidKeyException
393 Label

**デフォルトの名無しさん** · 2021/02/21(日) 19:53:59.50

誰か突っ込んでやれよ

**デフォルトの名無しさん** · 2021/02/21(日) 21:30:03.47

再利用できないコードの特徴
・凝集度が低い
・結合度が高い

この2つがセットだと、自分が使いたい機能に対して無関心な知識まで要求される
そういうのがクソコードの筆頭だと思う

Stringは、上手く実装されている例だな

**デフォルトの名無しさん** · 2021/02/22(月) 00:29:45.74

もしかして文字列出力が多いソフトウェアだと文字列クラスの利用が多くなるんじゃないか？

そうでなくとも5000個の文字列が各所に散らばってるんだろ
どうやって文章を管理して辻褄合わせるんだよ