テストを書いてからリファクタリングなんてのは幻想

**デフォルトの名無しさん** · 2012/10/03(水) 00:24:26.88

テストを書いてからリファクタリングするというけれど、
コードの内容によっては、それが現実的に不可能な場合がある。

汚いコードであればあるほど、リファクタリングの前に
テストを書くのは難しくなる。

テストが書けるのは、単機能の関数になっているものだけ。
1000行以上からなる複数の処理を行う関数などテストを先に書くなんてまず不可能。

テストを書くためには、コードの再配置を先にやらなくてはいけない。
コードの順番を変えたりモジュールに分離するなどして、小さな処理にまとめて関数化する。
そこまでやってやっとテストが書ける。

現実的な修正の順番としては

コード再配置 → テストコード記述 → リファクタリング

にならざるをえない。

コード再配置はテストがない状態で行うから非常に神経を使う。
ミスを起こさないような再配置しかやってはいけない。

**デフォルトの名無しさん** · 2012/10/03(水) 00:29:16.55

See: Working Effectively with Legacy Code

**デフォルトの名無しさん** · 2012/10/03(水) 03:59:19.12

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

**デフォルトの名無しさん** · 2012/10/03(水) 14:23:07.28

>>1
> 1000行以上からなる複数の処理を行う関数などテストを先に書くなんてまず不可能。

そうでもないよ。

================================== 終了 ===============================

**デフォルトの名無しさん** · 2012/10/14(日) 16:37:35.20

関数をリファクタリングするのは簡単だが、
明らかに関数になってない処理、
つまりいろんな手続きのあつまりを修正するのは難しい。

なぜなら、その処理の集まりを実行すると
何十もある状態（データベースなどの値）が一気に変化するから。

関数に値を数個入れて、一個の値を返すのではなく
何十個も値を入れて、何十個も値を返すという状態になってる。
そんなものにどうやってテストコードを書くのか。

こういうのはテストコードを書く前に、処理の集まりの中から
関数になる部分を抜き取るという作業になる。

抜き出した部分にテスト書くことはできるが、
処理の集まりの方に、テストを書くのはまず不可能。

**デフォルトの名無しさん** · 2012/10/14(日) 17:42:49.53

関数 {

　ここからAの処理
　　　：
　　　：

　ここからBの処理
　　　：
　　　：

　ここからCの処理
　　　：
　　　：

}
こういうのはリファクタリングしやすい。

**デフォルトの名無しさん** · 2012/10/14(日) 17:44:07.73

でも実際には、こうなっている。

関数 {
　Aの処理その1
　Bの処理その1
　Cの処理その1

　Cの処理その2
　Aの処理その2
　Bの処理その2

　Bの処理その3
　Aの処理その3
　Cの処理その3
}

**デフォルトの名無しさん** · 2012/10/14(日) 17:49:11.03

もちろん、どの行がどの処理かってのはわからないから
見た目にはこう見える。

関数 {
　処理そのa
　処理そのb
　処理そのc

　処理そのd
　処理そのe
　処理そのf

　処理そのg
　処理そのh
　処理そのi
}

**デフォルトの名無しさん** · 2012/10/14(日) 17:49:52.99

>>8のような感じのコードが数千行になっており
仕様も存在しない、書き方も冗長でよくわからないコード

それを綺麗に処理ごとに関数にリファクタリングするのは
すごく大変だということがわかるだろう？

テストを書く前に>>8の状態から>>6の状態に
する必要がある。そうしないと何を関数に分離できるかわからない。

**デフォルトの名無しさん** · 2012/10/14(日) 17:53:01.93

>>8の「関数」のテストを書けばいいだけと思うかもれないが、

「関数」がどんな処理を行なっているかは明確に書かれていない。
データベースの何かの値を読んで、なんかの値を返す。
そしてその他のサーバーとも通信している。
ファイルにも保存する。

徐々に機能が追加されてしまっており仕様がない。
入力となる組み合わせもデータベースのいろんな状態を考慮するために
こんなので全体が何をしているかのテストを書くのは不可能。

**デフォルトの名無しさん** · 2012/10/15(月) 11:19:25.44

>>10
> こんなので全体が何をしているかのテストを書くのは不可能。

そうでもないよ。

================================== 終了 ===============================

**デフォルトの名無しさん** · 2012/10/15(月) 11:24:01.39

