私の質問は初心者かもしれませんが、どのような状況で私がジュニット?
単純なアプリケーションを作成する場合でも、大規模なアプリケーションを作成する場合でも、ステートメントを使用してテストするSystem.outと、非常に簡単に思えます。
同じメソッドを呼び出して、その戻り値をチェックし、すべてに注釈を付けるオーバーヘッドが発生するのに、なぜ JUnit でテスト クラスやプロジェクト内の不要なフォルダーを作成するのでしょうか?
クラスを書いてすぐにテストするのではなくSystem.out、テストクラスを作成しないのはなぜですか?
追伸：私は大規模なプロジェクトに携わったことがなく、ただ学んでいるところです。
それで、目的は何ですか?
ベストアンサー1
それはテストではなく、「手動で出力を確認する」(業界では LMAO として知られています) ことです。より正式には、「手動で異常な出力を確認する」(LMFAO) として知られています。(下記の注記を参照)
コードを変更するたびに、アプリを実行して、その変更によって影響を受けるすべてのコードに対して LMFAO を実行する必要があります。小規模なプロジェクトであっても、これは問題が多く、エラーが発生しやすくなります。
今では 50k、250k、100 万行以上にスケールアップし、コードを変更するたびに大笑いします。不快なだけでなく、不可能です。入力、出力、フラグ、条件の組み合わせがスケールアップし、すべての可能な分岐を実行するのは困難です。
さらに悪いことに、LMFAO は、Web アプリのページを何ページも訪問し、レポートを実行し、数十のファイルとマシンにわたる何百万ものログ行を精査し、生成および配信された電子メールを読み、テキスト メッセージを確認し、ロボットのパスを確認し、ソーダのボトルに注ぎ、100 の Web サービスからデータを集約し、金融取引の監査証跡を確認する... といった作業を意味するかもしれません。"出力" は、数行のテキストを意味するのではなく、集約されたシステム動作を意味します。
最後に、ユニットテストと動作テスト定義するシステムの動作。テストは継続的インテグレーション サーバーで実行し、正確性をチェックできます。もちろん、テストでも可能ですSystem.outが、CI サーバーはテストの 1 つが間違っているかどうかを知ることはできません。間違っている場合は、ユニット テストなので、フレームワークを使用する方がよいでしょう。
自分たちがどれほど優秀だと思っていても、人間は優れた単体テスト フレームワークや CI サーバーではありません。
注: 大爆笑はテストではあるが、とても限られた意味しかありません。プロジェクト全体、またはプロセスの一部として、意味のある方法で繰り返すことはできません。これは、REPL で段階的に開発するが、それらの段階的なテストを形式化しないのと似ています。