私たちはプロジェクトの新しい部分を開始しようとしていますが、単体テストにはあまり関心がないようです (そして、彼らは TDD を経験したようには感じません)。これはほぼ不可欠であり、メンテナンスがはるかに簡単になると思います。それで、あなたの意見は何ですか？
ありがとう
ところで: これは言語にとらわれない質問ですが、新しいプロジェクトは Java です。
1114 次
17 に答える
8
私たちのプロジェクトでは、絶対に単体テストが使用されています。頭の悪いゲッターやセッターではないすべてのクラスは、ユニットテストされています。コードの機能テストを行うことで、一度に50の異なるものを壊すことを心配することなく、自由にリファクタリングすることができます。
単体テストのもう1つの過小評価されている側面は、アルゴリズムの見落とされている側面を表面化することです。テストケースのリストを作成するたびに、技術リーダーが見落としていた問題のさらに別の側面を発見したため、直交表を使用して単体テストを作成および再作成するのに2日間を費やしました。
于 2008-10-18T04:01:19.350 に答える
8
単体テストは単に便利なことであるだけでなく、開発者の責任でもあることがわかりました。有効で包括的な単体テストのセットに合格するように記述されていないコードをリリースすると、プロジェクトが遅れたり、他の人のパッケージやクラスなどで問題が発生したりする可能性があります。
さらに、（自分の会社であっても）顧客と緊密に連絡を取り、包括的な受け入れテストを行うように顧客に勧める必要があります。それは彼らの最善の利益です（ただし、製品が正確に機能しない場合に節約できる時間の長さにもかかわらず、テストの実行に必要な短期間の費用のために、一部の企業はこのアイデアに抵抗していることがわかりました彼らが望むこと）。
編集
ですから、そうです、私が言おうとしているのは、そうです。そうです、テスト駆動開発を進むべき道だと思います。もちろん、私が言及しなかったもう1つのことは、テストがコードの文書化に役立つという事実です。メソッドが何をするのかがわかり、後の段階で変更を加えたときに、メソッドが引き続き機能することを確認できます。
于 2008-10-17T11:19:29.730 に答える
5
単体テストには代償が伴います。まず、余分なコードをすべて作成して検証する必要があります。そして、単体テストを採用するために、プロジェクト チーム内で費用のかかる文化の変更を推進しなければならない場合があります。
この価格は、特定のプロジェクトに支払う価値があるかもしれません. 決定はドグマや逸話に基づくべきではなく、費用と利益の慎重な分析に基づくべきです。
于 2008-10-17T12:08:59.990 に答える
5
はい。しばらくの間、TDD を使用しています。どういうわけか、TDD は私たちの中で成長しており、より良いコード品質を達成するために、この漸進的なアプローチが気に入っています。開発が遅くなると思われる最初の拒否曲線にもかかわらず、コードを記述しながら一貫した漸進的な単体テストを行うことは、多くの点で不可欠です。漸進的に構築されている回帰テストのフレームワークのため、重大な変更を書き込むことは非常に困難です。正しく行われると、コードはより堅牢になり、コードとプロジェクト全体に対する信頼がプラスの影響を受けます。
今日、単体テストを書くことは、単なるエリートのためのものではありません。それはすべての開発者の責任であるべきです。コードのバグが発見されるのが遅ければ遅いほど、修正にかかる費用が高くなり、見つけるのが難しくなります。これは簡単にメンテナンスの悪夢になります。単体テストを強力にサポートすると、このリスクが大幅に軽減されます。
単体テストと TDD の機能を適切に構成された継続的インテグレーション システムと組み合わせることで、プロジェクトの初期段階で問題を迅速に発見できます。毎日のビルドは、将来のほぼ確実な面倒を避けるために必須です。
于 2008-10-17T11:13:29.773 に答える
2
コードのセクションがクライアントが本当に望んでいるように機能した後、単体テストを実行します。最初はユニットテストをあまりにも速く行っていたので、クライアントが気が変わったとき（そしてそれが起こったら、私を信じてください）、ユニットテストだけでなくコードも削除しなければならないことがよくあります。それは時間と費用がかかりすぎました。私はユニットテストを担当していますが、TDDは私たちにとって経済的なものではありませんでした。
于 2008-12-17T13:21:15.593 に答える
2
現在、自動テストなしでプロジェクトに取り組むことは想像できません（ユニット/統合など...）
実はよく言ってる
「これが壊れても私のせいじゃない」
テストを持たない人々のコードに取り組んでいるとき。
于 2009-08-25T09:49:33.677 に答える
2
厳密には TDD ではありませんが、私は自分が書いたすべてのコードに対して単体テストを行っています。ソース管理やリファクタリングと同じように考えています。これらは、高品質のコードを記述するためだけに行うものです。単体テストをしないとは思いません。
于 2008-10-17T12:20:04.057 に答える
1
ディスカッションフォーラムで質問すると、多くの人が単体テストは「必須」と言うでしょうが、実際には、調査結果が示すように、単体テストの考慮事項です。その他の参考資料/資料については、 http：//www.methodsandtools.com/dynpoll/oldpoll.php？UnitTest2を参照してください。
于 2008-12-17T21:47:25.570 に答える
1
TDDは本当に便利だと思いましたが、新しいコードを書くまで古いテストに失敗するまで、TDDの価値を理解できない開発者もいます。
于 2008-10-17T11:23:07.383 に答える
0
はい、できる限り。私は自分が書いたコードをサポートする必要があり、開発中に費やされた適度な量の余分な時間は、リリース後に費やされた適度な量の余分な時間から私を救うことを知っています。
于 2009-10-11T17:18:30.253 に答える
0
On all new development, we now do TDD. For legacy maintenance, we create failing unit tests to expose reported defects and gradually build up a library.
It is a culture shock, but it really does pay off when you realize that you are spending more time on new development and less time bug-hunting.
于 2008-12-10T19:20:57.630 に答える
0
私はそれをやりたいと思っていますが、途中で参加することになった大規模なプロジェクトでそれを始める方法がわかりません... 1996年以来、プロジェクトの真の新たな開始に関与していません！
于 2008-10-17T11:34:10.623 に答える
0
単体テスト (ここでは JUnit を考えています) と TDD は、新しいコードで新しいプロジェクトを開始する場合に適しています (さらに CI のようなものが必要になります)。
しかし、新しいプロジェクトで、それぞれに 5KLOC を含む密結合クラスでいっぱいの古いコード ベースを変更する場合、単体テストは困難であり、ほとんどの場合、プロジェクトのタイム ラインではリファクタリング (または書き直し) が許可されません。これがあなたが始めようとしている種類のプロジェクトである場合は、古いコードで戦略をテストするために「レガシー コードの使用」を読むことをお勧めします。
于 2008-10-18T03:47:56.227 に答える
0
残念ながら毎回ではありません。私たちの最もミッション クリティカルなシステムは、開発者に関係なく、実行すべきことを確実に実行し、実行し続けるための単体テストでいっぱいです。他のシステムでは、ほとんどの場合、開発時間が短すぎてテストの作成に費やすことができません。(ただし、最終的に得た時間はデバッグに 2 回費やされます。)
于 2008-10-17T13:16:07.280 に答える
0
自分のプロジェクトで単体テストをもっと活用できたらいいのにと思いますし、同僚が少なくともいくつかのテストを書いてくれたらいいのにと思います。:)
私の場合、単体テストを有効にして TDD プラクティスを使用するには、かなりの代償が伴います。それは主に、使用しているフレームワークにとって非常に貧弱なツールに依存しています。プロジェクト全体に対して 1 回のクリック (または、現時点で特定のテストが必要な場合は 2 回のクリック) で単体テストのみを実行できれば、はるかに簡単だったでしょう。私たちが現在使用しているツールは、実際には効果がありません。テストを実行するよりも、手動でバグを発見する方が簡単な場合があります。
Java にはより優れたツールがあるため、今すぐテストを書き始める必要があります。デバッグは最悪だし、岩をテストするのは本当に。
于 2008-10-17T12:54:01.850 に答える
0
書く価値があるなら、テストする価値があります。
于 2009-10-11T18:51:23.640 に答える
0
はい。クライアントが私の頭の横に銃を持っていて、一日の終わりまでに機能をドアの外に出す場合を除いて.
于 2008-10-18T02:59:38.693 に答える