プロの開発者として、単体テストを記述しないことは許容されますか？[閉まっている]

TDD /自動化された単体テストの長所と短所について疑問に思っており、プロの開発者が単体テストをサポートせずにアプリケーションを作成することが受け入れられるかどうかについてのコミュニティの見解を探していますか？

何をテストするの？

100％のコードカバレッジについて話している場合、それは非常にまれであり、有用ではなく、多くの場合不可能です。同様に、CRUD関連のコードをテストすることは時間の無駄であり、実際に役立つことをする代わりに、不要なコードを書くことに何時間も費やすことは非常に専門的ではありません。

さて、開発者として、あなたはユニットテストを書く方法とそれらをどこで必要とするかを知らなければなりません。

理論

単体テストは「ユニット」をテストするためのものであるという一般的な誤解があります。
単体テストは、他のすべてのテストと同様に、機能をテストします。テストできるものは他にありません。

ただし、複雑なシステムの機能は、効果的にテストできないことがよくあります。
たとえば、ユーザーが「削除」ボタンを押しても何も起こらないとします。どうして？エラーはデータベース内にあるか、接続が切断されているか、コアロジックが誤動作している可能性があります。または、操作が成功してもインターフェイスが正しく更新されなかった可能性があります。各層には、相互に呼び出す多くの関数が含まれる場合があり、エラーの場所が常に明確であるとは限りません。
単体テストは、コンポーネントを分離して個別にテストするというパラダイムに基づいています。

繰り返しになりますが、システム全体の動作は保証されませんが、テストが簡略化されます。

TDD自体は要件ではありません。開発者に「実際に何をコーディングするのか」と最初に答えるように強制することで、コーディングを簡素化します。

費用

多くの人は、テストを作成しないことで時間を節約できると考えています。違う。戦略的に考えると、エラーのコストは、出現してから検出されるまでの時間とともに指数関数的に増加します。

コードでエラーを犯し、同じ日にそれを検出して修正するとします。費用は$ Xです。
エラーが検出されずに残り、毎週の内部ビルドに移行するとします。幸いにも、QAがそれを検出し、バグ追跡システムでバグを提起しました。この問題は、5人の会議での5分間の議論の対象でした。最後に、問題を修正しました。コストはすべての人が費やした労働力の合計であり、この場合$ 3 * Xになる場合があります。
エラーがベータテストに進み、より多くの人が関与した場合はどうなりますか？$ 10 * Xとしましょう。
それが長期間検出されないままで、1,000人の顧客（できれば100万人ではない！）に行った場合、10人がそれを検出し、サポートスタッフと話し合いました。など、最後に、バグが戻ってきて、修正します。合計でいくらですか？$ 50 * X以上です。

ご覧のとおり、バグは遅かれ早かれあなた（またはあなたの同僚）に戻ってきます。唯一の違いは、いつ発生し、どのくらいの費用がかかるかです。
単体テストは、バグのライフサイクルを短縮し、コストを削減します。

プロの

• ユニットテストを使用すると、開発者はより適切にコーディングできます。それと同じくらい簡単です。
• 彼らはあなたの時間を節約できます。
• 彼らはコストを削減します。
• 単体テストは、テストするコードと一緒に実行されます。（常に発生する）変更要求があると、テストが適応します。

コンの

テストを書かないことの言い訳が1つあることがわかります。あなたがプロトタイプを書いているなら、例えば他の人に決して行くことがない何か。あるいは多分あなたは使い捨てのために何かを書いています。

確かに、それは少し内部ヘルパーユーティリティ、またはテストツール、またはビジネスが本当にシナリオのない書き込みユニットテストに受け入れられる、本当に品質よりも他のもの必要としますが、ソフトウェアが実行され、ちょうどすぐとして働いて得ることができることを、プロの開発者の発見にごなし。

私の経験では、ユニットテストで検出できるエラーの95％は、特にデータベース設計の変更後のデータ層の呼び出しに起因しています。データベースを使用している場合は、データベースへのアクセスに使用するすべてのメソッドをテストしてください。テストは精巧である必要さえありません、正しさのチェックだけです。

あなたの質問への回答-データベースにアクセスし、あなたがプロの開発者である場合は、単体テストを使用する必要があります。それ以外の場合は、状況によって異なります。

それは、アプリケーションがどのように使用されるかによります。これはミッションクリティカルなアプリケーションですか？それとも、開発者が内部でのみ使用する単純な検証アプリケーションですか？会社のコアアプリケーションで作業するときは、ビジネス上の決定がカバーされることを確認するために必要なだけの単体テストが必要です。あなたの会社によっては、これらは顧客が目にするアプリケーションであり、バグは費用がかかる可能性があります。うまくできていれば、単体テストは、デプロイ時にアプリケーションが機能することを確認するための大きな助けになります。しかし、それはすべてを解決するものではなく、人間によるテストは依然として行われるべきです。単純な内部（または補助）アプリケーションは、単体テストを必要としませんが、依然として適切に作成する必要があります。

