プログラマーに単体テストを要求する必要がありますか？[閉まっている]

私は多くのITプロジェクトを購入する場所で働いています。私たちは現在、将来のプロジェクトの要求のためのシステム要件の標準を作成しています。そのプロセスでは、サプライヤーに自動化された単体テストを要求できるかどうかを議論しています。

適切な自動化された単体テストが、コードの品質と安定性を文書化する唯一の方法であると確信しています。他の誰もが、単体テストはサプライヤだけに関係するオプションの方法であると考えているようです。したがって、自動化された単体テスト、継続テスト、カバレッジレポート、単体テストの検査などは一切必要ありません。このポリシーは非常にイライラします。

私はここで完全に列から外れていますか？

意見のいずれかの議論を提供してください。

適切な自動化された単体テストが、コードの品質と安定性を文書化する唯一の方法であると確信しています。

問題は、人々にそれを強制することによって適切な自動化された単体テストを取得しないことです（少なくとも非常にまれです）。それはくだらないテストを取得し、プロジェクトのコストを引き上げるのに良い方法です。

個人的には、品質に関係する何らかの需要またはSLAに注目します。達成方法に関係なく。10年前は、単体テストはせいぜいまれでした。品質を確保するためのより良い方法がありますが、古いポリシーでは古い方法を使用する必要がある場合、10年後にサプライヤーに手錠をかけたくありません。

個人的には、代わりに受け入れテストの観点から考えるべきだと思います：

• ブラックボックスが与えられ、特定の方法で動作することを期待しています。
• 支払うまで支払いはしません。
• 必要な動作を実行する単体テストを作成し、失敗した場合は修正する必要があります。

また、これは信頼の問題であることに注意してください。サプライヤを信頼していない場合は、ソースコードを入手して検査し、自分でコンパイルする必要があります。それ未満のことは、少なくともそれらをある程度信用していることを意味します。

適切な自動化された単体テストが、コードの品質と安定性を文書化する唯一の方法であると確信しています。

この考え方がどれほど一般的であるか、私は驚きました。はい、自動化されています。単体テスト（単独）、いいえ。自動化されたソフトウェアテストには、単体テストよりも多くの方法があります。統合、システム、機能、QAはどうですか？いくつかの理由で、人々は「OK、それで適切な単体テストがあります。テストを済ませて、金曜日の夜と呼んでください！」と考える傾向があります。。単体テストはほんの始まりに過ぎません。

とにかく、トピックに戻って。私は、誰かに何かを強要すると、おそらく望まれる結果とは反対の結果をもたらすと言っていることに同意します。チームがどのように機能するかを知らない、多分彼らは100万ドルの価値のあるテスト部門を得て、単一のユニットテストを書いたことがありません。

私の最初の仕事では、ユニットテストがゼロの場所で働いていました（多かれ少なかれ深刻なものを投げるジュニアの集まりでした）。信じられないかもしれませんが、うまくいきました。確かに、誰も打ち明けなかった理由は、このバグが修正しまった、または何この修正は壊れたが、それが働きました。絶対にランダムなバグが発生することがありましたが、野球のバットとあなたのアパートが焼けてしまうリスクいくつかの余分な時間が驚くほど働くことができます。サプライヤも同様の手法を使用しているのでしょうか？

あなたの経営陣が契約の適切な単体テストに対して喜んで支払いをすることを非常に疑います。適切な単体テストは、テストするコードと同じくらいの費用がかかりますが、エンドユーザーに認識される価値はほとんどないため、同等に価値があると見なされることはありません。質の高い開発会社は、他の部分よりも低コストで単体テストに開発努力を費やすつもりはありません。ユニットテスト要件。

要求の厳しい単体テストは、受け取った見積もりを不合理なレベルに引き上げる可能性が高く、低価格を得るための最初の譲歩になる可能性があります。

単体テストを行わない場合のコストは、自分でコードを拡張/サポートする量によって異なります。コードの一部を調べて品質の概念を把握することも重要です。

サードパーティのライブラリのように使用できるようにプロジェクトを購入するだけで、それらを変更すると思わない場合、実際に機能する限り、低品質のコードのリスクは低くなります。

