最近、RailsConf 2014の「All the Little Things」を視聴しました。この講演中に、Sandi Metzは、ネストされた大きなifステートメントを含む関数をリファクタリングします。
def tick
if @name != 'Aged Brie' && @name != 'Backstage passes to a TAFKAL80ETC concert'
if @quality > 0
if @name != 'Sulfuras, Hand of Ragnaros'
@quality -= 1
end
end
else
...
end
...
end
最初のステップは、関数をいくつかの小さなものに分割することです：
def tick
case name
when 'Aged Brie'
return brie_tick
...
end
end
def brie_tick
@days_remaining -= 1
return if quality >= 50
@quality += 1
@quality += 1 if @days_remaining <= 0
end
私が興味深いと思ったのは、これらの小さな関数の書き方でした。brie_tickたとえば、は元のtick関数の関連部分を抽出して作成されたのではなく、test_brie_*単体テストを参照して最初から作成されました。これらの単体テストのすべてに合格すると、brie_tick完了したと見なされました。小さな機能がすべて完了すると、元のモノリシックtick機能は削除されました。
残念ながら、プレゼンターは、このアプローチが4つの*_tick機能のうち3つが間違っていた（そしてもう1つは空だった）ことに気づいていないように見えました。*_tick関数の動作が元の関数の動作と異なる場合がありtickます。たとえば、@days_remaining <= 0in brie_tickは< 0- であるべきです- およびでbrie_tick呼び出された場合、正しく動作しません 。days_remaining == 1quality < 50
ここで何が問題になっていますか？これはテストの失敗ですか？これらの特定のエッジケースのテストがなかったためですか？または、リファクタリングの失敗-コードを最初から書き直すのではなく、段階的に変換する必要があったためですか？
2
質問を受けるかどうかはわかりません。もちろんコードを書き直しても大丈夫です。「コードを単純に書き直しても大丈夫ですか」という具体的な意味がわかりません。「多くのことを考えずにコードを書き直しても大丈夫ですか」と尋ねるなら、答えはノーです。その方法でコードを書くのは良くないのと同じです。
—
John Wu
これは主に、主に成功のユースケースのテストに焦点を当てたテスト計画と、エラーのユースケースまたはサブユースケースのカバーがほとんど（またはまったくない）ために発生します。したがって、それは主にカバレッジの漏洩です。テストのリーク。
—
Laiv
@JohnWu-私はリファクタリングが一般的にソースコードへの一連の小さな変換（ "extract-method"など）として単にコードを書き換えるのではなく（つまり、一から書き直すことなく）リンクされたプレゼンテーションで行われたように、既存のコードを調べます）。
—
user200783 2018年
@JohnWu-ゼロからの書き換えは許容可能なリファクタリング手法ですか？そうでなければ、リファクタリングに関するそのような評判の良いプレゼンテーションがそのアプローチを取るのを見るのは残念です。OTOHが許容できる場合、意図しない動作の変化は欠落しているテストのせいにすることができますが、テストがすべての可能なエッジケースをカバーしていることを確信する方法はありますか？
—
user200783 2018年
@ User200783それはもっと大きな質問ですね（実際にテストが包括的であることを確認するにはどうすればよいですか？）演習を行い、開発チームがロジックを書き換えるときに、それらを意識するようにします。
—
John Wu