クソコードとは何か

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

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

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

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

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

**デフォルトの名無しさん** · 2021/02/18(木) 00:43:39.30

>>342
思い込みのハゲしい人ですね。最初からいいますよ？私は自動テストも手動テストも否定してない。まず上の方の
人たちと同一人物視をやめなさい。あなたは「担保するの」と書いていて「速度」のことなんて、ID上は今まで
1回も言っていません。ちゃんと質問するなら
「手動テスト”だけ”で仕様通りにテストを行い、変更があったら”同じテストを繰り返した”と
　担保して、素早いテストの繰り返しによる開発を継続するのでしょうか？」ですよね

もちろん手動テスト”だけ”でも時間と費用があれば無理ではありませんが、当然時間がかかります。
この質問であれば、「素早い開発」の要件を満たせないのでテストコードによるイテレーションテスト「も」
必要になります。「無理」というのはあんたの頭の中でできてるストーリーに無理ができているだけです。

「嘘つくな（笑）オープンソースでなんか証拠持ってきてみ」
このような会話は５ｃｈだから通用しますが、現実世界ではあなたは爪弾きでしょう。何を言いたいのか
サッパリ分かりません。日本語が不自由な方かと思いましたが、思考が不自由な方だ
1.聞きたいことが質問にまとめられていない
2.聞きたいことを回答する人を馬鹿にして遊んでる
3.最初から（自分だけの）結論ありきで語っている

また頻繁に変更が入るコードで何度も同じテストを実行することはありますが、変更が入らないコードでは
同じテストを実行する事は無駄です。一部のツールはテスト結果で省略すらします。
自動ｖｓ手動という考えはあんたの頭の中にしかない初めて披露された考えです。この両者は対立構造では
ありませんし、ましてや勝つとか負けるとかどーでもいい事です。それがマウントと言っているのですよ

**デフォルトの名無しさん** · 2021/02/18(木) 00:44:42.11

>>345
一般的な言語なら普通にできるよ

**デフォルトの名無しさん** · 2021/02/18(木) 00:45:02.81

長文読まないよ

**デフォルトの名無しさん** · 2021/02/18(木) 00:45:40.48

結局の所、手動テストは時間がかかって
信頼性もないってことだろ

**デフォルトの名無しさん** · 2021/02/18(木) 00:46:31.03

>>347
自動テストでそれは解決できないだろ

**デフォルトの名無しさん** · 2021/02/18(木) 00:48:39.39

>>353
それはシートベルトでは衝突事故は防げないだろ論法？ｗ

手動テストは、高速に同じテストを何度も実行できない
手動テストは、正しくテストをしたという担保がない
自動テストで解決できてるだろ

**デフォルトの名無しさん** · 2021/02/18(木) 00:49:53.24

>>348
ごめんね、引数が100個あればクソコードかと言えば、そうでもなく可変引数展開するような言語では
配列渡しになったりするので「テストコード」も「開発手法」もここのタイトルだと何も関係ないね

**デフォルトの名無しさん** · 2021/02/18(木) 00:51:16.80

>>354
自動テストってなんで正しいの？

**デフォルトの名無しさん** · 2021/02/18(木) 00:52:15.60

自動テストってコードありきで作っちゃったゴミカステストしか見たことないよ

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

>>356
それをいうなら、
「自動テストは、正しくテストをしたという担保があるの？」
だよね。

コンピュータは書いたとおりに動く
だから、テストコードで書いたテストを
正しく行ったことが担保されている

それに対して人間は、いくらテスト指示書にこうしろと
書いてあったとしても間違えることがあるしサボることもある
なんかおかしい気がしたけど気づかずにスクショ取ってOKと記入してしまうこともある
だがあとになって調べようとしても、その時のテストが
間違っていたり手抜きしたことがわからない

**デフォルトの名無しさん** · 2021/02/18(木) 00:56:12.19

>>357
OSSなら基本的にテストファーストはしてないね、プロトタイプ作って0.1にバージョニングして
後からテストコード追加ですね。業務コードだとTDDを最初からやろうとする企業もあるけどさ
作ったテストが要件や機能に合わなくなることはあるあるネタだ

**デフォルトの名無しさん** · 2021/02/18(木) 00:57:26.69

>>358
いや、ないよ

**デフォルトの名無しさん** · 2021/02/18(木) 00:57:49.51

>>359
普通、一つのコミットの中にテストコードと実装コードが含まれるけど
テストファーストしてないという根拠は？

後からテストコードが追加されたことがあるからといって、
それはテストファーストしてない理由にはならない

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

>>360
何か言い返せよｗ
言い返せないのにレスだけするから恥をかくんだぞｗ

**デフォルトの名無しさん** · 2021/02/18(木) 00:59:52.93

