テストの実行
はじめに
JHipsterには広範なテストセットが用意されており、生成された各アプリケーションには以下のものが含まれます。
オプションで、JHipsterは次のテストも生成できます。
- Gatlingを使用したパフォーマンステスト
- Cucumberを使用した動作駆動型テスト
- CypressまたはProtractorを使用したAngular/React/Vue統合テスト
これらのテストの生成には2つの目的があります。
- すべてのJHipsterユーザーがベストプラクティスに従うことを支援すること。テストはすべてのアプリケーションの非常に有用な部分であると考えています。
- 生成された内容が正しいことを検証すること。そのため、テストを使用しない場合でも、アプリケーションの生成後に
./mvnw clean verifyとnpm testを実行することで、すべてが正常であるかどうか確認できます。テストが時間の無駄だと思われる場合は、これらのテストを無視してもかまいません！
これらのテストはすべて、標準のMaven src/testフォルダに生成されます。
統合テスト
統合テストはSpring Test Contextフレームワークを使用して実行され、src/test/javaフォルダに格納されます。JHipsterは、すべてのテストで再利用される特定のSpringテストコンテキストを次のように起動します。
- Spring Beanはステートレスでスレッドセーフである必要があるため、さまざまなテストスイートで再利用できます。
- すべてのテストに対して1つのSpringコンテキストのみを起動する方が、各テストに対して新しいSpringコンテキストを起動するよりもはるかに高速です。
このSpringテスト・コンテキストでは、特定のテスト・データベースを使用してテストを実行します。
- SQLデータベースを使用する場合、JHipsterは統合テストに一時データベースを使用するためにインメモリH2インスタンスを起動します。または、
testcontainersプロファイルを使用することにより、JHipsterはTestcontainersを使用してコンテナ化されたバージョンのプロダクションデータベースを起動します。いずれの場合も、Liquibaseが自動的に実行され、データベーススキーマが生成されます。 - Cassandraを使用している場合、JHipsterは、Testcontainersを使用して、Dockerでコンテナ化されたバージョンのCassandraを起動します。
- MongoDBを使用している場合、JHipsterはde.flapdoodle.embed.mongoを使用してインメモリMongoDBインスタンスを起動します。
- Elasticsearchを使用している場合、JHipsterはSpring Data Elasticsearchを使用してインメモリElasticsearchインスタンスを起動します。
- Couchbaseを使用している場合、JHipsterは、Couchbase Testcontainersを使用して、DockerでCouchbaseのコンテナ化バージョンを起動します。
- Neo4jを使用している場合、JHipsterは、Neo4j Testcontainersを使用して、DockerでNeo4jのコンテナ化バージョンを起動します。
これらのテストは、各テストクラスを右クリックするか、./mvnw clean verify（Gradleを使用している場合は./gradlew test integrationTest）を実行することによって、IDEで直接実行できます。
制限事項: 生成されたエンティティで検証が有効になっている場合、JHipsterは検証ルールに応じて正しい値を生成できません。これらのルールは非常に複雑である可能性があるため（Regexパターンが使用されている場合など）、これは不可能です。この場合、テストは検証に失敗し、テストで使用されるデフォルト値は、検証ルールに合格できるように手動で変更する必要があります。
UIテスト
JHipsterのUIテストには、JestによるユニットテストとProtractorによる統合テストの2種類があります。デフォルトではJestのみが提供されていますが、アプリケーションのテストカバレッジを良好にしたい場合は、両方のツールを一緒に使用することをお勧めします。
Jest
UIユニットテストはsrc/test/javascript/specフォルダにあります。これらのテストはJestを使用します。
これらのテストはアプリケーションのRESTエンドポイントへのアクセスをモックアップするため、Javaバックエンドを起動せずにUIレイヤーをテストできます。
- これらのテストは
npm testを使用して実行できます。 - ヒント：1つのテス トに集中したい場合は、モジュールの記述を
describe('...', function() {からfdescribe('...', function() {に変更すると、Jestはこのテストのみを実行します。
Cypress/Protractor
UI統合テストは、CypressまたはProtractorで行われ、src/test/javascript/e2eフォルダにあります。
これらのテストでは、ブラウザを起動し、実際のユーザーと同じようにアプリケーションを使用するため、データベースを設定した実際のアプリケーションを実行する必要があります。
これらのテストは、npm run e2eを使用して実行できます。
アーキテクチャテスト
特定の制約とベストプラクティスを適用するアーキテクチャテストは、ArchUnitを使用して実行されます。 公式ドキュメントに従って、ビルド時にアーキテクチャのカスタム制約をチェックするための独自のルールを作成できます。
パフォーマンステスト
パフォーマンステストはGatlingで行われ、src/test/java/gatling/simulationsフォルダにあります。パフォーマンステストはエンティティごとに生成され、多数の同時リクエストで各エンティティをテストできます。
警告！ 現時点では、これらのテストではエンティティに適用した検証ルールが考慮されていません。また、別のエンティティと必要な関係を持つエンティティを作成するためのテストは、そのままでは失敗します。いずれにしても、ビジネス・ルールに従ってこれらのテストを変更する必要があるため、テストを改善するためのヒントをいくつか示します。
- 実行中のアプリケーションで、
管理 > ログ画面に移動し、org.springframeworkをdebugモードにします。例えば、検証エラーが表示されます。 - アプリケーションを通常に使用し、Chromeの
console logを開くと、HTTPヘッダーを含むすべてのパラメータを持つRESTのリクエストを確認できます。
マイクロサービスアプリケーションでGatlingテストを実行するには、次のことが必要です。
- レジストリの実行
- ゲートウェイの実行
- マイクロサービスアプリケーションの実行
- その後、Gatlingテストを実行できます
Mavenを使ってGatlingを実 行する
すべてのGatlingのテストは./mvnw gatling:testで実行できます。
Gradleを使ってGatlingを実行する
すべてのGatlingのテストは./gradlew gatlingRunで実行できます。
ビヘイビア駆動開発（BDD）
振る舞い駆動開発（BDD）は、CucumberとそのJVM実装を使用して利用できます。
Gherkinのfeatureは、src/test/featuresディレクトリに書き込む必要があります。