テストを書いてからリファクタリングなんてのは幻想
テストを書いてからリファクタリングするというけれど、
コードの内容によっては、それが現実的に不可能な場合がある。
汚いコードであればあるほど、リファクタリングの前に
テストを書くのは難しくなる。
テストが書けるのは、単機能の関数になっているものだけ。
1000行以上からなる複数の処理を行う関数などテストを先に書くなんてまず不可能。
テストを書くためには、コードの再配置を先にやらなくてはいけない。
コードの順番を変えたりモジュールに分離するなどして、小さな処理にまとめて関数化する。
そこまでやってやっとテストが書ける。
現実的な修正の順番としては
コード再配置 → テストコード記述 → リファクタリング
にならざるをえない。
コード再配置はテストがない状態で行うから非常に神経を使う。
ミスを起こさないような再配置しかやってはいけない。 See: Working Effectively with Legacy Code このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
>>1
> 1000行以上からなる複数の処理を行う関数などテストを先に書くなんてまず不可能。
そうでもないよ。
================================== 終了 =============================== 関数をリファクタリングするのは簡単だが、
明らかに関数になってない処理、
つまりいろんな手続きのあつまりを修正するのは難しい。
なぜなら、その処理の集まりを実行すると
何十もある状態（データベースなどの値）が一気に変化するから。
関数に値を数個入れて、一個の値を返すのではなく
何十個も値を入れて、何十個も値を返すという状態になってる。
そんなものにどうやってテストコードを書くのか。
こういうのはテストコードを書く前に、処理の集まりの中から
関数になる部分を抜き取るという作業になる。
抜き出した部分にテスト書くことはできるが、
処理の集まりの方に、テストを書くのはまず不可能。 関数 {
ここからAの処理
：
：
ここからBの処理
：
：
ここからCの処理
：
：
}
こういうのはリファクタリングしやすい。 でも実際には、こうなっている。
関数 {
Aの処理その1
Bの処理その1
Cの処理その1
Cの処理その2
Aの処理その2
Bの処理その2
Bの処理その3
Aの処理その3
Cの処理その3
}
もちろん、どの行がどの処理かってのはわからないから
見た目にはこう見える。
関数 {
処理そのa
処理そのb
処理そのc
処理そのd
処理そのe
処理そのf
処理そのg
処理そのh
処理そのi
}
>>8のような感じのコードが数千行になっており
仕様も存在しない、書き方も冗長でよくわからないコード
それを綺麗に処理ごとに関数にリファクタリングするのは
すごく大変だということがわかるだろう？
テストを書く前に>>8の状態から>>6の状態に
する必要がある。そうしないと何を関数に分離できるかわからない。 >>8の「関数」のテストを書けばいいだけと思うかもれないが、
「関数」がどんな処理を行なっているかは明確に書かれていない。
データベースの何かの値を読んで、なんかの値を返す。
そしてその他のサーバーとも通信している。
ファイルにも保存する。
徐々に機能が追加されてしまっており仕様がない。
入力となる組み合わせもデータベースのいろんな状態を考慮するために
こんなので全体が何をしているかのテストを書くのは不可能。
>>10
> こんなので全体が何をしているかのテストを書くのは不可能。
そうでもないよ。
================================== 終了 =============================== >>12
キミがテストなんか書けないと思ってる関数さらしてごらん。
俺がテスト書いてやるから。 >>13
じゃ、これ
http://www.pro.or.jp/~fuji/mybooks/cdiag/cdiag.10.1.list
テスト書く前に修正はしないようにねｗ >>14
マジで、この関数のテストどう書けばいいかわかんないの？
超簡単じゃん、これ。書き方が下手なだけで、記述が冗長になってるだけ。
・システムコール以外の関数のスタブを準備する
・扱うファイルのフォーマットがわかるなら、そのファイルを準備する
・フォーマットがわからないなら、システムコールと同名のスタブを準備する
・コンパイルして実行できるmainあるいはxUnitのコードを書く
・全部の（をめざして）return文を実行するようなテストを書く
・全部の（をめざして）if-elseを分岐するようなテストを書く >>15
口より手を動かす。
自分で書いてやるといったのだから、
言い訳せずに書け。 言っとくが修正が終わったものを持ってくるだけじゃだめだぞ。
ちゃんと先にテストを書いたことがわかるように、
修正前のコード＋テストの状態のものを持ってくること。 つか、まさかとは思うけど、『レガシーコード改善ガイド』読んでないとか？
読めよｗ >>16
ヘッダファイル準備しろよ。そしたら実コード書いてやる。 >>16
このコードが意味不明なのだから
先にヘッダファイルが用意できるわけがない。
リファクタリングしなければ、ヘッダファイル
（何を関数にするか）判断できないだろ。
今お前はテストの前にリファクタリングを要求したんだよ。 >>16
というかさぁ、キミは>>15の6つのステップを実行できると思うの？思えないの？
実行できないと思えないのはどのステップ？
それはなんで実行できないの？ >>20
> このコードが意味不明なのだから
> 先にヘッダファイルが用意できるわけがない。
ちょっと何言ってるかわからないよ。
リファクタリングの定義知ってる？
動作するものを、その振る舞いを変えずに構造を変えることだよ。
つまり、ビルドできるものが前提。
ヘッダファイルが用意できないのなら、リファクタリングはおろか、ビルドもできないよ。
> リファクタリングしなければ、ヘッダファイル
> （何を関数にするか）判断できないだろ。
ヘッダファイルがなんなのかも知らないの？
関数宣言が入ってたり、構造体の定義が入ってたりする奴だよ？ もっと具体的に書かないとわからいのかな。
PSEND_CONDITIONとかSYS_PAGE_HEADの定義や、MakeSendMountDevice()の宣言が書かれたヘッダが必要。
じゃないとコンパイルできないじゃん。 > それはなんで実行できないの？
テストを書くと時間がかかるので、メリットが
相殺またはマイナスになってしまうから。
たとえば数値を+1する関数にいちいちテストは書かない。
これを間違える可能性は極めて少ないから。
本気でやるのならテスト項目は無限にある。
極端な例で言えば、全パターンの組み合わせテストを
行うと何千年もかかることもある。
すべてにテストを書くのが愚かであるのと同じように
間違いの可能性が少ない修正にテストは不要。
そのようなテスト不要な場所を見つけ、テストを書く前に
ある程度コードをリファクタリングするのが効率が良い。 あと、多分知らないと思うから、StubやMockやxUnitについて調べた方が良いよ。 >>23
> PSEND_CONDITIONとかSYS_PAGE_HEADの定義や、MakeSendMountDevice()の宣言が書かれたヘッダが必要。
> じゃないとコンパイルできないじゃん。
それこそ、スタブ書けって話だなｗ
>>24
安心してリファクタリングができるだけのテストがあれば十分。
誰もC0/C1カバレッジ100%のテストを書けとか言ってないよ？
> 本気でやるのならテスト項目は無限にある。
> 極端な例で言えば、全パターンの組み合わせテストを
> 行うと何千年もかかることもある。
循環的複雑度って知ってるかな。
上のURLのコードは「簡単」な部類だよ。全然「複雑」じゃない。 >>26
> >>23
> > PSEND_CONDITIONとかSYS_PAGE_HEADの定義や、MakeSendMountDevice()の宣言が書かれたヘッダが必要。
> > じゃないとコンパイルできないじゃん。
>
> それこそ、スタブ書けって話だなｗ
スタブが何か知らないんですね。 今俺が話してるのが>>1なのか違うのかしらないけど、俺は
>>1
> 1000行以上からなる複数の処理を行う関数などテストを先に書くなんてまず不可能。
が違うよって言いたいだけなんだよね。
書き方を知らないだけなんじゃ無いのってことで。 変数名とか関数名、型名とかプログラマが自由に付けられるものは、一度
AとかBとかの短い名前に置き換えてみると、>>6 >>7 >>8 の作業がやり易い。
長い名前のままだとそれを目で追って一致しているかどうかを判断するの
が面倒だし、間違いやすい。
ところで、
コード再配置 → テストコード記述 → リファクタリング
のコード再配置っていうのはリファクタリングの一部ではないの？
つまりスレ主が言いたいのは、
テストコード記述 → リファクタリング
は不可能で、
リファクタリング → テストコード記述
しかない、ってことなんじゃないの？
おれもそうだと思うけど。 >>30
何度も言わせないでくれよ。
まず『レガシーコード改善ガイド』を読めよ。 事前にテストなんか書けない、ということにしたい人達って何が目的なんだろうか。
事前にテストを書かないことの理論武装をしたくて、同調者を探してるのか？ 事前にテストを書くのは不可能ではないが、
事前にテストを書くとコストが高くなることがある。
レガシーなコードがそう。
ある程度片付けてからテストコードを
書いたほうが効率がいい。 どうやって振る舞いが変わってないことを
証明すんの? 変更前のテストが無いと
振るまいが変わってない保証がないよね テストがあったからって
振る舞いが変わってないという
保証はないよ。
なぜなら、そのテストが完璧なテストであるという
保証がないから。 簡単な処理に対するテストは簡単にかける。
だけど、リファクタリングをしたい ＝ コードが汚い ＝ 複雑な処理をしている
このテストを書くのは、すごく大変になる。
仮にリファクタリング対象の関数が、10の処理をしていたとしよう。
これが内部で綺麗に分かれていれば、10の処理に対するテストを書いて、10の関数に分ければいい
だけど、10の処理が内部で複雑に絡み合っていたら10乗のテストを書かなければいけない。
これだけテストの数が違うわけで、先にプチリファクタリングを行なって
内部で処理を分解したほうがはるかにコストが低いというのがわかるだろう。 先にテストをやれば〜とか
テストがあれば〜とか
言ってる人って、テストの作成・修正のコストを
無視してるんだよねｗ あまりにひどけりゃリファクタリングよりも書きなおす方を選ぼう。 仕様が完全にわかっていれば
それも出来るだろうけどな。 レガシーコード改善ガイドにも
コードの中の一部分を取り出して、
他のクラスに移動する。
新しいコードのテストは書くが
古いコードのテストは書かないって
よく読めばかいてあるよ。 機能追加とバグ改修の要求が一つもなけりゃいじらないよ リファクタリングに必要なのは結局は説得力だからな
「コードの見かけは変わったけどこの機能は変わってません」ということを報らせることができれば妥協、でいいんじゃないか
必須の機能についてのテストが書かれてなかったのなら、そりゃモトモト足りなかったってことで事前に書いとくのがいいだろう オリジナルを作ったときのテストなら信じられるが
後から作ったテストは信用ならないな。 >>43
> 新しいコードのテストは書くが
> 古いコードのテストは書かないって
> よく読めばかいてあるよ。
そもそも「レガシーコード」とは、「テストの無いコード」のことであって、それに対して
どう対処していくか、どうテストを書いていけば良いのかが『レガシーコード改善ガイド』なんだけど。
どこをどうよく読んだの？ 結論から言うと、素人がやる上から下へのベタ書きの方が理解しやすい 上から下へのベタ書きが理解しやすいのは
ifとforがほとんどないコードで100行まで。 クローズドな黎明期ならCプログラミング診断室のような糞本でも商売が出来た ぶっちゃけテストユニット作ってリファクタリングとかより
仕様理解してクソコードは全捨て&全書き直し
その後、人力デバッグした方が手っ取り早い さんざん言われてるが、どんだけコストをかけるか、かけたコストは回収できるのか、ということでしかないからな
無限の時間と無限のコストと無限の人員と仏の顧客がいるのなら、そりゃあねえ >仕様理解して
テストコード(あるだけましorソース)が仕様書です。(キリッ 仕様書はウソをつくがテストコードはウソをつかない
客の目に触れない部分は極力無駄なドキュメントを書かない ヘ(^o^)ヘ いいぜ
|∧
／ /
(^o^)／ てめえが何でも
／( ) 思い通りに出来るってなら
(^o^) 三 ／ ／ ＞
＼ (＼＼ 三
(／o^) ＜ ＼ 三
( ／
／ く まずはそのふざけた
幻想をぶち殺す
スレタイみたら、このAA貼られまくってんだろうな、と思っていたんだが… 「テスト」って「とりあえず作ってみる」ってことで合ってる？ COBOLの悲劇史を繰り返さないための手段であって
TESTでバグ出しするのは副次的な作業なんだけどな
仕様書や設計書に出てこない後から外から見るとナゾな挙動を説明するための Test存在意義がわからない
Testの為に機能を細切れにするの嫌だ
プロジェクトとTestの親和性に問題がある
そんな主張をするヤツを効率的に排除するツール 自動化できる部分を自動化できることをきっちりという コード量の生産性は悪い
中長期的および小中規模における保守改良を含めると生産性は結果的に高くなる
それだけの話
一人で書く・短期で書く・大人数で分担製作する・顔も知らない人が長期保守する等の場合は大きな障害になりうる
そういうプログラミングしかしないのなら最終証明書的なテスト以外はやらないほうがいいことが多い >一人で書く・短期で書く・大人数で分担製作する・顔も知らない人が長期保守する等の場合は
どこかの警視庁プロファイリングを思い出した 設計できるレベルのエンジニアが少ないのでしかたない 1 デフォルトの名無しさん sage 2012/10/03(水) 00:24:26.88
テストを書いてからリファクタリングするというけれど
テストとリファクタリングは関係無くね？ >>1 は正しい指摘をしてるのに
知識もない奴が難癖つけて
糞スレにしてしまった
悲しいことですね >テストを書いてからリファクタリングするというけれど
どこでそんなこと言われてるんだよ >>80
世のあちこちで
テスト書かなかったら動作が変わってないってどうやって保証すんのさ >>82
仕様書に決まってるでしょ
テストなんてのは仕様書に従っていることを部分的に検査するだけで
完全性を保証するものじゃない >>84
元々テストってそういうもんだよ
少なくともテスト書いた部分は変わってないと確認出来るだけ
仕様書で確認するのはいいけど、仕様書通りに動いてるのをどうやって証明するの？ もう仕様書の代わりにテストを上から提出してもらえばいいんじゃね？ ヘ(^o^)ヘ いいぜ
|∧
／ /
(^o^)／ テストを書いてから
／( ) リファクタリング出来るってなら
(^o^) 三 ／ ／ ＞
＼ (＼＼ 三
(／o^) ＜ ＼ 三
( ／
／ く まずはそのふざけた
幻想をぶち殺す まず幻想なのは
テストを書いてからやれば全て問題無いとは誰も言ってないのに
そう勘違いしていまった>>1の思考 そもそもファウラーのリファクタリングは読んだの？
テストしてないのにコードいじっちゃったらその時点でリファクタリングじゃナイよ？ とバカが何か言っております
バカほど自分の妄想を普遍的な事実のように語る ただのコード整理のことをリファクタリングと呼んでるなら別にそれでもいいけどね 振る舞いが変わってないのを証明出来るならどの手法でもリファクタリングを名乗っていいよ リファクタリングしたらお金もらえる契約だった貰えます 私のリファクタリングおじさんが匿名で銀行にお金を振り込んでくれるよ 俺の全力120%リファクタリングを見せるときが来たようだな フッ、その程度の力で俺のテストファーストを破れると思うなよ >>1
一理あるな。
あんまり初心者のだとこのコードのテスト書く意味とは…ってなる。
つまりテスト書く前に直しが入る。 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
VZCU5 修正ついでにリファクタリングしたけど、機能は変えてないからテストしなくて良いよね 漠∞！！！！
列∞！！！！！
廷∞！！！！！！
器∞！！！！！！！
斗∞！！！！！！！！
容∞！！！！！！！！！
寿∞！！！！！！！！！！
非∞！！！！！！！！！！！ TDDは設計変更がそうそう起きない場合にしか現実的じゃないわな
外部ツールやらドメインやらの知識が更新されたり、仕様変更が起きると
それに伴う設計変更が起きて、同時にテストも直さなきゃならなくなる
無思慮にテストファーストがいいって言ってるやつは信用ならん 自動テストは無理かも知らんが、
ある程度この種の仕様テストは通すってのは用意しなきゃいかんでしょ。 なんか話が噛み合ってないな
テストを用意するのは当たり前、その上でテストファーストの是非を問うスレじゃないのか テスト書いたほうが実装は楽
むしろテストお陰で実装の質を上げられる
リファクタリングも同じ クソ実装に合わせたテストコードなんてリファクタリングしたら無駄になるやろ 最初の実装まではテストいらんよな
・関数Aのテストを書く
・関数Aを書く
・関数Bのテストを書く
・関数Bを書く
・関数Aと関数Bの重複部分を関数Cにリファクタリングするべ
・関数Cのテストを書く
・関数Cを書く
・関数Aのテストを修正←いらんやろ
・関数Aを修正
・関数Bのテストを修正←いらんやろ
・関数Bを修正 実装にはカオス期と安定期があるからカオス期のテストは無駄
安定期に入ったらテストを書け >>122
このスレの文脈ではユニットテストのソースコードを書くという意味では？ 仕事だとコーディングのことを「書く」とは言わないからな。 そりゃ頭痛が痛いなんて言わないからな
コードを書くとは言う。
コーディング（コードを書くこと）を書くとは言わない 全銀システム障害「詳細設計書見落とし」でオーバーフローの痛恨、再発防止なるか
https://xtech.nikkei.com/atcl/nxt/column/18/00001/08680/
やっぱりテスト駆動にしておけば回避出来たよな >詳細設計書では4種類のテーブルを同時に展開できるだけの作業領域を確保することを求めていたが、プログラマーやレビュアーなどの関係者がいずれもその記述を見落とし、これが上述のオーバーフローを招いたという痛恨のミスだ
>プログラマーやレビュアーなどの関係者がいずれもその記述を見落とし
つまりテスト環境自体が無くてテストしてからって発想が抜け落ちてるのね テストケース作るのがしんどいってケースもあるからいつでもテストファーストが良いってことはないわな。 テストの有無とテストファーストの是非を混同してるやつがいるが、
おそらく故意にやってるんだろうな
まあ、釣られてるやつほぼおらんけど テストケース作るのがしんどいってテストしないのかよ
顧客のところでバグ炸裂して終了じゃんそんなの まあ実際全銀でバグ炸裂して終了してるしな
NTTデータがケチる所でもないのに客に本番に近いテスト環境も別途必要ですよって説明してないんだろ やっぱりプログラムを書き始める前に
テストプログラムを書いておく
これが最強 プログラムを書く時は間違えるがテストコードを書く時は間違えない前提 テストコードを間違えるか否か以前に、テストケースが抜け落ちるか否かもあるしな
全銀の件は抜け落ちてた話だから、テストファーストでやっても抜け落ちてたから一緒 根本的な解決策としては
複数人でチェックする
ことかなあ
自分ではなかなか間違いに気が付かないし
自分の間違いが自分で気が付かないのは心理学でなんか名前がついていたような気がする テストコードを間違いなく漏れなく書ける人がいるならその人がプログラムを書いたらいいだけの話 建築とか機械系ではエラーはほとんど起きないんだけどな
なんでソフトウエアだけ?
ちなみに航空機は安全性を考えていると重くなって飛べなくなるので
安全係数が1を切っていると聞いたが ライブラリやOSなどの基本ソフトとアプリなどの応用ソフトではまったく状況が違うよ
基本ソフトは大量に配布されて（コピーされて）、頻繁に実行されるので、
最高のエンジニアに作られて、徹底的に検証される（そうされないものは淘汰される）
要するにコスパの問題だよ。1本10万円のゲームで遊びたいかい？ ソシャゲ課金て月に数十万単位だし
無料のAPEXのスパレジェすら1つにつき5万円だし
10万程度は払うやつなら払うよ >>141
Windowsの売上って四半期で何百億ドルといくらしいけど、
ソシャゲとかってそのぐらいの売上になるの？ 四半期の事なんて知らんが
手間考えたらOS売るなんてアホな商売よりはソシャゲのが儲かるだろうね OS売る商売はLinuxに滅ぼされたからな
早期に見切りをつけてクラウドに移行したMSは先見の明がある 