>>362
だってないもん
単体テストなんか仕様書ビルドしてできたわけでもねーのにそんな正しさがいきなり入る前提なのが気が狂ってる

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

バカが作ればバカなりな正常が定義されるだけだろ
夢みんな

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

>>363
ああ「正しさ」だけ書いて論点をすり替えようとしてるのねｗ

俺がずーっと言ってるのは
「手動テストでどうやってちゃんと書いてあるとおりにテストしたと担保するの？」

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

手動テストではいくらテスト項目が書いてあったからって
そのとおり正しくテストしたという保証がまったくないんだわ
人間は間違えることがあるから

**デフォルトの名無しさん** · 2021/02/18(木) 01:04:27.27

>>365
いや、それ自動テストと手動テストに違いないじゃん
自動テストの間違ったテストコードで正常になっちゃったも
手動テストで間違ったエビデンスのとり方して正常になっちゃったも
違いねーし
頭おかしんちゃう？お前

**デフォルトの名無しさん** · 2021/02/18(木) 01:06:47.98

>>367
自動テストの間違ったテストコードで正常になっちゃった場合は
テストコードを見れば、テストコードが間違っていたとあとからわかる

手動テストでは、テスト作業が間違っていたのかどうかもわからない
あとから見た所で、作業内容自体までスクショ取ってないから。
それとも監視カメラで作業員の行動を動画で撮って
あとからその動画を眺めるつもりか？
コンビニの監視カメラの映像を確認するように

一体何時間時間がかかると思ってるんだ

**デフォルトの名無しさん** · 2021/02/18(木) 01:07:56.11

>>368
え？わかるやり方もあるでしょ？バカなん？

**デフォルトの名無しさん** · 2021/02/18(木) 01:08:25.16

だから手動テストでは
もう一回やったら再現できませんでしたとか
ちゃんとテストしたのに実際は動きませんでした
とか発生した時に、その原因の追求ができない

うごくからヨシっていう
適当な仕事をしてる

**デフォルトの名無しさん** · 2021/02/18(木) 01:09:01.59

>>369
その分るやり方を書けよｗ
お前議論できねーな

言い返す言葉がないならレスしなくていいんだぞ？

**デフォルトの名無しさん** · 2021/02/18(木) 01:09:10.15

>>368
あとテストコード見たってわかんないよ
仕様書見るんでしょ？
それは手動テストだって同じだよね？

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

>>370
は？
自動テストだって同じでしょ？
デバイス絡みがコードだけで動くわけ無いじゃん

**デフォルトの名無しさん** · 2021/02/18(木) 01:11:16.43

>>372
テストコードみれば、実際にやったテストがわかるだろ？
馬鹿なのか？

手動テストでは、何が書いてあっても
実際にどういうテストをやったかがわからない
人間が間違えたかもしれないって話をしてるのだが
ついてこれてる？

**デフォルトの名無しさん** · 2021/02/18(木) 01:11:52.03

俺がつないであるプリンタを踵落としで叩き割ったらもう動かないよね？

**デフォルトの名無しさん** · 2021/02/18(木) 01:12:02.27

>>373
> 自動テストだって同じでしょ？

なにが同じなんだよ？

自動テストなら実際にやったテストがわかる or 手動テストではわからない
って話をしてるんだが、ついてこれてる？

**デフォルトの名無しさん** · 2021/02/18(木) 01:12:12.31

>>363
「普通、一つのコミットの中にテストコードと実装コードが含まれる」間違い、0点です。
OSSでもクローズドソースでも普通はコミットの中には、偏在が生じます。TDD推進や原理主義者では
テストコード比率は80%だと主張する方もいます。一般的にOSSではテストコードがほとんどない方が
多いです。もちろんこれの正当性を主張するわけでもありませんが、何故そうなるのかと言えば多くが
個人開発だからです。いい加減な自動テストが含まれていて、それをテストファーストと主張するなら
主張すればいいですよｗ

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

>>375
その点テストコードは、バージョン管理するから
動いていたものが動かなくなった原因までしっかり記録される

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

>>374
は？それが正しいかどうかは仕様書見ないとわからないだろ？
仕様書とテストコードとコード見るんやな
なんか無駄じゃねぇの？
仕様書とコード見るだけでよくね？

なんでテストコード書く必要あったんだっけ？

**デフォルトの名無しさん** · 2021/02/18(木) 01:15:16.04

そもそも仕様書とコードを見比べてどうして正しいかわからないんだっけ？

**デフォルトの名無しさん** · 2021/02/18(木) 01:15:18.95

>>377
> 「普通、一つのコミットの中にテストコードと実装コードが含まれる」間違い、0点です。

ん？証拠を持ってくればいいわけ？

例なんていくらでもあるけど、一つのコミットの中にテストコードと実装コードが含まれてます。
https://github.com/facebook/react/pull/20813/files

