何も存在しない場合、単体テストを正常に統合するにはどうすればよいですか？

Question

私は、当社の内部テストの標準と手順のためのドキュメントを開発することを任されています。私はたくさんの調査をして、良い記事を見つけましたが、私はいつもここで情報を得るためにコミュニティに連絡したいと思います。

私の質問はこうです：どのようにテスト可能であれば、ほとんどテスト可能な非常に大きなレガシーコードベースを持つ企業をどのように雇用し、効率的にテストできるか試してみてください。あなたは密接に結合されたコードのためのいくつかの便利な自動化されたテストケースを作成する方法に関するヒントを持っていますか？

私たちの新しいコードはすべて、できるだけ疎結合して書かれており、私たちは新しい開発の方向性を非常に誇りに思っています。記録のために、私たちはMicrosoftからVisual Studioへの移行を行っています。

Answer 1

実際には、この質問には技術的、政治的という2つの側面があります。

技術的なアプローチは、Michael Feathersの書籍Working Effectively With Legacy Codeでかなりよく定義されています。コード全体を一度にテストすることはできないので、架空の非建築的な「縫い目」に沿って分解します。これらは、コード内の論理的な問題点であり、コードブロックの残りの部分とは幾分隔離されているように見えます。これは、必ずしもそれを分割する "最良の"アーキテクチャ上の場所ではありません。それは、単独でテストできる独立した論理ブロックを選択することです。この時点で2つのモジュール、つまりコードの大部分と独立した関数に分割します。今度は、その時点で自動テストを追加して、分離された機能を実行します。これにより、ロジックに対する変更がコードの大部分に悪影響を及ぼすことはないことが証明されます。

SOLID OOの設計原則、DRY原則などを踏襲して、分離されたロジックを町やリファクタリングすることができます。Martin Fowler's Refactoring本は優れた参考資料です。リファクタリング時に、新たにリファクタされたクラスとメソッドに単体テストを追加します。あなたが作成した分割で描いた「裏のまま」にとどまります。互換性の問題を防ぐのに役立ちます。

最終的には、完全にユニットテストされたロジックの構造化されたセットが最適です。これは一時的な互換レイヤーにアタッチされ、以前にカットしたシームまでフックします。ロジックの他の独立したセクションについても、このプロセスを繰り返します。次に、それらを結合し始め、一時的なレイヤーを破棄することができます。最後に、美しいコードベースで終わるでしょう。

これには長い時間がかかります。そして政治に入る。マネージャーにコードベースを改善することで、より良い/安価な/より速く変更できるようになると説得しても、その視点はおそらく上の幹部によって共有されません。経営陣が見ていることは、リファクタリングに費やされる時間が、要求された機能の追加に費やされない時間であるということです。そして、彼らは間違っているわけではありません：あなたと私が必要なメンテナンスとみなすかもしれないものは、限られた予算を費やしたい場所ではありません。彼らの心の中で、今日のコードは、たとえそれが高価であってもうまく動作します。言い換えれば、彼らは「それが壊れていなければ、それを修正しないでください」と考えています。

リファクタリングされたコードベースにアクセスする計画を提示する必要があります。これには、アプローチ、関連するステップ、見ている仕事の大きな塊、予定されたタイムラインが含まれます。また、ここに代替案を提示するのも良いです：あなたは完全な書き直しによってより良く役立つでしょうか？言語を変更する必要がありますか？サービス指向アーキテクチャーに移行する必要がありますか？あなたはそれを雲の中に移動し、それをホストされたサービスとして販売する必要がありますか？これらはすべて、今日彼らについて考えていなくても、彼らがトップで検討すべき質問です。

最終的に同意する場合は、ツールをアップグレードし、ピアコードレビューや自動ユニットテストの実行、パッケージング、QAへの展開などのプラクティスを含む最新の開発チェーンをセットアップする時間を無駄にしないでください。

11年間この木を個人的に樹立してしまったので、私はそれが信じられないほど簡単でないことを保証することができます。 CIO、CTO、開発のSVP、または誰でも、組織内のハイテクラダーの最上部で変更を行う必要があります。また、技術的な仲間にも納得させる必要があります。古い製品に長い歴史を持ち、実際に変更したくない人がいるかもしれません。彼らはコーダーとしての自分のスキルに対する個人的な攻撃としてのあなたの現在の状態についてのあなたの不平を見るかもしれませんし、あなたの努力を妨害したり、砂場に捨てるかもしれません。

私は心からあなたのベンチャーに幸運を祈ります。