いくつかの Q&A セッション (これとこれを参照) から理解したように、単体テストは開発者が作成する必要があります。
以前の職場では、このタスクを QA エンジニアに任せようとしましたが、うまくいきませんでした。すでにプロジェクトの途中であり、重要なコード カバレッジを行う機会がなかったためか、別の理由による可能性があります。
そのような方法で単体テストを書くことから開発者を解放するのは悪い考えだと思いますか?
10332 次
10 に答える
20
一般的に、それは悪い考えだと思います。ユニット テストは、コードが運用システムとテスト コードの両方で機能する必要があるため、開発者がモジュール式の (したがって有用で再利用可能な) コードを作成するように導きます。
于 2009-01-14T11:18:40.417 に答える
16
単体テストと QA テストの目的には、微妙ではあるが重要な違いがあります。QA テストは機能を検証します。単体テストは設計を検証します。つまり、製品の外側のビューと内側のビューが対比されます。
QA 担当者は製品の内部設計に慣れていませんが、ユーザーの視点を模倣する必要があるため、意図的に設計されています。一方、開発者は内部の仕組みをよく知っており、設計が有意義であるかどうかを検証するメカニズムは開発者にとって重要です。
したがって、QA 担当者ではなく開発者が単体テストを作成するのは当然のことです。
于 2009-01-14T11:40:18.860 に答える
10
これは、テスト ワークフローの実装方法によって異なります。
悪い：
開発者が自分のコードを書き、他の人が単体テストを追加してこのコードをテストしようとします。ここでの問題は、開発者が簡単にテストできるコードを書きたがらないことです。単体テストをテストしにくいコードに適応させるために多くの時間を費やすか、後で元のコードをリファクタリングしてテストしやすくすることで時間を浪費する可能性があります。
良い：
開発者とは別の人が単体テストを書き、開発者はその後コードを書き、それらすべてのテストをグリーンにしようとします。テストを実装するためにいくつかの基本的なインターフェースが存在する必要があるため、最初は少しぎこちないかもしれませんが、開発者がテスト開発者のためにインターフェースを準備できるように、基本的なインターフェースは設計ドキュメントで定義する必要があります。利点は、テスト開発者が実際の実装とは無関係に考えられる限り多くのテストを作成しようとすることですが、元の開発者は他の問題を想像することなく、コードの内部に応じてテストを作成していたでしょう。そうでなければ、彼はすでに彼の実装で彼らを防いでいたでしょう.
「良い」アプローチは私のプロジェクトのうちの 2 つでうまく機能しましたが、テストを実行するためにクラス名に同意するだけでよい、型付けされていない言語 (Smalltalk) を使用しました。Java では、少なくとも関数を呼び出すためのインターフェースを実装する必要があります。
于 2009-01-14T11:32:23.917 に答える
3
開発者は単体テストを作成する必要があります。そうでなければ、開発者が品質を気にする必要がないようなものです。さらに、単体テストは、開発者がより良いコードを書くのに役立ちます。
TDDについて聞いたことがあるでしょうか。「テスト駆動開発」は、開発にとって本当に良い習慣です。その主な目的は、実際のコードを書く前に単体テストを開発することです (TDD を使い始めると、これは奇妙なことです)...
于 2009-01-14T11:23:39.050 に答える
3
はい。
開発者は、「ユニット」が想定どおりに機能することを確認するユニットテストを作成します。QA 担当者がアプリケーション全体をテストします。
また、単体テストはコードであり、開発者がコードを記述します。ほとんどの場合、QA エンジニアはコードを書きません。
于 2009-01-14T11:18:12.057 に答える
1
チームに単体テスト専任の担当者がいることは、一見すると興味深いことに思えるかもしれません。彼はすべてのコードをレビューします。これにより、1 人の開発者が製品コードと単体テストで同じエラーを起こすリスクも軽減されます。
ただし、単体テストを行うには、コードがテスト可能である必要があります。受け取ったコードがテストできない場合、彼は何ができるでしょうか? 書き直しますか？それをリファクタリングしますか？単体テストなし？
要するに、これはあまり良い考えではないと思います。
于 2009-01-14T13:25:39.583 に答える
1
私が働いている場所では、全員が単体テストを行っていますが、独自のコードでは行っていません。引き続きテスト可能なコードを記述し、引き続き品質に重点を置きます。開発者は、自分が取り組んでいないソフトウェアの領域に慣れてきます。誰もがコード ベースを知っており、他の開発者から引き継ぐことができます。
ソフトウェアの非開発者が単体テストを作成するために、他のすべての回答に同意します。それは悪い考えです。
あなたの質問では、単体テストを行う人が 1 人いると言いました。優れた単体テストには、必要なテスト カバレッジに応じて多くの労力が必要です。これは、開発チームの作業量の 50% から 100% の範囲です。多くの開発者コードを 1 人でテストすると、完全に圧倒されます。
于 2009-01-14T14:34:41.053 に答える
0
私はそれが悪いことではないと思います、私はそれが可能であるとは思いません。コードが最初にテストで書かれていなかった場合、おそらくテスト可能ではありません。
QA担当者は、コードをテスト可能にするためにリファクタリングを行っていますか？
もしそうなら、それは問題ありません、そして私は彼らのタイトルが何であるかを気にしません。そうでなければ、私は彼らが成功するだろうとは思わない。
于 2009-01-14T14:45:11.313 に答える
0
QAが単体テストを書くのは一般的に悪いことだと思います。単体テストはコードであり、開発コードの構築方法と密接に関連しています。このため、開発者はどのテストが最も理にかなっているのかを最もよく知っています。
一方で、QAはユニットテストに可能な限り近づける必要があると思います。QAは開発者との良好な関係を必要とし、コード設計を理解しようとします。なんで？開発者が単体テストを作成しているとき、焦点はテストではなく開発にあります。開発者が最良のテストケースを考え出し、彼女が優れたカバレッジを持っていることを（悪い意味ではなく）信頼することはできません。QAはテストに特化しているため、単体テスト中はQAと開発を可能な限り近づけることをお勧めします。
于 2009-05-15T15:56:33.350 に答える
0
開発者または仲間の開発者 (コード レビュー担当者) は、開発されたコードまたは技術設計に基づいたユニット テスト ケースを文書化する必要があります。ただし、QA テスト ケースは、機能設計に基づく機能テスターによって作成される必要があります。
ここでの根本的な違いは、UT がロジック、内部フロー、パフォーマンス、最適化をカバーしているのに対し、QA はユーザー エクスペリエンスを模倣する機能フローをカバーしていることです。
于 2014-07-07T11:04:59.570 に答える