**デフォルトの名無しさん** · 2021/02/18(木) 01:15:52.08

>>381
ウィルス

**デフォルトの名無しさん** · 2021/02/18(木) 01:16:06.06

>>379
いい加減「正しい」の意味をすり替えるのやめろ

「書いてあるとおりに正しくテストした」ことが
自動テストならわかるって言ってるだろ

**デフォルトの名無しさん** · 2021/02/18(木) 01:16:36.10

>>382
そうだよね。そうやって嘘を付くしかないもんねｗ

**デフォルトの名無しさん** · 2021/02/18(木) 01:17:07.59

>>383
え？それは仕様書通りって意味でないとビジネスで役に立たないよね？

**デフォルトの名無しさん** · 2021/02/18(木) 01:17:45.50

自動テストでどうやって仕様書通りかどうかわかるの？

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

お前のテストコードがクソコードだったら終わりじゃん

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

さっきからなんの正しい説明にもなってないじゃん
自動テストも手動テストも仕様書通りかどうかテストすんだろ
何度も言わせるなクソが

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

>>381
js系の人ですか（笑）reactの場合、ver17.0.0になってもissueのOpen数が500あります。明らかにデグレを
生んでいますが、issueのClose数も1万近くです。テストが完璧だとどうやって担保しているでしょうか？（笑）
リリース数は数えたら137回です

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

>>381
ん？ショーコですか？誰もそんな事言ってないと思いますが？ｗ
参考までにそのコミットの1つ前にはテストコードが含まれてませんが？ｗ2つ前も含まれてませんw
対象コードはCIのコードですがｗよくあるFix typo も多くはテストコードとやらは含まれませんね。

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

>>387
”「書いてあるとおりに正しくテストしたことが自動テストならわかる」って言ってるだろ ”
上の方を見ても1回もそんな事はいってませんね・・・それと、日本語の区切りがおかしいので
直しておきました。「書いてあるとおりに正しくテストした」これを一言で言えばオナニー猿です。

逃げてしまったのか

**デフォルトの名無しさん** · 2021/02/18(木) 06:37:17.08

>>327
はいはい、どうしようもない現実を知らないとか幸福な人生で何よりですw

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

テストの内容（文章 or コード）が、仕様書通りかは、手動テストも自動テストもわからない
この勝負はドロー（引き分け）

テストの内容（文章 or コード）が仕様書通り正しいと仮定する
手動テストは、テストの内容を正しく実行したとは限らないが
自動テストであれば、テストの内容を正しく実行したことが保証される
なぜならコードは書いたとおりに動くから

この勝負は自動テストの勝ち

**デフォルトの名無しさん** · 2021/02/18(木) 07:11:33.36

>>393
だからテストコードのテストを行わなければ完結しない

ということだね

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

>>394
テストコードのテストというのは意味不明
お前の理屈だと、テストのテストが必要になるだろ
テストのテストのテストも必要になるだろ
アホらしい

テストコードに必要なのはコードレビュー
テストコードのレビューが必要なように
テスト実行手順書のレビューも必要

この勝負はドロー

そしてテストコードのレビューがOKだった場合
書いてあるテストコードの通りテストは行われるが

テスト実行手順書のレビューがOKでも
手動でテストすると、そのとおりにテストが行われるとは限らない

ということで、手動テストの負けになる

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

>>308

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

俺が折角>>305で流れ戻してやろうと思ったのに馬鹿を刺激すんな
もう手遅れだけど

馬鹿は詭弁を並べて相手にならねーから会話するな
馬鹿と会話しようとするから疲れる
テキトーに流しとけ

**デフォルトの名無しさん** · 2021/02/18(木) 11:03:49.56

推奨するやつの頭が悪いから
テストの自動化自体も悪く見えるパターンだなこれ

ルビきちパターン

**デフォルトの名無しさん** · 2021/02/18(木) 11:05:28.89

>>397
馬鹿筆頭の自覚無しw

**デフォルトの名無しさん** · 2021/02/18(木) 11:40:46.00

>>399
煽り耐性無さ過ぎ...

**デフォルトの名無しさん** · 2021/02/18(木) 11:49:50.78

スレの趣旨的にはむしろ>>305が正しい

**デフォルトの名無しさん** · 2021/02/18(木) 12:14:02.17

>>1や>>305の中身がペラいから欲しい反応を貰えないだけやろ

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

>>320の"再利用性の無いクラスは糞"でトライしてみたんだろうけどペラすぎて役に立たないから誰も反応しない

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

そう？
むしろさり気なくanemic domainの話をしてる奴らがいたから、良スレの予感したのに一人の馬鹿が荒らした挙げ句に単体テストの必要性の有無とかいう低レベルスレになってがっかりしてる俺がここにいるけど？

内容がペラいってか、本当の経験者なら察せるし、一言二言から深堀すればいいのに

