2

私たちのプロジェクトの単体テストの実装に関する提案の中で、私のマネージャーは、2セットのコードを維持するため、単体テストを作成する方が費用がかかる可能性があると主張しました。彼の主張は、要件/機能に変更があると、単体テストが廃止される可能性があるため、開発者は自動ビルドに合格するためにテストを更新する必要があるというものです。彼は、開発者のコ​​ーディング時間が短縮され、テストの修正に費やされる可能性があるため、開発者にとって不便になる可能性があると述べました。

単体テストを実装したかった理由は、コードが機能テストのために検証チームに渡される前に、バグの発生、特に重要なバグの発生を最小限に抑えるためです。また、システムの品質を向上させることで、単体テストの作成コストを回収できると思います。

現在、私にとっての彼の課題は、変更が容易な保守しやすいテスト、または可能であれば簡単に壊れないテストを作成することです。テストを支援するために、JUnitなどのxUnitテストフレームワークと、mockitoやpowermockなどのモックフレームワークを使用しています。

保守しやすいテストを作成する方法や、脆弱なテストを回避する方法に関するヒントとテクニックを探しています。そのようなテストを作成するのに役立つ他のツールはありますか？私はJavaとC++でコードを書いています。ありがとう。

4

5 に答える 5

4

あなたは文化の違いに直面していると思います-あなたのマネージャーは、テストが提供する潜在的なタイムシンクを恐れています。TDD / BDDプロセスは前もって費用がかかることは既知の事実ですが、時間が経つにつれて、「この1つの孤立したものだけを変更する...」として報酬を獲得し始めます。コストのかかるバグ。

私の提案は、いくつかの調査を行い、プロセスをマネージャーに売り込もうとするドキュメントをまとめ、堅実なテストスイートで解決できた/解決したであろうビジネスですでに起こったことに基づいてビジネスケースを提示することです。

私が今まで見たどのウェブサイトや記事などよりもTDDにうまく入る本が1冊あります。TDD / BDD / OOPを練習したい人のために読むことを強くお勧めします： http ：//www.growing-object-Oriented-software.com/ （これをリンクしてもお金は稼げません！-しかしそれは私の机への素晴らしい追加です！）。

于 2012-08-22T08:58:02.023 に答える
2

私の経験から、「ユニットテスト懐疑論者」を本当に説得することはほとんど不可能です。

私のアドバイス：テストの追加を開始し、製品の最も重要で頻繁に変更される部分の選択に関するカバレッジを増やします。これは自分の時間に、場合によっては「共犯者」と一緒に行い、作業の時間を計ります。

その後、これらのテストで検出されたリグレッションバグの懐疑的な例と、実際に費やした時間の価値を示します。そうすることに成功した場合、経営陣は単体テストにリソースを費やすことに価値を見出します。

技術的な課題に従って、私はここで実践が完璧になるという他の答えに同意しますが、あなたを助けることができるいくつかのガイドラインがあります：

  • テストごとに1つだけテストします。同じ条件を表明するテストが100個ある場合、この条件が変更されると、100個のテストを更新する必要があります。
  • 「テスト対象クラス」が巨大で、大量のロジックが含まれている場合、テストするのは非常に困難です。クラスを小さくて一貫性のあるロジックの単位にリファクタリングしてみてください。これらのユニットの1つが変更されると、失敗したテストの数は比較的少なくなります。
  • 実装の詳細ではなく、パブリックインターフェイスをテストします。これにより、開発者は、テストへの影響を最小限に抑えながら、バグを修正し、パフォーマンスを向上させ、リファクタリングすることができます。

Googleの「ユニットテストガイドライン」の最初のページには、さらに多くの ガイドラインがあります。優れたユニットテストの作成に関する広範な記事については、 The Art OfUnitTestingを参照してください。

幸運を！

于 2012-08-22T18:24:34.507 に答える
1

単体テストを作成するかどうかは、管理に関係する必要はありません。通常重要なのは、機能が迅速に実装され、バグがないことです。それをどのように達成するかは、開発者の皆さん次第です。ユニットテストは1つの方法にすぎません。依存関係を簡単にモックアウトできる疎結合コードに最適です。

しかし、優れた単体テストを作成することは、それらを作成するかどうか、または使用するツールを決定することだけではありません。ほとんどの場合、練習することによってのみ得られる経験についてです。コードがないため、優れた単体テストを作成できる簡単なレシピはありません。経験のない人に単体テストを書くように強制すると、確かに生産性が低下し、明らかなメリットはありません。最終的には、他の誰かがあなたを助けるべきだと思っているからではなく、あなたがそれがあなたを助けていると信じているので、あなたはユニットテストを書くべきです。

于 2012-08-22T02:22:14.920 に答える
0

テスト対象のシステムが変更された場合、テストデータファクトリを統合することでメンテナンスコストを削減できます。

多くの場合、テストには、わずかな違いがあるだけの同様のテストセットアップがあります。

単体テストを開始したとき、コピー＆ペーストを使用して、既存のテストから新しいテストを作成しました。

すべてのテストには長いテストセットアップがありました。

テスト対象システムを変更した後、多くのテストを更新する必要がありました。

今日、私は標準との違いだけが割り当てられているテストデータファクトリを使用しています。

例

  void customerUnder18ShouldNotbeGrantedAccess() {
      // Arrange
      Customer customer = TestdataFactory.CreateStandardCustomer();
      customer.setAge(16);

      // Act...
      // Assert ..
  }

ここにもっと役立つヒントがあります。

于 2012-08-22T04:51:34.193 に答える
0

答えは、単体テストは機能ではなく実装をテストする必要があるということです。したがって、開発者がコードをリファクタリングする場合、内部をテストするのではなく、結果だけをテストするため、単体テストで何も変更する必要はありません。

もちろん、インターフェースや動作を大幅に変更すると、もちろんテストも変更されますが、とにかく新しいコードをテストしたいので、テストを作成し続けることになります。

簡単に言えば、優れたテストスイートが長期的には大幅に時間を節約するという多くの研究があります。

于 2012-08-22T02:44:12.713 に答える