反論できないのを見るとすっきりするなｗ

**デフォルトの名無しさん** · 2012/10/15(月) 13:05:35.58

>>12
キミがテストなんか書けないと思ってる関数さらしてごらん。
俺がテスト書いてやるから。

**デフォルトの名無しさん** · 2012/10/15(月) 15:10:45.67

>>13
じゃ、これ
http://www.pro.or.jp/~fuji/mybooks/cdiag/cdiag.10.1.list

テスト書く前に修正はしないようにねｗ

**デフォルトの名無しさん** · 2012/10/15(月) 15:22:46.82

>>14
マジで、この関数のテストどう書けばいいかわかんないの？
超簡単じゃん、これ。書き方が下手なだけで、記述が冗長になってるだけ。

・システムコール以外の関数のスタブを準備する
・扱うファイルのフォーマットがわかるなら、そのファイルを準備する
・フォーマットがわからないなら、システムコールと同名のスタブを準備する
・コンパイルして実行できるmainあるいはxUnitのコードを書く
・全部の（をめざして）return文を実行するようなテストを書く
・全部の（をめざして）if-elseを分岐するようなテストを書く

**デフォルトの名無しさん** · 2012/10/15(月) 15:23:43.32

>>15
口より手を動かす。

自分で書いてやるといったのだから、
言い訳せずに書け。

**デフォルトの名無しさん** · 2012/10/15(月) 15:25:16.96

言っとくが修正が終わったものを持ってくるだけじゃだめだぞ。
ちゃんと先にテストを書いたことがわかるように、
修正前のコード＋テストの状態のものを持ってくること。

**デフォルトの名無しさん** · 2012/10/15(月) 15:26:01.91

つか、まさかとは思うけど、『レガシーコード改善ガイド』読んでないとか？

読めよｗ

**デフォルトの名無しさん** · 2012/10/15(月) 15:27:04.34

>>16
ヘッダファイル準備しろよ。そしたら実コード書いてやる。

**デフォルトの名無しさん** · 2012/10/15(月) 15:34:36.31

>>16
このコードが意味不明なのだから
先にヘッダファイルが用意できるわけがない。

リファクタリングしなければ、ヘッダファイル
（何を関数にするか）判断できないだろ。

今お前はテストの前にリファクタリングを要求したんだよ。

**デフォルトの名無しさん** · 2012/10/15(月) 15:35:18.81

>>16
というかさぁ、キミは>>15の6つのステップを実行できると思うの？思えないの？
実行できないと思えないのはどのステップ？
それはなんで実行できないの？

**デフォルトの名無しさん** · 2012/10/15(月) 15:38:07.18

>>20
> このコードが意味不明なのだから
> 先にヘッダファイルが用意できるわけがない。

ちょっと何言ってるかわからないよ。
リファクタリングの定義知ってる？
動作するものを、その振る舞いを変えずに構造を変えることだよ。
つまり、ビルドできるものが前提。

ヘッダファイルが用意できないのなら、リファクタリングはおろか、ビルドもできないよ。

> リファクタリングしなければ、ヘッダファイル
> （何を関数にするか）判断できないだろ。

ヘッダファイルがなんなのかも知らないの？

関数宣言が入ってたり、構造体の定義が入ってたりする奴だよ？

**デフォルトの名無しさん** · 2012/10/15(月) 15:41:19.98

もっと具体的に書かないとわからいのかな。

PSEND_CONDITIONとかSYS_PAGE_HEADの定義や、MakeSendMountDevice()の宣言が書かれたヘッダが必要。
じゃないとコンパイルできないじゃん。

**デフォルトの名無しさん** · 2012/10/15(月) 15:41:21.69

> それはなんで実行できないの？

テストを書くと時間がかかるので、メリットが
相殺またはマイナスになってしまうから。

たとえば数値を+1する関数にいちいちテストは書かない。
これを間違える可能性は極めて少ないから。

本気でやるのならテスト項目は無限にある。
極端な例で言えば、全パターンの組み合わせテストを
行うと何千年もかかることもある。

すべてにテストを書くのが愚かであるのと同じように
間違いの可能性が少ない修正にテストは不要。
そのようなテスト不要な場所を見つけ、テストを書く前に
ある程度コードをリファクタリングするのが効率が良い。