**デフォルトの名無しさん** · 2021/02/18(木) 12:28:13.80

単体テストの話で流れるせいで誰も手が出せん
何なら、隔離スレいる？

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

ペラいとか言うけど、そもそも>>320の言ってることわかる？
他人を批判する前に貴方の実力チェックがしたいのだが、なんで再利用できないクラスがクソなのかわかる？

**デフォルトの名無しさん** · 2021/02/18(木) 14:03:58.21

>>406
>なんで再利用できないクラスがクソなのかわかる？

その考え方がペラいって言ってんのにわかんないやつだな
これ全部同一人物じゃなきゃありえんな

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

>>407
その考えとは？わからないから教えてくれや

**デフォルトの名無しさん** · 2021/02/18(木) 14:52:32.67

>>407
まさか再利用できないクラスが普通だとか思ってる？流石にそれはレベル低すぎてその発想はなかったけど、そういうこと？

たのむから伝わるように文章を書いてくれ
お前の文章こそ情報量がない
あるのは相手にマウントを取ろうとする意気込みだけ

**デフォルトの名無しさん** · 2021/02/18(木) 15:50:41.18

>>408
一般常識を持たず
自分の半径5cmの出来事の一側面だけを見て
コンテキストを無視して一般化しようとする考え方

**デフォルトの名無しさん** · 2021/02/18(木) 15:59:27.62

>>410
一般常識？ID変えながら、こんな時間に2chやる俺らが？w
発言元からコンテキスト境界を読み取れずに他人を批判するお前こそ薄ペラ野郎だわ

**デフォルトの名無しさん** · 2021/02/18(木) 17:08:42.38

まず再利用性とは何かをまるで理解していない
アプリ全体の一箇所でしかインスタンス化されないからといって再利用性が無いとは言わない
再利用には様々な形があるにもかかわらずインスタンス化される箇所の数という著しく狭い一つの側面だけしか見えていない

そもそもインスタンス化される箇所の数と、そのクラスがクソかどうかとは何の関係も無い
ないない尽くし

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

クラスの再利用性の度合いが低ければそのクラスがクソかと言えば全くそんなことは無い
クソがどうかは再利用性の度合いとは関係ない

クラスベースのOO言語を使ってるならどんなアプリでそのアプリ特有の処理はそのアプリの用途に特化したクラスで実現する
当然、一般的に言うところのクラスとしての再利用性は無い

それだけでクソだと言い出したらGoogleが作るものでもMSが作るものでも世の中のアプリはほぼ全てクソの塊

**デフォルトの名無しさん** · 2021/02/18(木) 17:49:20.06

ジョブがやたら多いシステムきつい

**デフォルトの名無しさん** · 2021/02/18(木) 17:53:10.20

>>413
> クラスベースのOO言語を使ってるならどんなアプリでそのアプリ特有の処理はそのアプリの用途に特化したクラスで実現する
> 当然、一般的に言うところのクラスとしての再利用性は無い

そんなの当たり前じゃん
殺人事件が起きて殺人は駄目だと訴える遺族の前で死刑囚は殺してはいけないと言うのか？とか言い出すようなもの

それくらい察してやれ

**デフォルトの名無しさん** · 2021/02/18(木) 17:59:21.72

って、アプリ特有ってまさか業務特有の処理とかじゃないよな？
フレームワーク特有だったらわかるけど

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

組込してるけど、USBクラス、SDカードクラスのインスタンス化が封じられていて、しかもUSBクラスの中にMCUのポートに依存する処理が書かれてたらクソだと思う

なんで、回路構成変わるたびにいちいちUSBのロジックを実装しなきゃなんねーんだよクソがって言いたい

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

>>417
なんで修正しないの？
staticなメソッドとメンバーのみを使うとしても必要なところを入れ替えるように作れるでしょ

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

トイレ行っていい？

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

>>418
文面だと伝わりづらいと思うからコード書くけど
USBポートが2ポートある場合

USB usb1 = new USB（port1）
USB usb2 = new USB（port2）

で済むのに、インスタンス化を封じられたら

USB1 usb1 = USB1.getSingleton（）
USB2 usb2 = USB2.getSingleton（）

みたいにUSB1クラス、USB2クラスを自分で定義しないといけなくなるからやめた方がいいよって話
なぜかというと、USB1と2に同じコードを書かないといけないし、もし、USBの処理に仕様変更が生じると、今後はUSB1と2を変更しないと駄目だから
面倒でしょ？2個程度なら...という油断は命取り

>>419
ご自由に

**デフォルトの名無しさん** · 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
> テストコードがソースコードである以上テストしないわけにはいかんだろ
だからいらない
馬鹿なのかな？
テストコードのテストなんてお前したことないだろ？
世の中の誰もしたことないわｗ
そんなものありはしないんだから

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

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