これらは最終的にはビジネス上の決定ですが、決定を下す人はだれでも技術的評価を認識していることを確認する必要があります。経営者に説明する必要がある場合、それは中古車を買うようなものです。最終的には価値があるかどうかを判断するのは買い手次第ですが、レモンを手に入れないことを知っているので、整備士に持って行くことをお勧めします。

あなたは支払いをしています、あなたは彼らのすべてのユニットテストのコピー/レポートを含む、あなたが望むものを要求することができます。

テストを書くこともできますし、少なくともテスト仕様自体を書くこともできます。

コード品質の非常に良い尺度であるという点であなたの意見に同意します。サプライヤがこの要求を拒否した場合、警告音が鳴ります。なぜそれをしたくないのでしょうか。品質基準が低く、近道を取っていますか？

プロジェクトで自動化された単体テスト、継続テスト、カバレッジレポート、単体テストの検査が必要であることは間違いありません。

しかし、他の人が詳細に述べているように、要求の厳しいものはあなたが望む結果を達成しません。

あなたの課題は、人々を説明し、説得することです-もっと難しいスキルです！

最初は管理から始め、テストの長所と短所、そして将来の成果について説明します。「私は適切なユニットテストを書いています」（資本化あなたのもの）のようなステートメントの背後にある感情を伝えないように注意してください。（すべての大文字が意味するように）言葉を「大声で叫ぶ」ことは望ましくありません。人々が自分自身で正しい解決策を選択できるように説得し、説得します。

究極的には、これらの方法論を導入して、自分がどこにいるのかを受け入れられない場合、さらに、あなたが述べているのと同じくらい情熱的であれば（これは良いことです！）機内でお迎えいたします。面接で彼らについて前もって確かめてください。そうすれば、彼らはあなたの情熱がどこにあるのか、そしてあなたがぴったりなのかどうかを知ることができます。

@Joachim Sauerと@Telastynがコメントで指摘したように、自動テストを誰かに強制しても、希望する結果は得られません。多くの人にとって、自動化された単体テストは考え方の大きな変化です。多くの人が機能するコードを書いていますが、あまりテスト可能ではありません。データベース、ビジネスルール、オブジェクトなどを照会するすべてのロジックがコードビハインドにあるASP.NET Webページを作成できます。ページは機能しますか？はい。自動化された単体テストを使用してテストできますか？絶対違う。サプライヤーが自動化された単体テストを持っていない場合、単体テストを適切に作成する方法を学習し、これを学習した結果、コードを再作成またはリファクタリングしてより簡単にテストできるようにするためにかなりの努力が必要になります。彼らはその費用をあなたに転嫁するでしょう。

問題は、サプライヤが製品を提供していることです。それが.dllであろうと、Windowsアプリケーションであろうと、99％の確率で機能すると期待しています。確かにあちこちにバグがありますが、大部分は動作するはずです。特にサプライヤーがあなたのビジネスを維持したい場合、それは合理的な期待です。ブラックボックスの場合、どのように機能させるかは問題ではありません。テスターの人間の波を使用することも、キーをランダムに押す猿の部屋を使用することもできます。それが機能する限り。しかし、彼らはそれを使用する方法に関する何らかの他のドキュメントを提供する必要があります。

ただし、ソースコードを提供して修正できる場合は、単体テストが期待されます。単体テストを提供していない会社とは働きません。あなたが行った変更がすべてを損なうことを他にどのように知っていますか？

単体テストは、サプライヤが開発サイクル中にどのようにリスクを処理するかの指標です。単体テストを使用する人はリスクを軽減し、それらのテストの質はリスクがどれだけ管理されているかを示します。

そうは言っても、単体テストでは、プロジェクトが取り組もうとするリスクのレベルを定義しません。また、不適切なプログラミング手法によってもたらされるリスクの低減においても役割を果たしません。

したがって、堅実なテストを実施しているが非常にリスクの高いコードを書き続けるサプライヤと、テストを行わないが低リスクのコードを書くサプライヤがいる可能性があります。2つのサプライヤが同じ製品を提供する場合は、リスクの低いサプライヤに行くのが最善です。

これは、そのサプライヤに関係する人々の個性とスキルについてインタビュー、指導、学習することによってのみ評価できます。