**デフォルトの名無しさん** · 2012/10/15(月) 15:42:52.44

あと、多分知らないと思うから、StubやMockやxUnitについて調べた方が良いよ。

**デフォルトの名無しさん** · 2012/10/15(月) 15:44:16.59

>>23
> PSEND_CONDITIONとかSYS_PAGE_HEADの定義や、MakeSendMountDevice()の宣言が書かれたヘッダが必要。
> じゃないとコンパイルできないじゃん。

それこそ、スタブ書けって話だなｗ

**デフォルトの名無しさん** · 2012/10/15(月) 15:45:18.08

>>24
安心してリファクタリングができるだけのテストがあれば十分。
誰もC0/C1カバレッジ100%のテストを書けとか言ってないよ？

> 本気でやるのならテスト項目は無限にある。
> 極端な例で言えば、全パターンの組み合わせテストを
> 行うと何千年もかかることもある。

循環的複雑度って知ってるかな。
上のURLのコードは「簡単」な部類だよ。全然「複雑」じゃない。

**デフォルトの名無しさん** · 2012/10/15(月) 15:46:00.22

>>26
> >>23
> > PSEND_CONDITIONとかSYS_PAGE_HEADの定義や、MakeSendMountDevice()の宣言が書かれたヘッダが必要。
> > じゃないとコンパイルできないじゃん。
>
> それこそ、スタブ書けって話だなｗ

スタブが何か知らないんですね。

**デフォルトの名無しさん** · 2012/10/15(月) 15:47:31.99

今俺が話してるのが>>1なのか違うのかしらないけど、俺は

>>1
> 1000行以上からなる複数の処理を行う関数などテストを先に書くなんてまず不可能。

が違うよって言いたいだけなんだよね。
書き方を知らないだけなんじゃ無いのってことで。

**デフォルトの名無しさん** · 2012/10/21(日) 00:18:34.09

変数名とか関数名、型名とかプログラマが自由に付けられるものは、一度
AとかBとかの短い名前に置き換えてみると、>>6 >>7 >>8 の作業がやり易い。
長い名前のままだとそれを目で追って一致しているかどうかを判断するの
が面倒だし、間違いやすい。

ところで、
　コード再配置 → テストコード記述 → リファクタリング
のコード再配置っていうのはリファクタリングの一部ではないの？
つまりスレ主が言いたいのは、
　テストコード記述 → リファクタリング
は不可能で、
　リファクタリング → テストコード記述
しかない、ってことなんじゃないの？

おれもそうだと思うけど。

**デフォルトの名無しさん** · 2012/10/22(月) 11:16:06.10

>>30
何度も言わせないでくれよ。
まず『レガシーコード改善ガイド』を読めよ。

**デフォルトの名無しさん** · 2012/10/22(月) 14:56:28.67

事前にテストなんか書けない、ということにしたい人達って何が目的なんだろうか。
事前にテストを書かないことの理論武装をしたくて、同調者を探してるのか？

**デフォルトの名無しさん** · 2012/10/22(月) 20:18:22.95

事前にテストを書くのは不可能ではないが、
事前にテストを書くとコストが高くなることがある。
レガシーなコードがそう。

ある程度片付けてからテストコードを
書いたほうが効率がいい。

**デフォルトの名無しさん** · 2012/10/22(月) 22:55:12.15

どうやって振る舞いが変わってないことを
証明すんの?

**デフォルトの名無しさん** · 2012/10/23(火) 00:03:06.37

test

**デフォルトの名無しさん** · 2012/10/23(火) 00:08:10.16

変更前のテストが無いと
振るまいが変わってない保証がないよね

**デフォルトの名無しさん** · 2012/10/23(火) 03:07:20.45

テストがあったからって
振る舞いが変わってないという
保証はないよ。

なぜなら、そのテストが完璧なテストであるという
保証がないから。

**デフォルトの名無しさん** · 2012/10/23(火) 03:18:27.38

簡単な処理に対するテストは簡単にかける。

だけど、リファクタリングをしたい＝コードが汚い＝複雑な処理をしている
このテストを書くのは、すごく大変になる。

仮にリファクタリング対象の関数が、10の処理をしていたとしよう。
これが内部で綺麗に分かれていれば、10の処理に対するテストを書いて、10の関数に分ければいい
だけど、10の処理が内部で複雑に絡み合っていたら10乗のテストを書かなければいけない。

