0

TDD/自動化された単体テストの長所と短所を知り、プロの開発者が単体テストをサポートせずにアプリケーションを作成することが許容されるかどうかについてコミュニティの意見を探していますか?

プログラマーに再質問: https://softwareengineering.stackexchange.com/questions/159572/is-it-acceptable-as-a-professional-developer-not-to-write-unit-tests

4

3 に答える 3

2

これについては -1 -ed を取得するに違いありませんが、それでも言います: 品質を確保するための他の手段 (回帰の回避、プログラムの検証、プログラムの検証など) がある場合は、 いいえ。

唯一の問題は、通常、これを達成するための単体テスト以外のツールがないことです。

モデルを正式にテストした場合 (実際にモデルをテストするツールがあるか、モデルが有効であることを保証する方法で構築されている場合)、実際に実行されているソフトウェアがそのモデルに準拠していることを確認する方法を正式にテストした場合は、大丈夫だよ。

例: Ruby で記述したコードが期待どおりに動作することが確実な場合 (あなたまたは他の誰かが Ruby インタープリターをテストし、バグがないため、または既知の機能のサブセットのみを使用したため)安心してください）それなら大丈夫です。通常、私たちは C コンパイラと CPU をこのように信頼します。

また、プログラムを 1 回だけ使用する場合は、回帰の問題はありません。何かを計算してくれるワンライナーを bash で書いた場合、最初に偽のデータで手動でテストしてから、実際のデータで実行します。自動化されたテストを書く必要はありません。

あなたが責任を負う場合は、仮定に沿って進むこともできます。通常、Eclipseはセッターとゲッターの作成に非常に優れていると思いますが、それらについてはテストしていません。また、Java 7 で Java の Collection クラスに問題が発生した場合、それはすでに判明していると思います。ただし、トラブルが発生した場合、それは個人的なトラブルです。誰も責めないで。

個人的には、特定のコードに対して単体テストを使用することはめったにありません。形式的にテストするのは、まだ紙の上のフローチャートであり、そのような状況で動作することが知られている言語/ライブラリのサブセットのみを使用するようにするためです。また、ピア レビューなしでコードを公開することはありません。それでも、受け入れテストを実行する人がいる方が良い場合もあります...

于 2012-08-05T12:56:12.937 に答える
1

それはあなた次第です。質問は本質的により哲学的です。

単体テストは、あなたを助けるための単なるツールです。それらを無視することを選択できます。ただし、些細なプロジェクトに取り組む場合は、単体テストを使用することをお勧めします。

はい、書くのにも時間がかかります。しかし、最終的には、リファクタリングが行われたり、コードの一部を変更する必要がある場合に、大幅に節約できます。

于 2012-08-05T12:53:58.837 に答える
1

いつものように：場合によります。

一般的に言えば、ユニット テストは良いことです。エラーのクラス全体をキャッチし、特定の状況下でコードの特定の部分が期待どおりに機能することを検証し、問題が発生したときにエラーを追跡しやすくします。したがって、そうしない正当な理由がない限り、単体テストを作成する必要があります。

単体テストを作成しない正当な理由は次のとおりです。

  • このため、構造が悪く、ほとんどテストできないコードベースに比較的小さな変更を加えます (通常、その理由は、関心の分離がほとんどなく、コードベース自体に侵入的な変更を加えなければ、テスト可能なユニットをテスト用に分離できないためです)。
  • 問題ドメインの性質上、コードは本質的にテスト不可能になります。これはまれですが、発生します。たとえば、GUI を描画するルーチンの意味のある単体テストを考え出すのは非常に困難です。モック サーフェスにレンダリングしてから、個々のピクセルをチェックする必要がありますが、また、レイアウトの決定などに影響を与えるすべてのパラメーターをモックする必要があります。これは理論的には可能ですが、通常、努力する価値はありません。そのような場合は、手動または半自動のテストを選択する必要があります。
  • このプロジェクトは、スコープが小さく、ライフサイクルが非常に短い小さな使い捨てプログラムであるため、単体テストから得られる利点 (保守性の向上、複雑さの軽減) はわずかです。ただし、ソフトウェアは設計されたよりも長く存続する傾向があり、1 回限りの使い捨てスクリプトが会社のプロセスのミッションクリティカルな部分になる可能性が非常に高いことに注意してください。
于 2012-08-05T12:55:51.217 に答える