私の会社でユニットテストに関する 10 分間の Grok トークを行う予定です。私自身もやってみましたが、確かに会社に利益をもたらすことができると感じています。専任の QA チームで既に WebInject テストを行っていますが、単体テストを開発者に販売したいと考えています。
では、たった 10 分間で何をカバーしますか? またその理由は?
- 私たちは Microsoft Shop C# Web Apps です。経験上、NUnit を使用しました。
15 に答える
15
単体テストは信頼がすべてです。
これにより、自分のコードが堅固であり、他の人がシステムの独自の部分を作成する際に信頼できることを確信できます。単体テストが新しいシステムの最初のリリースに伴う不安を取り除くのに役立つことを理解できれば、聴衆がすぐに非常に興味を持ってくれることを願っています.
于 2009-02-04T13:14:26.187 に答える
8
多くのプログラマーがよく知っているかもしれない問題から始めたいと思います。それは、既存のコードを変更することへの恐怖です。それは、何かを壊してしまうのではないかという恐怖からです。それがどのように作業の発生を妨げたり、適切に行われたりするのを妨げたり (リファクタリングを恐れているため)、x 年ごとにすべてを書き直さなければならないことになります。
単体テスト -> リファクタリング -> リビング コード。
編集： ところで、私は「ユニットテストのないすべてのコードはレガシーコードです」というMichael Feathers からの引用をリードしません。初めて聞いたときは確かに防御的に感じました。人々が屈辱を感じなくなるまでに、10分は終わります:-) (個人的には、引用は役立つというよりも真実だと思います)。
于 2009-02-04T13:27:40.463 に答える
4
以下は、テクニック X に関する簡単な説明に適した形式です。
- なぜそれをしようと思ったのか X そもそも
- X を使用して個人的に得たもの
- あなたが気づいた制限、Xが対処していないこと
理論を売り込んだり、多くの時間を割いたりしないでください。事前に準備し、最も役立つと思われる本、記事の URL、またはチュートリアルを人々に紹介してください。講演後に興味のある方はWebで詳細を調べてください。
于 2009-02-04T13:19:05.177 に答える
3
テスト駆動開発の側面について簡単に説明してみてください。最初にテストを書き、インターフェイスを作成し、次にすべてを実装します。
おそらく継続的インテグレーションについて言えば、これは、ソース管理システムに何かをチェックインするとすぐに、プロジェクトがコンパイルされ、すべてのテストが実行されるため、開発者は何か間違ったことをしたかどうかをすぐに知ることができることを意味します。
聴衆の中にプロジェクト マネージャーがいる場合は、ユニット テストを行うとプロジェクトに 15 ～ 30% の時間がかかることを公平に伝えてください。
于 2009-02-04T13:15:38.443 に答える
2
学習曲線が難しく、生産性に影響を与えているように感じるかもしれませんが、メリットはそれだけの価値があります。
たとえば、自動化されたリグレッション テスト スイートを効果的に作成することで、既存の機能を壊すことを心配することなく、既存のものにさらに大きな追加や変更を加えることができます。
本番コードの作成は遅くなりますが、これはコードの品質の向上、つまりバグの減少によって相殺され、長期的には全体的な生産性が向上します。
于 2009-02-04T13:22:25.670 に答える
1
ユニットテストで時間を節約する方法の簡単な例を示すには、10分で十分だと思います。
クラスを実装し（必要に応じてTDDを実行できます）、単体テストでクラスを壊す変更をキャッチする方法を示します。
また、個別にテストする場合（つまり、Webアプリケーションを起動してログインし、機能に移動してテストする必要がない場合）、コンポーネントの開発を高速化する方法を強調できます。テストを実行するだけです。
あなたはあなたの会社からのコードの一部でこれを実行することができるかもしれません-そしておそらくユニットテストがあなたが最近持っていたバグをどのように見つけたかを示すかもしれません。
于 2009-02-04T13:47:15.947 に答える
1
神への愛のために、ユニットテストはロジックの「ユニット」をテストするためのものであることを強調してください。誰も維持する必要があるとは思わなかった NUnit テストの QA スイートを見るのは嫌いです。各「単体テスト」は、150 個の (バイナリ) 入力ファイルの有効な出力をテストし、1 つが失敗すると、どれがどれであるかを通知せずに失敗します。
于 2009-02-04T15:04:43.967 に答える
1
私はデモンストレーションします：
- 生成するコードに与える信頼
- 単体テストに合格するため、コードを変更したときに得られる信頼
- コード カバレッジの利点は、もはや「ああ、else ステートメントはテストされていない!」ということではありません。
- Hudson などの CI プラットフォームでビルドごとに単体テストを実行する利点
FWIW HudsonボックスでMSTESTを介して安っぽいビジュアルスタジオテストを実行し、Hudsonが結果をnunit形式に変換するために使用するxsltを取得して、Hudsonがそれらを解読できるようにしました。Microsoft のテスト プラットフォームに固執してほしい場合に備えて、それを公開するだけです。
于 2009-02-04T15:11:50.707 に答える
1
Kent Beck が強調しているように、説明責任は、単体テストによって促進されるもう 1 つの特性です。IT Conversationsで彼のポッドキャストを聞いてください。(説明責任に関する彼の指摘は 30:34 から始まります。)
于 2009-02-04T13:31:22.313 に答える
1
デモンストレーションを行う場合は、誰もがよく知っているプロジェクトの実際のコードで行います。人為的な例は避けてください。TDD に関する本はすでにそれらでいっぱいであり、TDD が実際のプロジェクトでどのように機能するかを実際に売り込んでいるわけではありません。
于 2009-02-04T13:59:11.710 に答える
0
フォローアップ/自主学習のための優れたリソースセットを用意します。
- java / c＃の実用的な単体テストは、このテーマに関する優れた本です。
- ユニットテストに関するケントベックペーパー
- 選択したテストフレームワークを使用した、より大きなサンプルへのリンク
于 2009-02-04T15:27:40.253 に答える
0
このTシャツを着てください;-)
于 2009-02-04T14:06:09.247 に答える
0
ビジネスの観点から、単体テストがコードに加えた変更の「リスクを軽減」できるという事実を強調したい場合があります。一連の単体テストを作成したら、コード ベースに変更を加えて、何が壊れていて何が壊れていないかを知ることができます。
ユーザーテストを行うのは悪い考えではないかもしれません。適切なテスト セットがある場合は、変更を加えた後で失敗したテストをユーザーに提供して、新しい結果が正しいことを検証してもらうことができます。さらに、ユーザーに新しい単体テスト定義を作成してもらうと、要件の収集を合理化できます。コーディングできる必要はありませんが、適切な入力と期待される出力を提供できる必要があります (そうでなければ、要求した変更が機能しているかどうかをどのように知ることができるでしょうか?)。
Visual Studio には単体テスト用の非常に優れたツール セットが用意されているため、例を 1 つか 2 つ使用すると、単体テストが実際にどのようなものかをグループに理解してもらうことができます。
于 2009-02-04T13:24:22.577 に答える