カスタムソフトウェアの購入に関するこの記事は非常に便利です。http：//blog.8thlight.com/paul-pagel/2012/06/20/entrepreneurs-guide-to-buying-software.html

彼らが尋ねるべき一番の質問は、サプライヤーがテストを書くかどうかです。

ユニットテストを要求する他の人に同意することは、テストのためにテストにつながるでしょう。あなたが望むものに非常に反するもの。

サプライヤーを審査する過程で; テストはそのプロセスの一部にすぎないため、開発プロセスを教えてください。

彼らは自動化されたビルドプロセスを持っていますか？彼らはいくつかの管理パラダイムに従っていますか？彼らは適切に訓練されたテスターと独立した品質保証チームを持っていますか？ドキュメントの標準はどうですか？

これらはプロセスの全体的な品質を判断するのに役立ち、順番にそれらが生成するものの品質を判断するのに役立ちます。

強制することは不可能であるため、この要件を含めることは実際的なメリットがほとんどないと思われます。

実際のテスト用のコード、または実際に実行されて合格したテストのレポートを要求できます。独自のプロジェクトである場合、ベンダーはおそらくそれを提供したくないでしょう。なぜなら、コードの詳細を非常に示唆している可能性が高く、低レベルの実装の詳細を提供し、その方法ジョブ。ある時点で、ある程度の信頼が必要です。

そうでない場合、彼らはあなたを吹き飛ばすことができますが、ユーティリティがコンパイルされて実行されるか、または同様の半分の努力。

そのため、自動化された単体テストは称賛に値するプラクティスですが、外部ベンダーからそれを主張することは実用的ではないと思います。

多くの人々が指摘しているように、契約を履行するためにベンダーに単体テスト（または、より優れた自動化された単体テストと統合テストの組み合わせ）の作成を強制しても、おそらく高品質の結果は得られません。一方、コードの品質を保証するために現在使用されている最良の方法は自動テストであることに同意します。

ユニットテストで書かれたコードは、最初に書かれて後でユニットテストが追加されたコードよりも保守がずっと簡単だと思います。モジュール性と最小限の依存関係を強制します。 統合テストは、コードの正確さを検証するためにも必要ですが、コードの品質に書かれているのと同じ影響はありません。本質的には、自動化された統合テストを事後に追加することができますが、元のコードで記述した場合、ユニットテストが最も大きな影響を及ぼします。

あなたの状況に対する私のアドバイスは、単体テストでコードを書くことを好むベンダーを探し、単体テストでコードを書かない傾向があるベンダーよりもそれらを選ぶことです。経営陣がそれを支払う場合、自動テストを契約に入れますが、ベンダーがユニットテストでコードを記述するために使用される場合のみです。

優先順位をまっすぐに取得しましょう...

顧客としてのあなたの役割における主な関心事は、単体テストではありません

あなたのためにソフトウェアを生産するサプライヤを使用している場合、彼らが何らかの方法論を使用しているかどうかを本当に心配するべきではありません。目標は、目標を達成するのに役立つ何らかのソリューションを取得することです。唯一気にする必要があるのは、その解決策が受け入れられるかどうかです。それが、あなたが望むものを手に入れることを確認するあなたの責任にあるので、受け入れテストがある理由です。お金があなたの会社のポケットからサプライヤーのポケットに送られることは、顧客の受け入れの重要な瞬間です。

成果物の要件として単体テストを要求することもできますが、それらにはいくつかの継承問題があります。最も深刻なのは、メトリックを事前に決定する確実な方法がないことです。

• 単体テストの許容量はいくらですか？

10回のテストが必要ですか？100個のテストはどうですか？1000個のテストはどうですか？実際、必要なテストの数を最初に判断することは非常に困難です。実際の数は、実際には不確定です...停止する問題のように...しかし、我々はその問題を解決していません。

開発を継続できるように、単体テストを備えたソフトウェアが必要です。単体テストでは、まだ何が壊れているかはわかりませんが、コードにリグレッションバグがある場合に伝えるのに非常に適しています。

• コードカバレッジの許容レベルとは何ですか？

