【”打鍵”と”テストコード”の使い分け】

疑問に思うところがあると思いますが、打鍵バージョンでの試験とテストコードバージョンでの試験の２パターンで試験を実施できます。
そこで、両方やる必要があるのか、もしくはどちらかだけをやるのか最初はわかりません。それを解説していきたいと思います。

実際のプロジェクトでは、打鍵テストだけに頼ることはまずありません。
理由として、手動での確認ではどうしても時間がかかり、ミスが生じやすいからです。特に大規模なプロジェクトやチーム開発では、テストコードを書くことが標準的なプロセスになっています。

理想的な流れ

１、単体テスト（自動化）

小さいナコードの単位（メソッドやクラス）が正しく動作しているかをJUnitなどでテストします。これにより、コードの品質を保証しつつ、あとから変更しても、問題がないかをすぐに確認できます。

２、結合テスト（自動化）

サービスやコントローラーなど、複数のコンポーネントが連携して動作しているかをテストします。これもできるだけ自動化し、データベースや外部APIとのやり取りを確認します。

３、打鍵テスト（手動）

大きな機能やユーザーインターフェースの変更がある場合には、手動での打鍵テストも併用します。UIの見た目や、細かな動作の確認は自動化が難しいことがあるため、実際に人間の目で確認することが大切です。

４、エンドツーエンドテスト（自動化と手動の併用）

ユーザーの実際の操作を趣味レーションするエンドツーエンドテストを、CypressやSeleniumのようなツールで自動化することもあります。また重要な箇所は打鍵でチェックすることもあります。

打鍵テストだけではだめなのか

打鍵テストだけでも、ある程度の品質保証は可能ですが、手動の作業が増え長期間のプロジェクトでは非効率です。また、打鍵テストでは見逃しやすいバグや、内部的なエラーの検知が難しい場合があります。ですので、基本的には打鍵テストだけではなく、テストコードを書くのが推奨されています。

テストコードだけではだめなのか

テストコードだけでも、アプリケーションの内部的な動作を十分にカバーできます。しかし、実際の画面操作やUIの見た目、ユーザー体験に関する部分までは自動テストだけでは確認しづらい部分もあります。特にフロン路エンドの細かな挙動やデザインが絡む場合は打鍵テストのように実際に目で確認することが必要です。

まとめ

実際のプロジェクトでは、打鍵テストとテストコードの両方を使うことが望ましいです。自動テストによって基本的な機能や動作をカバーしつつ、重要な部分やUIに関しては手動でチェックする、というのがバランスの取れたアプローチです。初心者のうちから、テストコードを書く習慣をつけておくと、後々大規模なプロジェクトに参加した際に役立ちます。