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

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

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

テストが書けるのは、単機能の関数になっているものだけ。
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
何度も言わせないでくれよ。
まず『レガシーコード改善ガイド』を読めよ。

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

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

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

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

test

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

小規模ならね

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

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

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

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

>仕様理解して

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

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

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

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

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

そげぶ

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

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

合ってない

じゃぁなんだよ

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

テストって結局何よ？

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

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

'
てすと

テスト開発駆動

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

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

テスト

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

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

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

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

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

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

テスト ドリチン

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

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

アホには関係

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

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

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

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

てすてす。

>>80
世のあちこちで

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

てすと