これだけテストの数が違うわけで、先にプチリファクタリングを行なって
内部で処理を分解したほうがはるかにコストが低いというのがわかるだろう。

**デフォルトの名無しさん** · 2012/10/23(火) 03:29:50.21

そうだね。恥をかいたのは女性だけど

**デフォルトの名無しさん** · 2012/10/23(火) 03:36:13.09

先にテストをやれば～とか
テストがあれば～とか
言ってる人って、テストの作成・修正のコストを
無視してるんだよねｗ

**デフォルトの名無しさん** · 2012/10/23(火) 06:09:57.99

あまりにひどけりゃリファクタリングよりも書きなおす方を選ぼう。

**デフォルトの名無しさん** · 2012/10/23(火) 06:27:51.93

仕様が完全にわかっていれば
それも出来るだろうけどな。

**デフォルトの名無しさん** · 2012/10/23(火) 06:45:06.99

レガシーコード改善ガイドにも

コードの中の一部分を取り出して、
他のクラスに移動する。

新しいコードのテストは書くが
古いコードのテストは書かないって
よく読めばかいてあるよ。

**デフォルトの名無しさん** · 2012/10/23(火) 10:43:00.90

動いてるソースをいじるなよ

**デフォルトの名無しさん** · 2012/10/23(火) 19:25:45.13

機能追加とバグ改修の要求が一つもなけりゃいじらないよ

**デフォルトの名無しさん** · 2012/10/24(水) 09:50:26.74

リファクタリングに必要なのは結局は説得力だからな
「コードの見かけは変わったけどこの機能は変わってません」ということを報らせることができれば妥協、でいいんじゃないか
必須の機能についてのテストが書かれてなかったのなら、そりゃモトモト足りなかったってことで事前に書いとくのがいいだろう

**デフォルトの名無しさん** · 2012/10/24(水) 16:51:24.57

オリジナルを作ったときのテストなら信じられるが
後から作ったテストは信用ならないな。

**デフォルトの名無しさん** · 2012/10/24(水) 17:07:38.54

>>43
> 新しいコードのテストは書くが
> 古いコードのテストは書かないって
> よく読めばかいてあるよ。

そもそも「レガシーコード」とは、「テストの無いコード」のことであって、それに対して
どう対処していくか、どうテストを書いていけば良いのかが『レガシーコード改善ガイド』なんだけど。

どこをどうよく読んだの？

**デフォルトの名無しさん** · 2012/12/19(水) 01:23:05.20

結論から言うと、素人がやる上から下へのベタ書きの方が理解しやすい

**デフォルトの名無しさん** · 2012/12/19(水) 11:00:58.54

小規模ならね

**デフォルトの名無しさん** · 2012/12/30(日) 00:02:34.08

上から下へのベタ書きが理解しやすいのは
ifとforがほとんどないコードで100行まで。

**デフォルトの名無しさん** · 2013/01/02(水) 11:19:49.01

クローズドな黎明期ならCプログラミング診断室のような糞本でも商売が出来た

**デフォルトの名無しさん** · 2013/01/27(日) 00:48:54.78

ぶっちゃけテストユニット作ってリファクタリングとかより
仕様理解してクソコードは全捨て&全書き直し
その後、人力デバッグした方が手っ取り早い

**デフォルトの名無しさん** · 2013/01/27(日) 00:56:19.75

さんざん言われてるが、どんだけコストをかけるか、かけたコストは回収できるのか、ということでしかないからな
無限の時間と無限のコストと無限の人員と仏の顧客がいるのなら、そりゃあねえ

**デフォルトの名無しさん** · 2013/01/27(日) 14:10:54.08

>仕様理解して

