多くのユニットテストを書いたことがないのですが、どうすればそれをさらに練習できますか？
来週すぐにインタビューが来ます。このソフトウェア開発ジョブの責任のリストにいくつかの点があります（ジョブポジションのタイトルはあいまいで、Java開発者）と言っています）約：
- 単体テスト機能
- 新機能のデバッグ
- テストケースの設計に関する推奨事項を入力してください（これは何ですか？）
過去のソフトウェアプロジェクトでは、ユニットテストの記述を気にしていなかったので心配です。 JUnitを使用してEclipseおよびプロセスでテストを作成する方法は知っていますが、テストを作成した経験があまりないというだけのことです。たとえば、私は互いに大きく異なるWebからのデータに依存し、このデータを処理します。すべての種類のデータのテストケースを作成するにはどうすればよいですか？また、データがローカルデータベースからのものである場合、テーブルからのデータが適切に読み取られていることを確認するテストケースをどのように記述しますか？
可能な場合はいつでもEclipseでデバッグ機能を使用しましたが、ソースコードが提供されていないライブラリ（商用のサードパーティのjarなど）にアクセスすると、機能へのステップが停止します。したがって、ほとんどの場合、バグが発生している場所を見つけるためにSystem.out.printlnを実行します。より良い方法はありますか？
単体テストを書く能力をある程度身につけるには、どうすれば短期間に練習できますか？
練習する唯一の方法は、ただそれを行うことです。自分で効果的な単体テストを作成する方法をまだ学んでいます。残念ながら、優れた単体テストがどのように見えるかについての本当の気持ちをつかむには、何時間もかかる必要があります。私が考えることができる唯一の近道は、8時間ではなく1日16時間作業することです。2倍の速さで学習できますが、疲労が始まるまでです。
私が提案するいくつかのこと：
タイムクリティカルではないタスクに取り組んでいることを確認してください。時間のプレッシャーとすぐに実行しなければならないという感覚は、一般的に人々にショートカットを与え、a）テストを作成しない、b）ほとんど作成しない、またはc）決して維持できないためテストを作成できないそれらをリファクタリングするのに時間がかかりました。
プロダクションコードと同じように、コード品質の要件が（厳密でないとしても）同じである単体テストを作成するタスクに取り組みます。単体テストがリリースされていないと考える人もいるので、優れたプラクティスに従うことはそれほど重要ではなく、テストは非常に壊れやすく、保守が非常に困難になります。
テストだけでなく、自分（およびチームの他の人）の生活を楽にするヘルパークラスも作成するのに十分な時間を割り当てます。私自身の経験から、特定のタスクが長すぎて適切にコーディングできないため、またコードをライブラリに分解するのにさらに時間がかかるため、人々はテストを作成するときにショートカットをとる傾向があるようですが、ユニットテストプロジェクト間でコードをコピー/貼り付けすることになります。私は、将来のテストの開発をスピードアップすることを意図して、私たちのグループのユニットテストヘルパーライブラリを開始しました（ライブラリのいくつかの一般的な機能：モックオブジェクトアクションを記録/検証するための単純なコード、ユニットテストを支援するファイルを操作するためのコード）外部データ、標準のフックをフィードして、win32呼び出しをオーバーライドする必要があります...）。
コードの前にテストを作成するTDDの練習の習慣を身に付けてください。最初は単体テストはオーバーヘッドが多いようですが、とにかく作成した本番コードを実行する必要があるため、TDDはそれを補う以上のものです。すべての長期的なメリットを考慮せずに、テストの作成にかかった時間をすぐに回収し始めます。
これは、優れた単体テストの作成方法を概説しています。優れた単体テストとは何かを単に「知りたい」と思っている人のために、本当に良い本がたくさんあります。 （私は Art of Unit Testing から始めます）
ソフトウェアコミュニティは、単体テストの問題で分かれています。
単体テストは作成しないことをお勧めします。これらはほとんど役に立ちません。それらは、「それは良い習慣」、「成熟したチーム/開発者が単体テストを書く」、または他のいくつかの業界の教義のために書かれています。
一方、統合またはエンドツーエンドのテストは、チームが本当に品質を気にしている兆候です。
とにかく、あなたの質問のいくつかの特定のポイントに行きましょう。
- Webからデータを受け入れるコードのテストを作成します。
ハッピーパステストケースから始めます。このテストは、コードがその基本的なシナリオで機能することを示すためにあります。これは、コードの変更によってアプリが大きな影響を受けなかったことを検証するのに非常に役立ちます。
データを受け入れるロジックが複雑な場合は、このロジックのすべての主要なブランチに対してハッピーパステストを記述します。
私の経験では、このテストはすぐに元が取れます。通常、テストが書かれてから数時間以内です。私を信じて、このテストは与え続けるだけです。
次に、セキュリティが機能し、APIが適切な場合に401/403を返すことを証明するテストを作成できます。
その後、必須フィールドが欠落しているデータでテストを記述します。多くの場合、そのためのコードを一度記述して、別の欠落フィールドで実行できます。
- テストデータ
テストを書く純粋な方法は、テストに必要なすべてのデータを作成し、テスト後にそのすべてのデータを削除するように書くことです。実際にはこれはしばしば不可能であり、1つの一般的な戦略は、定期的に（たとえば、1日に1回、またはテストを実行するたびに）dbをフラッシュバック/復元することです。
多くの場合、データベーステストでは、ベースラインデータがデータベースに存在することを前提としています。これは問題ありません。
- 「デバッグ」のための印刷。
それは2016年であり、デバッグはますます簡単になっていますが、コードをステップ実行できない場合でも、ログに行を追加する方法がまだあると思います。
単純なクラスを作成し、そのユニットテストを記述します。練習を通してのみ、それがどのように行われるかを理解することができます。必要に応じて、オープンソースプロジェクトの単体テストの例を見つけるか、ガイダンスとしていくつかのオンラインチュートリアルを参照してください。
面接で頑張ってください！