testing - 失敗できないテストを検出する自動化された方法、最小コードカバレッジを取得するためにチェックインしましたか？

Question

私には開発者がいて、失敗することのないテストを作成することでコードカバレッジを回避します。

コードはひどいものですが、テストはassert（true）であるため、それをキャッチすることはありません。

私はレビューをコーディングしていますが、常に全員が彼らのために働くことはできません。このような人々に、どのようにして優れたソフトウェアを作成する動機を与えるのですか？

失敗できないテストを検出するためのビルドプラグインはありますか？

C＃、mbUnitテスト。

score 3 · Accepted Answer

本当のモチベーションは内側から生まれます。一部の人々は、できること以外の理由もなく、時々得られるチャンスがあるたびにシステムをゲームします。他の人は、ハックだからという理由だけでそれを行います。

そうは言っても、あなたがマネージャーであると仮定して、開発者と「イエスに来て」ミーティングをしてください。それでもうまくいかない場合は、常にドアがあります。

あなたが管理者でない場合は、適切なチャンネルで取り上げてください。

score 1 · Accepted Answer

私はあなたがそこで質問にほとんど答えたと思います。誰かがあなたのために、またはあなたと一緒に働いている場合 (あなたがこの開発者のマネージャーであるかどうかは明確ではありません)、彼らが適切に仕事をしていない場合は、この人に彼らが許容できる水準の作品を制作していません。

開発者は TDD を初めて使用しますか? 良いテストを書くための授業料が必要かもしれません。さもなければ、彼らはお尻を蹴って、テストが彼/彼女が作成しているコードよりも重要ではないかのように強調する必要があります。

そうそう、プラグインのことは忘れてください。今行っているのと同じコードレビューで十分です。

score 0 · Accepted Answer

使用している言語/フレームワークを実際に指定する必要があります。

最も単純なケースでは、単純な-pingassert(true)で文字列を簡単に検出できるはずです。grep

score 0 · Accepted Answer

すでにテストに感染している 2 人以上の開発者によるコードレビューは、問題の開発者に、自動化された単体テストが実際にはそれほど難しくも珍しいものでもないことを確認させるためのおそらく最良の方法です。各レビューに 2 人のテスト感染開発者がいるということは、彼にとって品質の高い単体テストの重要性を強調することになります。また、十分にテストされた他の開発者のコードのレビューを彼に割り当てることは、単体テストの方法を学ぶのに役立ちます。

弱いテストを検出するために、いくつかの突然変異テストを行うことを検討する必要があります。Nester ( Jesterに相当する .Net ) は、便利なツールの 1 つです。

行き方を教えてください！

更新: 「なぜほとんどの開発者はまだ単体テストを作成しないのですか?」ここも読んでみるといいと思いました。

score 0 · Accepted Answer

失敗しないテストを探すことに時間を費やす代わりに、テストを少し拡張して、コードをさまざまな方法で失敗させてみませんか。それは

より良いテストの書き方を彼に教えてください
彼に自分のコードを修正するように強制し、より悪いコードがチェックインされるのを防ぎます

使用しなければならないバグのあるコードは、良い出発点になります。それが機能することを確認する必要があります...

score 0 · Accepted Answer

アプリケーション構成値のガベージを使用して、いつでもテスト実行を試すことができます。

合格したテストは疑わしいですか？

score 0 · Accepted Answer

彼がテストしているインターフェースを最も単純な形に縮小します。つまり、クラス/メソッドのシグネチャを取得し、それ以上のコンパイルに必要なコードのみを追加します。それに対して彼のテストを実行します。プログラムが何もしないのに、なぜ彼のテストが成功するのかを彼に尋ねてください。

score 0 · Accepted Answer

まず、失敗するテストを彼に書かせる必要があると思います。彼にその習慣を身につけさせるようにしてください。多くの場合、単体テストに不慣れな人は、それらを書くのに苦労します。

また、「考えられるすべてのコードパスを調べる」のに役立つツールもいくつかあります。自動テストを生成するPEXを検討することをお勧めします。これにより、彼のコードが壊れる可能性が高くなります...これは最適なソリューションではないかもしれませんが、共有コードベースの概念を促進してみてください。

開発者にプログラムをペアリングしてもらいます。同じ関数で他の誰かと作業しているときに「怠惰」になるのははるかに難しく、コードの所有権が広がります。「彼の」コードについて話しているので、あなたはこれをしていないようです。同じ仕事に2人で取り組んでいると、どれだけ多くのことを成し遂げることができるかということに驚くかもしれません.

また、単体テストは、すべての問題を根絶するための聖杯ではありません...それらは、自由に使えるツールの1つである必要があります。

コードカバーの要件は何ですか?

testing - 失敗できないテストを検出する自動化された方法、最小コードカバレッジを取得するためにチェックインしましたか？

8 に答える 8

Related

Reference