テストコード(あるだけましorソース)が仕様書です。(キリッ

**デフォルトの名無しさん** · 2013/01/28(月) 11:11:45.51

仕様書はウソをつくがテストコードはウソをつかない
客の目に触れない部分は極力無駄なドキュメントを書かない

**デフォルトの名無しさん** · 2013/01/28(月) 13:46:04.77

仕様書の厚さが請求金額に比例します！(ｷﾘｯ

**デフォルトの名無しさん** · 2013/02/06(水) 22:51:21.05

　　　　　　　　　　　　　　　　　　　　　　ヘ(^o^)ヘいいぜ
　　　　　　　　　　　　　　　　　　　　　　　　　|∧ 　
　　　　　　　　　　　　　　　　　　　　　／　　/
　　　　　　　　　　　　　　　　 (^o^)／てめえが何でも
　　　　　　　　　　　　　　　／( 　)　　　　思い通りに出来るってなら
　　　　　　　(^o^) 三　　／　／＞
　＼　　　　 (＼＼三
　(／o^)　　＜　＼三　
　( ／
　／く　まずはそのふざけた
　　　　　　　幻想をぶち殺す

スレタイみたら、このAA貼られまくってんだろうな、と思っていたんだが…

◆ahSvoMzzMtg3 · 2013/06/15(土) 23:55:59.85

そげぶ

**デフォルトの名無しさん** · 2014/02/27(木) 22:28:26.67

設計せずにテスト書くから>>1みたいになるんだろ

**デフォルトの名無しさん** · 2014/03/01(土) 05:02:58.30

「テスト」って「とりあえず作ってみる」ってことで合ってる？

**デフォルトの名無しさん** · 2014/03/01(土) 05:43:48.56

合ってない

**デフォルトの名無しさん** · 2014/03/02(日) 10:27:27.27

じゃぁなんだよ

**デフォルトの名無しさん** · 2014/03/02(日) 11:48:58.69

COBOLの悲劇史を繰り返さないための手段であって
TESTでバグ出しするのは副次的な作業なんだけどな
仕様書や設計書に出てこない後から外から見るとナゾな挙動を説明するための

**デフォルトの名無しさん** · 2014/03/04(火) 02:47:44.08

テストって結局何よ？

**デフォルトの名無しさん** · 2014/03/04(火) 11:53:44.72

Test存在意義がわからない
Testの為に機能を細切れにするの嫌だ
プロジェクトとTestの親和性に問題がある

そんな主張をするヤツを効率的に排除するツール

忍法帖【Lv=7,xxxP】(1+0：5) · 2014/03/06(木) 16:46:28.44

'
てすと

**デフォルトの名無しさん** · 2014/03/07(金) 22:19:35.78

テスト開発駆動

**デフォルトの名無しさん** · 2014/03/10(月) 17:37:30.97

きっちり設計していればテストは不要

**デフォルトの名無しさん** · 2014/03/10(月) 18:43:43.35

自動化できる部分を自動化できることをきっちりという

忍法帖【Lv=10,xxTP】(2+0：5) · 2014/05/24(土) 00:41:48.50

テスト

**デフォルトの名無しさん** · 2014/07/29(火) 23:13:43.20

テストドリブンって生産性悪いよな？

**デフォルトの名無しさん** · 2014/07/30(水) 11:48:15.62

コード量の生産性は悪い
中長期的および小中規模における保守改良を含めると生産性は結果的に高くなる

それだけの話
一人で書く・短期で書く・大人数で分担製作する・顔も知らない人が長期保守する等の場合は大きな障害になりうる
そういうプログラミングしかしないのなら最終証明書的なテスト以外はやらないほうがいいことが多い

**デフォルトの名無しさん** · 2014/10/25(土) 15:43:01.88

>一人で書く・短期で書く・大人数で分担製作する・顔も知らない人が長期保守する等の場合は

どこかの警視庁プロファイリングを思い出した

**デフォルトの名無しさん** · 2014/11/08(土) 14:04:15.77

設計できるレベルのエンジニアが少ないのでしかたない

**デフォルトの名無しさん** · 2014/12/02(火) 21:54:52.49

テストドリチン

**デフォルトの名無しさん** · 2014/12/07(日) 09:17:55.92

1 デフォルトの名無しさん sage 2012/10/03(水) 00:24:26.88
テストを書いてからリファクタリングするというけれど

テストとリファクタリングは関係無くね？

**デフォルトの名無しさん** · 2014/12/17(水) 21:46:46.06

アホには関係

**デフォルトの名無しさん** · 2015/02/14(土) 07:54:44.64

>>1 は正しい指摘をしてるのに

知識もない奴が難癖つけて
糞スレにしてしまった
悲しいことですね

**デフォルトの名無しさん** · 2015/02/14(土) 10:03:56.04

>テストを書いてからリファクタリングするというけれど

どこでそんなこと言われてるんだよ

**デフォルトの名無しさん** · 2015/02/21(土) 05:55:05.56

てすてす。

**デフォルトの名無しさん** · 2015/02/24(火) 06:35:08.88

>>80
世のあちこちで

テスト書かなかったら動作が変わってないってどうやって保証すんのさ

**デフォルトの名無しさん** · 2015/03/10(火) 22:04:47.66

てすと

**デフォルトの名無しさん** · 2015/03/29(日) 23:25:52.43

>>82
仕様書に決まってるでしょ
テストなんてのは仕様書に従っていることを部分的に検査するだけで
完全性を保証するものじゃない

**デフォルトの名無しさん** · 2015/04/05(日) 11:08:09.11

うんこ

**デフォルトの名無しさん** · 2015/04/15(水) 21:28:33.53

>>84
元々テストってそういうもんだよ
少なくともテスト書いた部分は変わってないと確認出来るだけ

仕様書で確認するのはいいけど、仕様書通りに動いてるのをどうやって証明するの？

**デフォルトの名無しさん** · 2015/05/04(月) 11:40:34.47

テストする

**デフォルトの名無しさん** · 2015/06/30(火) 00:28:27.44

もう仕様書の代わりにテストを上から提出してもらえばいいんじゃね？

**デフォルトの名無しさん** · 2015/07/19(日) 08:54:14.12

「テスト仕様書を下さい。でないと作れません」

**デフォルトの名無しさん** · 2015/10/06(火) 17:42:46.37

　　　　　　　　　　　　　　　　　　　　　　ヘ(^o^)ヘいいぜ
　　　　　　　　　　　　　　　　　　　　　　　　　|∧ 　
　　　　　　　　　　　　　　　　　　　　　／　　/
　　　　　　　　　　　　　　　　 (^o^)／テストを書いてから
　　　　　　　　　　　　　　　／( 　)　　　リファクタリング出来るってなら
　　　　　　　(^o^) 三　　／　／＞
　＼　　　　 (＼＼三
　(／o^)　　＜　＼三　
　( ／
　／く　まずはそのふざけた
　　　　　　　幻想をぶち殺す

**デフォルトの名無しさん** · 2015/10/24(土) 07:59:19.85

まず幻想なのは
テストを書いてからやれば全て問題無いとは誰も言ってないのに
そう勘違いしていまった>>1の思考

**デフォルトの名無しさん** · 2015/10/28(水) 21:55:48.26

そげぶ

**デフォルトの名無しさん** · 2015/10/31(土) 20:40:40.38

そもそもファウラーのリファクタリングは読んだの？
テストしてないのにコードいじっちゃったらその時点でリファクタリングじゃナイよ？

**デフォルトの名無しさん** · 2015/11/01(日) 09:19:02.47

とバカが何か言っております
バカほど自分の妄想を普遍的な事実のように語る

**デフォルトの名無しさん** · 2015/11/01(日) 11:24:21.57

ただのコード整理のことをリファクタリングと呼んでるなら別にそれでもいいけどね

**デフォルトの名無しさん** · 2016/01/21(木) 12:50:33.37

ふむ

**デフォルトの名無しさん** · 2016/01/27(水) 22:08:01.75

コード整理はリファクタリングの主要な一種だなあ

**デフォルトの名無しさん** · 2016/01/29(金) 01:36:46.48

振る舞いが変わってないのを証明出来るならどの手法でもリファクタリングを名乗っていいよ

**デフォルトの名無しさん** · 2016/02/03(水) 18:22:39.26

つまりこの世にリファクタリングは存在しない

**デフォルトの名無しさん** · 2016/02/07(日) 15:40:59.07

部分的には出来る

**デフォルトの名無しさん** · 2016/02/14(日) 20:20:34.76

リファクタリングしたらお金貰えますか？

**デフォルトの名無しさん** · 2016/05/20(金) 20:00:00.76

リファクタリングしたらお金もらえる契約だった貰えます

**デフォルトの名無しさん** · 2016/05/21(土) 12:44:55.03

私のリファクタリングおじさんが匿名で銀行にお金を振り込んでくれるよ

**デフォルトの名無しさん** · 2017/02/28(火) 07:59:14.85

俺の全力120%リファクタリングを見せるときが来たようだな

**デフォルトの名無しさん** · 2018/04/22(日) 21:49:11.75

フッ、その程度の力で俺のテストファーストを破れると思うなよ

**デフォルトの名無しさん** · 2018/04/23(月) 13:16:52.06

>>1
一理あるな。
あんまり初心者のだとこのコードのテスト書く意味とは…ってなる。
つまりテスト書く前に直しが入る。

**デフォルトの名無しさん** · 2018/05/23(水) 19:41:33.31

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

VZCU5

**デフォルトの名無しさん** · 2018/07/05(木) 01:50:13.98

6L4

**デフォルトの名無しさん** · 2020/01/29(水) 13:51:22.02

修正ついでにリファクタリングしたけど、機能は変えてないからテストしなくて良いよね

**デフォルトの名無しさん** · 2022/04/22(金) 14:27:10.14

てｓｔ

**あぼーん** · NG

あぼーん

**デフォルトの名無しさん** · 2022/06/10(金) 07:54:47.35

あっそ

**デフォルトの名無しさん** · 2023/06/06(火) 22:29:07.67

>>1
「テストを書く」の意味がわからない。

**デフォルトの名無しさん** · 2023/06/28(水) 13:43:55.35

漠∞！！！！
列∞！！！！！
廷∞！！！！！！
器∞！！！！！！！
斗∞！！！！！！！！
容∞！！！！！！！！！
寿∞！！！！！！！！！！
非∞！！！！！！！！！！！

**デフォルトの名無しさん** · 2023/06/28(水) 17:23:02.87

TDDは設計変更がそうそう起きない場合にしか現実的じゃないわな
外部ツールやらドメインやらの知識が更新されたり、仕様変更が起きると
それに伴う設計変更が起きて、同時にテストも直さなきゃならなくなる
無思慮にテストファーストがいいって言ってるやつは信用ならん

**デフォルトの名無しさん** · 2023/06/28(水) 19:07:09.03

自動テストは無理かも知らんが、
ある程度この種の仕様テストは通すってのは用意しなきゃいかんでしょ。

**デフォルトの名無しさん** · 2023/06/28(水) 19:28:23.06

なんか話が噛み合ってないな
テストを用意するのは当たり前、その上でテストファーストの是非を問うスレじゃないのか

**デフォルトの名無しさん** · 2023/06/28(水) 22:15:25.11

テスト書いたほうが実装は楽
むしろテストお陰で実装の質を上げられる
リファクタリングも同じ

**デフォルトの名無しさん** · 2023/06/30(金) 00:06:22.90

クソ実装に合わせたテストコードなんてリファクタリングしたら無駄になるやろ

**デフォルトの名無しさん** · 2023/06/30(金) 03:44:05.79

最初の実装まではテストいらんよな
・関数Aのテストを書く
・関数Aを書く
・関数Bのテストを書く
・関数Bを書く
・関数Aと関数Bの重複部分を関数Cにリファクタリングするべ
・関数Cのテストを書く
・関数Cを書く
・関数Aのテストを修正←いらんやろ
・関数Aを修正
・関数Bのテストを修正←いらんやろ
・関数Bを修正

**デフォルトの名無しさん** · 2023/06/30(金) 04:40:09.64

実装にはカオス期と安定期があるからカオス期のテストは無駄
安定期に入ったらテストを書け

**デフォルトの名無しさん** · 2023/08/23(水) 00:04:39.70

「テストを書く」って何？

**デフォルトの名無しさん** · 2023/08/23(水) 03:12:21.78

>>122
このスレの文脈ではユニットテストのソースコードを書くという意味では？

**デフォルトの名無しさん** · 2023/08/23(水) 04:28:20.13

仕事だとコーディングのことを「書く」とは言わないからな。

**デフォルトの名無しさん** · 2023/08/25(金) 01:30:03.89

そりゃ頭痛が痛いなんて言わないからな

コードを書くとは言う。
コーディング（コードを書くこと）を書くとは言わない

**デフォルトの名無しさん** · 2023/08/30(水) 15:08:16.42

テスト

**デフォルトの名無しさん** · 2023/09/20(水) 17:55:14.32

ヽ(*'0'*)ﾂﾜｧｵｫ!!

**デフォルトの名無しさん** · 2023/12/06(水) 11:48:46.05

全銀システム障害「詳細設計書見落とし」でオーバーフローの痛恨、再発防止なるか
https://xtech.nikkei.com/atcl/nxt/column/18/00001/08680/

やっぱりテスト駆動にしておけば回避出来たよな

**デフォルトの名無しさん** · 2023/12/09(土) 15:17:43.26

>詳細設計書では4種類のテーブルを同時に展開できるだけの作業領域を確保することを求めていたが、プログラマーやレビュアーなどの関係者がいずれもその記述を見落とし、これが上述のオーバーフローを招いたという痛恨のミスだ
>プログラマーやレビュアーなどの関係者がいずれもその記述を見落とし
つまりテスト環境自体が無くてテストしてからって発想が抜け落ちてるのね

**デフォルトの名無しさん** · 2024/01/02(火) 22:20:43.54

テストケース作るのがしんどいってケースもあるからいつでもテストファーストが良いってことはないわな。

**デフォルトの名無しさん** · 2024/01/03(水) 14:18:03.35

テストの有無とテストファーストの是非を混同してるやつがいるが、
おそらく故意にやってるんだろうな
まあ、釣られてるやつほぼおらんけど

**デフォルトの名無しさん** · 2024/01/04(木) 11:26:57.34

テストケース作るのがしんどいってテストしないのかよ
顧客のところでバグ炸裂して終了じゃんそんなの

**デフォルトの名無しさん** · 2024/01/04(木) 16:14:29.73

まあ実際全銀でバグ炸裂して終了してるしな
NTTデータがケチる所でもないのに客に本番に近いテスト環境も別途必要ですよって説明してないんだろ

**デフォルトの名無しさん** · 2024/01/05(金) 04:49:34.73

やっぱりプログラムを書き始める前に
テストプログラムを書いておく
これが最強

**デフォルトの名無しさん** · 2024/01/10(水) 14:29:25.20

プログラムを書く時は間違えるがテストコードを書く時は間違えない前提

**デフォルトの名無しさん** · 2024/01/10(水) 23:00:16.65

テストコードを間違えるか否か以前に、テストケースが抜け落ちるか否かもあるしな
全銀の件は抜け落ちてた話だから、テストファーストでやっても抜け落ちてたから一緒

**デフォルトの名無しさん** · 2024/01/11(木) 19:24:45.83

根本的な解決策としては
複数人でチェックする
ことかなあ
自分ではなかなか間違いに気が付かないし
自分の間違いが自分で気が付かないのは心理学でなんか名前がついていたような気がする

**デフォルトの名無しさん** · 2024/01/12(金) 08:10:20.90

テストコードを間違いなく漏れなく書ける人がいるならその人がプログラムを書いたらいいだけの話

**デフォルトの名無しさん** · 2024/01/12(金) 21:23:36.19

建築とか機械系ではエラーはほとんど起きないんだけどな
なんでソフトウエアだけ?
ちなみに航空機は安全性を考えていると重くなって飛べなくなるので
安全係数が1を切っていると聞いたが

**デフォルトの名無しさん** · 2024/01/13(土) 14:43:18.36

ライブラリやOSなどの基本ソフトとアプリなどの応用ソフトではまったく状況が違うよ
基本ソフトは大量に配布されて（コピーされて）、頻繁に実行されるので、
最高のエンジニアに作られて、徹底的に検証される（そうされないものは淘汰される）
要するにコスパの問題だよ。1本10万円のゲームで遊びたいかい？

**デフォルトの名無しさん** · 2024/01/13(土) 15:00:13.69

ソシャゲ課金て月に数十万単位だし
無料のAPEXのスパレジェすら1つにつき5万円だし
10万程度は払うやつなら払うよ

**デフォルトの名無しさん** · 2024/01/13(土) 15:07:45.36

>>141
Windowsの売上って四半期で何百億ドルといくらしいけど、
ソシャゲとかってそのぐらいの売上になるの？

**デフォルトの名無しさん** · 2024/01/13(土) 15:37:46.38

四半期の事なんて知らんが
手間考えたらOS売るなんてアホな商売よりはソシャゲのが儲かるだろうね

**デフォルトの名無しさん** · 2024/01/16(火) 04:37:40.68

OS売る商売はLinuxに滅ぼされたからな
早期に見切りをつけてクラウドに移行したMSは先見の明がある

**デフォルトの名無しさん** · 2024/01/17(水) 19:10:33.33

マジかMSはソシャゲ屋になったほうがいいな