TDDは、最初にテストを記述するだけではありません。コードを簡単にテストできるようにすることです。そして、たいていの場合、簡単にテストできるコードは、読み取り/デバッグ/保守も簡単です。多くの場合、容易にテスト可能なコードは、SOLIDなどのパターンとオブジェクト指向の原則にも従います。私はプロの開発者として、あなたのコードは常にそのように書かれるべきだと主張します。

あなたは間違いなく「テストなし」を望んでいません。単体テストを作成する場合、コードがテストと一致することを少なくともある程度保証します（ただし、テストが仕様と一致することを確認する必要があります）。

ただし、単体テストだけでは完了しません。おそらく、まだ統合テストとエンドツーエンドテストを行う必要があります（そして、時間の経過とともにテストケースを蓄積して、バグのリグレッションをキャッチします）。

私はここで外に出て、それは主に主観的であり、あなたの目標に依存すると言います。tl; dnr：それは良いことですが、それについて独断的であることは、より多くの問題につながるでしょう。

TDD /ユニットテストは、コードの安定性を向上させます。それらはコードベースをよく知らなくても簡単に変更を加えることができ、リファクタリングをより速くし、愚かなことをしていないことを確実にします。単体テストも時間の無駄です。コードの記述に費やすことができる時間。また、盲目的にコードをフォローしなければ、コードが機能しない場合でもコードが機能していると思い込んでしまう可能性があります。

ベストプラクティスをサポートし、それらを実装するための時間を与えてくれる会社で働いていて、持続するアプリケーションが必要な場合は、ユニットテストとコードレビューを使用して実践するのが誰にとっても最良です。QAチームを持つことは、開発者がそれを乱用しない限り、受け入れ可能な代案になる可能性があります。プロトタイプを作成している場合は（プロダクションのプロトタイプであっても）、煙のテストを行うだけの方が高速かもしれません。

混乱が世界の終わりにならないような何かに取り組んでいる場合は、カバレッジを減らしても問題ないでしょう。金融取引？たくさん。コードベースを熟知している強力な開発者のチームがいて、うまく連携し、離職がない場合は、おそらく対象範囲を狭める必要があります。等。

だからそれはおそらくいくつかの機能になるだろう

• チームの規模/離職率
• アプリケーションの望ましい貯蔵寿命
• アプリケーションとどのように重大な障害があります
• 時間は、開発スケジュールに対するベストプラクティスを実装するために提供しました
• チームの適性（これはあなたが書き込みユニットテストではないはずですが、ジュニアの開発者のないチームはより多くの成功とズボンの座席によって飛ぶことができるかもしれない優秀なプログラマーの手段であることを意味するものではありません）

許容可能であるユニットテストを書いていない状況がたくさんあります。TDDは今「を」ですが、それは銀の弾丸ではありません。

するプロであるウィル保存あなたの時間と涙ということメンテナンス可能ユニットテストを書きます！

がありmisconception that Unit test finds bugsます。まあそれは単にすべての場合に当てはまるわけではありません。単体テストは、バグの発見や回帰の検出に関するものではありません。定義によりexamine each unit of your code separatelyます。しかし、アプリケーションが実際に実行される場合、これらのすべてのユニットは連携して動作する必要があり、全体は独立してテストされた部分の合計よりも複雑で微妙です。

したがって、ユニットテスト（TDDプロセス内）の目標は、ソフトウェアコンポーネントを堅牢に設計することです。

編集：単体テストが実際にバグを検出するという例外が1つあります。ユニットのコードをリファクタリングまたは再構築しているが、動作を変更する意味がないときです。この場合、ユニットテストでは、ユニットの動作が変更されたかどうかを確認できます。

プロの開発者として、単体テストを記述しないことは許容されますか？

番号。

疑いの余地はありません-これは、初心者が学ぶ最初のレッスンの1つです。QAにテストの準備ができていることを伝える前に、ユニットテストを開発してコードが機能することを証明する必要があります。そうしないと、プロジェクトのコストが増大し、チームの士気が低下します。

これらの単体テストはどの程度徹底すべきですか？

リトマステストは次のとおりです。QAがコードのバグを発見した場合、上司に対するデューデリジェンスを証明するためにユニットテストを使用しても問題ありませんか？

答えが「いいえ」の場合は、より優れた単体テストを作成する必要があります。
答えが「はい」の場合、コードを検証する準備ができています。

プロの開発者として、自動化された単体テストを記述しないことは許容されますか？

はい。

特に、自動化された単体テストの作成に費やされた時間と労力が、テストによって得られるメリットを上回る場合。これには、モックするのが難しいUIコードが含まれますが、これに限定されません。

強調：UIコードの自動化された単体テストを書くことが不可能だと言っているのではありません。私の経験では、一部の UIコードの自動化された単体テストを作成することが難しい場合があることを言っています。