ユニットテストをプロジェクトにゆっくりと統合するための手順
https://stackoverflow.com/questions/1017917
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
私は現在、他の1人の生協学生と完成間近のプロジェクトに取り組んでいる生協に所属しています。このプロジェクトは協同組合から協同組合に引き継がれているため、貧弱な実践が行われ、テストは最後まで残っています。テスト中に何か新しいことを学ぶために、単体テストを書きたいと思いました。
ただし、現在の形式では単体テストが不可能と思われる3層の密結合アプリで作業しています。私は、これらの概念をまったく知らずに他の生協学生を捨てて、一晩で認識を超えてコードをリファクタリングしたくありません。では、コードをユニットテスト可能性に向けてゆっくりと引き上げるには、どのような手順を踏む必要がありますか？先に進む前に、まず工場パターンを実装し、他の学生にそれを理解させる必要がありますか？
知識に欠陥があり、まったく問題がない場合は謝罪します。私はこれが初めてです：）
解決
レガシーコードを効果的に使用するマイケルフェザーズ
ファクトリパターンの実装が良い結果をもたらすかどうかを知るのは困難です。コードの実行内容に依存します：）
他のヒント
レガシーコードを効果的に使用 by Michael Feathers（Safariでも利用可能）サブスクリプションを持っている場合）は、タスクに最適なリソースです。著者はレガシーコードを単体テストなしのコードと定義し、コードをテスト対象にするためにセーフティネットなしで作業しているために必要な保守的なテクニックの多くの実践的なウォークスルーを提供します。目次：
- パート：I変化のメカニズム
- 第1章ソフトウェアの変更
- ソフトウェアを変更する4つの理由
- 危険な変更
- 第2章フィードバックの操作
- 単体テストとは
- 高レベルのテスト
- テストカバー
- レガシーコード変更アルゴリズム
- 第3章検知と分離
- 共同編集者の偽装
- 第4章Seamモデル
- 巨大なテキストシート
- 縫い目
- シームタイプ
- 第5章ツール
- 自動化されたリファクタリングツール
- モックオブジェクト
- ユニットテストハーネス
- 一般的なテストハーネス
- 第1章ソフトウェアの変更
- パート：IIソフトウェアの変更
- 第6章あまり時間がないので、変更する必要がある
- 新芽法
- スプラウトクラス
- ラップ方法
- ラップクラス
- 概要
- 第7章変更を行うには永遠に時間がかかる
- 理解
- ラグタイム
- 依存関係の破壊
- 概要
- 第8章機能を追加するにはどうすればよいですか？
- テスト駆動開発（TDD）
- 違いによるプログラミング
- 概要
- 第9章このクラスをテストハーネスにすることはできません
- 刺激的なパラメーターの場合
- 隠された依存関係のケース
- 建設ブロブの場合
- 刺激的な世界的依存の事例
- 恐ろしい依存関係が含まれる場合
- タマネギパラメータの場合
- エイリアスパラメータの場合
- 第10章テストハーネスでこのメソッドを実行できない
- 隠しメソッドの場合
- 「役に立つ」ケース言語機能
- 検出不能な副作用のケース
- 第11章変更を加える必要があります。どのメソッドをテストする必要がありますか？
- 効果についての推論
- 今後の推論
- 効果の伝播
- 効果推論のためのツール
- 効果分析から学ぶ
- エフェクトスケッチの簡略化
- 第12章1つの領域で多くの変更を行う必要があります。関係するすべてのクラスの依存関係を解除する必要がありますか？
- 傍受ポイント
- ピンチポイントでデザインを判断する
- ピンチポイントトラップ
- 第13章変更を加える必要があるが、どのテストを書くべきかわからない
特性評価試験
- クラスの特徴付け
- ターゲットテスト
- 特性評価テストを作成するためのヒューリスティック
- 第14章図書館への依存が私を殺している
- 第15章私のアプリケーションはすべてのAPI呼び出し
- 第16章変更するほどコードを理解していない
- メモ/スケッチ
- マークアップの一覧表示
- スクラッチリファクタリング
- 未使用コードの削除
- 第17章アプリケーションに構造がありません
- システムのストーリーを伝える
- 裸のCRC
- 会話の精査
- 第18章私のテストコードは邪魔です
- クラスの命名規則
- テスト場所
- 第19章私のプロジェクトはオブジェクト指向ではありません。安全に変更するにはどうすればよいですか？
- 簡単なケース
- ハードケース
- 新しい動作の追加
- オブジェクトの向きを活用する
- 第6章あまり時間がないので、変更する必要がある
プロジェクトの途中で新しい開発プラクティスを開始することは非常に困難です。過去に私が最初からユニットテストされていないプロジェクトに取り組んだとき、取る良いアプローチは、「新しいコードはユニットテストを持たなければならない」というルールを設定することですが、ユニットテストに圧力をかけないでください古いコード用に記述されています。
もちろん、プロジェクトの構造がテスト容易性に適していない場合でも、これは困難です。
私の最善の推奨事項は、小さなステップでそれを取ることです。
テストを含まない単体テストアセンブリ（またはプロジェクトなど）を作成することから始めます。次に、かなり適切に定義および分離されたコードの単一の小さな領域を見つけて、その領域の単体テストを作成します。コードをチェックインするたびに単体テストを実行する（可能な場合は自動的に実行する）など、ココーダーに目を向けてもらい、いくつかの「ベストプラクティス」の取得を開始します。
作業が完了したら、徐々に追加を開始できます。
キーはゆっくりです。そして、私が言ったように、古いコードを最初からテストから免除する方が簡単です。チームが単体テストのアイデアを把握し、それらを書くのが上手になったら、いつでも後でそれに戻ることができます。
コードの主要な機能を対象とした一連のブラックボックステストを作成してみませんか？ ASP.NETプロジェクトであることに言及しているため、 WaitN または Selenium を使用して、Webブラウザーを自動化します。これにより、コードがいくら変化しても一定のままであるベースライン機能セットが提供されます。
プロジェクトの高レベルの機能をテストするための快適な数のテストができたら、コードに飛び込み始めます。SimonP. Stevensが述べているように、ゆっくり動作します。