「もちろん、100％！」あなたは思うだろう。残念ながら、そのメトリックは誤解を招くものです。コードカバレッジが100％であっても、期待どおりに機能していると確信していますか？カバレッジを100％にすることは可能ですが、実行しないでください。

本当に必要なのは探索的テストです。つまり、物を壊すのが本当に上手な人を見つけて、テストをさせます。開発者が考えもしなかったバグを見つけるため。

また、必要なパフォーマンスハックがあり、テストが難しいデザインパターンを使用している場合、純粋な単体テストでは100％を達成できない場合があります（お気に入りの検索エンジンで「シングルトン」と「tdd」を検索すると、いくつかの例が見つかります）。

提供されたソフトウェアが機能することを望み、仕様書はそれが機能する唯一の保証です。

より高いレベルのテストが必要になります

仕様書は何らかの方法で検証する必要があります。サプライヤーは明確な目標と受け入れ基準を持って、各ポイントを通過する必要があります。適切に機能するQA組織（または予算が限られている場合は素晴らしいテスター）が、これらの受け入れ基準を確認するためのテストケースを提供します。また、それらの受け入れ基準を検証する誰かが必要です。

目標を検証する方法はいくつかありますが、品質、性能、効率の目標を設定できないと誰かが教えてくれた場合、探索、性能、ユーザビリティのテストに関する大きな本と重い本で頭を打ちます。目標を達成するのは簡単ですが、知識とコミュニケーションは現実的な目標の設定に役立ちます。

私は弁護士ではありませんが、ほとんどのプロジェクト契約（これは基本的にプロジェクトのすべての仕様の母です）私が読んだことは通常、許容できると見なされるバグの数を規定する欠陥率の基準を持っています。バグは通常、重大度によって決定され、QAによって検出されたショー停止バグは許容度が低く、小さな傷は許容度が高くなります。実際のプロジェクトでは、ソフトウェアに欠陥がないことを要求することは困難です。締め切りは通常、その慣行を停止します。これらの状況で、スコープの交渉を開始する必要があります。

私が見たほとんどの付属ソフトウェアは、通常、単体テストでは提供されていません。サプライヤはこれを提供するのに十分な専門家である必要があると主張することができますが、ユニットテストを提供する主な理由は、リグレッションバグが発生しないこととリファクタリングを有効にすることです。締め切りの厳しいプロジェクトでは、サプライヤと顧客の両方が範囲を縮小し、ユニットテストは通常​​、窓から出て必要な成果物のリストから削除されます。

注目度の高いオープンソースソフトウェアが単体テストで提供されるのは少し悲しいですが、プロのソフトウェア開発者はそうではありませんよね？

それで、私はいつ顧客として単体テストに関心を持ちますか？

ユニットテストを本当に気にするのは、成果物ソフトウェアがスタンドアロンプ​​ログラムとして実行されない自給自足のコンポーネントである場合だけであると主張します。。クラスライブラリは、単体テストと一緒に提供できる製品の一種です。

ベンダーが単体テストを書いていないことをどのように知っていますか。

管理者とベンダーが会議を開いて、コードの費用がXドル、ユニットテストの費用がYであるとベンダーが言ったのかもしれません。ペニー・ピンチング・マネジメントは、ただコードが欲しいと言った。

ベンダーは（品質のため）とにかく単体テストを書くことにしました（競争上の優位性のため）。

ここで、ソフトウェアを大幅に調整する必要があります。コードを所有しているので、自分でコードを作成することも、競争力のある形で雇うこともできます（必ずしも元のベンダーとは限りません）。ただし、単体テストを購入しなかったため、元のベンダーは競合他社に比べて安価で同等の品質の作業を行うことができます。

ユニットテストを使用しないという事実にもかかわらず、非常に成功しているプロジェクトがたくさんあります。linuxカーネルを見てください。これは、通常のプロジェクトに見られるものをはるかに超える複雑さを備えた巨大なプロジェクトであり、引き続き機能します。したがって、結果が優れたソフトウェアである場合、彼らがそれをどのように達成したかを気にする必要はありません。

いいえ、必ずしも完全で自動化されたテストユニットを要求する必要はありません。より重要なのは、適切なテスト戦略文書を提供することです。この方法でうまくやっています。