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

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

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

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

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

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

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

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

にならざるをえない。

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

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

See: Working Effectively with Legacy Code

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

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

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

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

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

そうでもないよ。


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

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

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

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

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

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

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

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

関数 {

　ここからAの処理
　　　：
　　　：

　ここからBの処理
　　　：
　　　：

　ここからCの処理
　　　：
　　　：

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

[7 デフォルトの名無しさん 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
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

そうでもないよ。


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

読めよｗ

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

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