diff --git a/adev-ja/src/content/guide/routing/testing.en.md b/adev-ja/src/content/guide/routing/testing.en.md new file mode 100644 index 0000000000..5a1f2fe13d --- /dev/null +++ b/adev-ja/src/content/guide/routing/testing.en.md @@ -0,0 +1,341 @@ +# Testing routing and navigation + +Testing routing and navigation is essential to ensure your application behaves correctly when users navigate between different routes. This guide covers various strategies for testing routing functionality in Angular applications. + +## Prerequisites + +This guide assumes you are familiar with the following tools and libraries: + +- **[Jasmine](https://jasmine.github.io/)** - JavaScript testing framework that provides the testing syntax (`describe`, `it`, `expect`) +- **[Karma](https://karma-runner.github.io/)** - Test runner that executes tests in browsers +- **[Angular Testing Utilities](guide/testing)** - Angular's built-in testing tools ([`TestBed`](api/core/testing/TestBed), [`ComponentFixture`](api/core/testing/ComponentFixture)) +- **[`RouterTestingHarness`](api/router/testing/RouterTestingHarness)** - Test harness for testing routed components with built-in navigation and component testing capabilities + +## Testing scenarios + +### Route parameters + +Components often rely on route parameters from the URL to fetch data, like a user ID for a profile page. + +The following example shows how to test a `UserProfile` component that displays a user ID from the route. + +```ts +// user-profile.component.spec.ts +import { TestBed } from '@angular/core/testing'; +import { Router } from '@angular/router'; +import { RouterTestingHarness } from '@angular/router/testing'; +import { provideRouter } from '@angular/router'; +import { UserProfile } from './user-profile'; + +describe('UserProfile', () => { + it('should display user ID from route parameters', async () => { + TestBed.configureTestingModule({ + imports: [UserProfile], + providers: [ + provideRouter([ + { path: 'user/:id', component: UserProfile } + ]) + ] + }); + + const harness = await RouterTestingHarness.create(); + await harness.navigateByUrl('/user/123', UserProfile); + + expect(harness.routeNativeElement?.textContent).toContain('User Profile: 123'); + }); +}); +``` + +```ts +// user-profile.component.ts +import { Component, inject } from '@angular/core'; +import { ActivatedRoute } from '@angular/router'; + +@Component({ + template: '

User Profile: {{userId}}

' +}) +export class UserProfile { + private route = inject(ActivatedRoute); + userId: string | null = this.route.snapshot.paramMap.get('id'); +} +``` + +### Route guards + +Route guards control access to routes based on conditions like authentication or permissions. When testing guards, focus on mocking dependencies and verifying navigation outcomes. + +The following example tests an `authGuard` that allows navigation for authenticated users and redirects unauthenticated users to a login page. + +```ts +// auth.guard.spec.ts +import { RouterTestingHarness } from '@angular/router/testing'; +import { provideRouter, Router } from '@angular/router'; +import { authGuard } from './auth.guard'; +import { AuthStore } from './auth-store'; +import { Component } from '@angular/core'; +import { TestBed } from '@angular/core/testing'; + +@Component({ template: '

Protected Page

' }) +class ProtectedComponent {} + +@Component({ template: '

Login Page

' }) +class LoginComponent {} + +describe('authGuard', () => { + let authStore: jasmine.SpyObj; + let harness: RouterTestingHarness; + + async function setup(isAuthenticated: boolean) { + authStore = jasmine.createSpyObj('AuthStore', ['isAuthenticated']); + authStore.isAuthenticated.and.returnValue(isAuthenticated); + + TestBed.configureTestingModule({ + providers: [ + { provide: AuthStore, useValue: authStore }, + provideRouter([ + { path: 'protected', component: ProtectedComponent, canActivate: [authGuard] }, + { path: 'login', component: LoginComponent }, + ]), + ], + }); + + harness = await RouterTestingHarness.create(); + } + + it('allows navigation when user is authenticated', async () => { + await setup(true); + await harness.navigateByUrl('/protected', ProtectedComponent); + // The protected component should render when authenticated + expect(harness.routeNativeElement?.textContent).toContain('Protected Page'); + }); + + it('redirects to login when user is not authenticated', async () => { + await setup(false); + await harness.navigateByUrl('/protected', LoginComponent); + // The login component should render after redirect + expect(harness.routeNativeElement?.textContent).toContain('Login Page'); + }); +}); +``` + +```ts +// auth.guard.ts +import { inject } from '@angular/core'; +import { CanActivateFn, Router } from '@angular/router'; +import { AuthStore } from './auth-store'; + +export const authGuard: CanActivateFn = () => { + const authStore = inject(AuthStore); + const router = inject(Router); + return authStore.isAuthenticated() ? true : router.parseUrl('/login'); +}; +``` + +### Router outlets + +Router outlet tests are more of an integration test since you're essentially testing the integration between the [`Router`](api/router/Router), the outlet, and the components being displayed. + +Here's an example of how to set up a test that verifies different components are displayed for different routes: + +```ts +// app.component.spec.ts +import { TestBed } from '@angular/core/testing'; +import { RouterTestingHarness } from '@angular/router/testing'; +import { provideRouter } from '@angular/router'; +import { Component } from '@angular/core'; +import { App } from './app'; + +@Component({ + template: '

Home Page

' +}) +class MockHome {} + +@Component({ + template: '

About Page

' +}) +class MockAbout {} + +describe('App Router Outlet', () => { + let harness: RouterTestingHarness; + + beforeEach(async () => { + TestBed.configureTestingModule({ + imports: [App], + providers: [ + provideRouter([ + { path: '', component: MockHome }, + { path: 'about', component: MockAbout } + ]) + ] + }); + + harness = await RouterTestingHarness.create(); + }); + + it('should display home component for default route', async () => { + await harness.navigateByUrl(''); + + expect(harness.routeNativeElement?.textContent).toContain('Home Page'); + }); + + it('should display about component for about route', async () => { + await harness.navigateByUrl('/about'); + + expect(harness.routeNativeElement?.textContent).toContain('About Page'); + }); +}); +``` + +```ts +// app.component.ts +import { Component } from '@angular/core'; +import { RouterOutlet, RouterLink } from '@angular/router'; + +@Component({ + imports: [RouterOutlet, RouterLink], + template: ` + + + ` +}) +export class App {} +``` + +### Nested routes + +Testing nested routes ensures that both the parent and child components render correctly when navigating to nested URLs. This is important because nested routes involve multiple layers. + +You need to verify that: + +1. The parent component renders properly. +2. The child component renders within it. +3. Ensure that both components can access their respective route data. + +Here's an example of testing a parent-child route structure: + +```ts +// nested-routes.spec.ts +import { TestBed } from '@angular/core/testing'; +import { RouterTestingHarness } from '@angular/router/testing'; +import { provideRouter } from '@angular/router'; +import { Parent, Child } from './nested-components'; + +describe('Nested Routes', () => { + let harness: RouterTestingHarness; + + beforeEach(async () => { + TestBed.configureTestingModule({ + imports: [Parent, Child], + providers: [ + provideRouter([ + { + path: 'parent', + component: Parent, + children: [ + { path: 'child', component: Child } + ] + } + ]) + ] + }); + + harness = await RouterTestingHarness.create(); + }); + + it('should render parent and child components for nested route', async () => { + await harness.navigateByUrl('/parent/child'); + + expect(harness.routeNativeElement?.textContent).toContain('Parent Component'); + expect(harness.routeNativeElement?.textContent).toContain('Child Component'); + }); +}); +``` + +```ts +// nested-components.ts +import { Component } from '@angular/core'; +import { RouterOutlet } from '@angular/router'; + +@Component({ + imports: [RouterOutlet], + template: ` +

Parent Component

+ + ` +}) +export class Parent {} + +@Component({ + template: '

Child Component

' +}) +export class Child {} +``` + +### Query parameters and fragments + +Query parameters (like `?search=angular&category=web`) and URL fragments (like `#section1`) provide additional data through the URL that doesn't affect which component loads, but does affect how the component behaves. Components that read query parameters through [`ActivatedRoute.queryParams`](api/router/ActivatedRoute#queryParams) need to be tested to ensure they handle different parameter scenarios correctly. + +Unlike route parameters that are part of the route definition, query parameters are optional and can change without triggering route navigation. This means you need to test both the initial loading and the reactive updates when query parameters change. + +Here's an example of how to test query parameters and fragments: + +```ts +// search.component.spec.ts +import { TestBed } from '@angular/core/testing'; +import { Router, provideRouter } from '@angular/router'; +import { RouterTestingHarness } from '@angular/router/testing'; +import { Search } from './search'; + +describe('Search', () => { + let component: Search; + let harness: RouterTestingHarness; + + beforeEach(async () => { + TestBed.configureTestingModule({ + imports: [Search], + providers: [ + provideRouter([ + { path: 'search', component: Search } + ]) + ] + }); + + harness = await RouterTestingHarness.create(); + }); + + it('should read search term from query parameters', async () => { + component = await harness.navigateByUrl('/search?q=angular', Search); + + expect(component.searchTerm()).toBe('angular'); + }); +}); +``` + +```ts +// search.component.ts +import { Component, inject, computed } from '@angular/core'; +import { ActivatedRoute } from '@angular/router'; +import { toSignal } from '@angular/core/rxjs-interop'; + +@Component({ + template: '
Search term: {{searchTerm()}}
' +}) +export class Search { + private route = inject(ActivatedRoute); + private queryParams = toSignal(this.route.queryParams, { initialValue: {} }); + + searchTerm = computed(() => this.queryParams()['q'] || null); +} +``` + +## Best practices for router testing + +1. **Use RouterTestingHarness** - For testing routed components, use [`RouterTestingHarness`](api/router/testing/RouterTestingHarness) which provides a cleaner API and eliminates the need for test host components. It offers direct component access, built-in navigation, and better type safety. However, it isn't as suitable for some scenarios, such as testing named outlets, where you may need to create custom host components. +2. **Handle external dependencies thoughtfully** - Prefer real implementations when possible for more realistic tests. If real implementations aren't feasible (e.g., external APIs), use fakes that approximate the real behavior. Use mocks or stubs only as a last resort, as they can make tests brittle and less reliable. +3. **Test navigation state** - Verify both the navigation action and the resulting application state, including URL changes and component rendering. +4. **Handle asynchronous operations** - Router navigation is asynchronous. Use `async/await` or [`fakeAsync`](api/core/testing/fakeAsync) to properly handle timing in your tests. +5. **Test error scenarios** - Include tests for invalid routes, failed navigation, and guard rejections to ensure your application handles edge cases gracefully. +6. **Do not mock Angular Router** - Instead, provide real route configurations and use the harness to navigate. This makes your tests more robust and less likely to break on internal Angular updates, while also ensuring you catch real issues when the router updates since mocks can hide breaking changes. diff --git a/adev-ja/src/content/guide/routing/testing.md b/adev-ja/src/content/guide/routing/testing.md index 5a1f2fe13d..6b29344385 100644 --- a/adev-ja/src/content/guide/routing/testing.md +++ b/adev-ja/src/content/guide/routing/testing.md @@ -1,23 +1,23 @@ -# Testing routing and navigation +# ルーティングとナビゲーションのテスト -Testing routing and navigation is essential to ensure your application behaves correctly when users navigate between different routes. This guide covers various strategies for testing routing functionality in Angular applications. +ルーティングとナビゲーションのテストは、ユーザーが異なるルート間を移動する際にアプリケーションが正しく動作することを保証するために不可欠です。このガイドでは、Angularアプリケーションにおけるルーティング機能のテストに関する様々な戦略について説明します。 -## Prerequisites +## 前提条件 {#prerequisites} -This guide assumes you are familiar with the following tools and libraries: +このガイドは、以下のツールとライブラリに精通していることを前提としています。 -- **[Jasmine](https://jasmine.github.io/)** - JavaScript testing framework that provides the testing syntax (`describe`, `it`, `expect`) -- **[Karma](https://karma-runner.github.io/)** - Test runner that executes tests in browsers -- **[Angular Testing Utilities](guide/testing)** - Angular's built-in testing tools ([`TestBed`](api/core/testing/TestBed), [`ComponentFixture`](api/core/testing/ComponentFixture)) -- **[`RouterTestingHarness`](api/router/testing/RouterTestingHarness)** - Test harness for testing routed components with built-in navigation and component testing capabilities +- **[Jasmine](https://jasmine.github.io/)** - テスト構文（`describe`、`it`、`expect`）を提供するJavaScriptテストフレームワーク +- **[Karma](https://karma-runner.github.io/)** - ブラウザでテストを実行するテストランナー +- **[Angular Testing Utilities](guide/testing)** - Angularに組み込まれているテストツール（[`TestBed`](api/core/testing/TestBed)、[`ComponentFixture`](api/core/testing/ComponentFixture)） +- **[`RouterTestingHarness`](api/router/testing/RouterTestingHarness)** - 組み込みのナビゲーションとコンポーネントテスト機能を備えた、ルーティングされたコンポーネントをテストするためのテストハーネス -## Testing scenarios +## テストシナリオ {#testing-scenarios} -### Route parameters +### ルートパラメーター {#route-parameters} -Components often rely on route parameters from the URL to fetch data, like a user ID for a profile page. +コンポーネントは、プロフィールページのユーザーIDのように、URLからのルートパラメーターに依存してデータを取得することがよくあります。 -The following example shows how to test a `UserProfile` component that displays a user ID from the route. +以下の例は、ルートからユーザーIDを表示する`UserProfile`コンポーネントをテストする方法を示しています。 ```ts // user-profile.component.spec.ts @@ -60,11 +60,11 @@ export class UserProfile { } ``` -### Route guards +### ルートガード {#route-guards} -Route guards control access to routes based on conditions like authentication or permissions. When testing guards, focus on mocking dependencies and verifying navigation outcomes. +ルートガードは、認証や権限などの条件に基づいてルートへのアクセスを制御します。ガードをテストする際は、依存関係のモックとナビゲーションの結果の検証に焦点を当てます。 -The following example tests an `authGuard` that allows navigation for authenticated users and redirects unauthenticated users to a login page. +以下の例は、認証されたユーザーのナビゲーションを許可し、認証されていないユーザーをログインページにリダイレクトする`authGuard`をテストします。 ```ts // auth.guard.spec.ts @@ -131,11 +131,11 @@ export const authGuard: CanActivateFn = () => { }; ``` -### Router outlets +### ルーターアウトレット {#router-outlets} -Router outlet tests are more of an integration test since you're essentially testing the integration between the [`Router`](api/router/Router), the outlet, and the components being displayed. +ルーターアウトレットのテストは、本質的に[`Router`](api/router/Router)、アウトレット、および表示されるコンポーネント間の統合をテストしているため、より統合テストに近いものです。 -Here's an example of how to set up a test that verifies different components are displayed for different routes: +異なるルートに対して異なるコンポーネントが表示されることを検証するテストを設定する方法の例を以下に示します。 ```ts // app.component.spec.ts @@ -204,17 +204,17 @@ import { RouterOutlet, RouterLink } from '@angular/router'; export class App {} ``` -### Nested routes +### ネストされたルート {#nested-routes} -Testing nested routes ensures that both the parent and child components render correctly when navigating to nested URLs. This is important because nested routes involve multiple layers. +ネストされたルートをテストすることで、ネストされたURLにナビゲートしたときに親コンポーネントと子コンポーネントの両方が正しくレンダリングされることを保証します。ネストされたルートは複数のレイヤーを含むため、これは重要です。 -You need to verify that: +以下を確認する必要があります。 -1. The parent component renders properly. -2. The child component renders within it. -3. Ensure that both components can access their respective route data. +1. 親コンポーネントが適切にレンダリングされること。 +2. 子コンポーネントがその内部にレンダリングされること。 +3. 両方のコンポーネントがそれぞれのルートデータにアクセスできることを確認すること。 -Here's an example of testing a parent-child route structure: +親子のルート構造をテストする例を以下に示します。 ```ts // nested-routes.spec.ts @@ -274,13 +274,13 @@ export class Parent {} export class Child {} ``` -### Query parameters and fragments +### クエリパラメーターとフラグメント {#query-parameters-and-fragments} -Query parameters (like `?search=angular&category=web`) and URL fragments (like `#section1`) provide additional data through the URL that doesn't affect which component loads, but does affect how the component behaves. Components that read query parameters through [`ActivatedRoute.queryParams`](api/router/ActivatedRoute#queryParams) need to be tested to ensure they handle different parameter scenarios correctly. +クエリパラメーター（`?search=angular&category=web`など）とURLフラグメント（`#section1`など）は、どのコンポーネントがロードされるかには影響しませんが、コンポーネントの動作には影響を与える追加データをURLを通じて提供します。[`ActivatedRoute.queryParams`](api/router/ActivatedRoute#queryParams)を通じてクエリパラメーターを読み取るコンポーネントは、異なるパラメーターシナリオを正しく処理することを確認するためにテストする必要があります。 -Unlike route parameters that are part of the route definition, query parameters are optional and can change without triggering route navigation. This means you need to test both the initial loading and the reactive updates when query parameters change. +ルート定義の一部であるルートパラメーターとは異なり、クエリパラメーターはオプションであり、ルートナビゲーションをトリガーすることなく変更できます。これは、初期ロードと、クエリパラメーターが変更されたときのリアクティブな更新の両方をテストする必要があることを意味します。 -Here's an example of how to test query parameters and fragments: +クエリパラメーターとフラグメントをテストする方法の例を以下に示します。 ```ts // search.component.spec.ts @@ -331,11 +331,11 @@ export class Search { } ``` -## Best practices for router testing +## ルーターテストのベストプラクティス {#best-practices-for-router-testing} -1. **Use RouterTestingHarness** - For testing routed components, use [`RouterTestingHarness`](api/router/testing/RouterTestingHarness) which provides a cleaner API and eliminates the need for test host components. It offers direct component access, built-in navigation, and better type safety. However, it isn't as suitable for some scenarios, such as testing named outlets, where you may need to create custom host components. -2. **Handle external dependencies thoughtfully** - Prefer real implementations when possible for more realistic tests. If real implementations aren't feasible (e.g., external APIs), use fakes that approximate the real behavior. Use mocks or stubs only as a last resort, as they can make tests brittle and less reliable. -3. **Test navigation state** - Verify both the navigation action and the resulting application state, including URL changes and component rendering. -4. **Handle asynchronous operations** - Router navigation is asynchronous. Use `async/await` or [`fakeAsync`](api/core/testing/fakeAsync) to properly handle timing in your tests. -5. **Test error scenarios** - Include tests for invalid routes, failed navigation, and guard rejections to ensure your application handles edge cases gracefully. -6. **Do not mock Angular Router** - Instead, provide real route configurations and use the harness to navigate. This makes your tests more robust and less likely to break on internal Angular updates, while also ensuring you catch real issues when the router updates since mocks can hide breaking changes. +1. **RouterTestingHarnessを使用する** - ルーティングされたコンポーネントをテストするには、よりクリーンなAPIを提供し、テストホストコンポーネントの必要性を排除する[`RouterTestingHarness`](api/router/testing/RouterTestingHarness)を使用してください。これは、直接的なコンポーネントアクセス、組み込みのナビゲーション、およびより優れた型安全性を提供します。ただし、名前付きアウトレットのテストなど、カスタムホストコンポーネントを作成する必要がある一部のシナリオには適していません。 +2. **外部の依存関係を慎重に処理する** - より現実的なテストのために、可能な場合は実際の実装を優先してください。実際の実装が実現不可能な場合（例：外部API）は、実際の動作を近似するフェイクを使用してください。モックやスタブは、テストを脆弱にし、信頼性を低下させる可能性があるため、最後の手段としてのみ使用してください。 +3. **ナビゲーション状態をテストする** - URLの変更やコンポーネントのレンダリングを含む、ナビゲーションアクションと結果として生じるアプリケーション状態の両方を検証してください。 +4. **非同期操作を処理する** - ルーターのナビゲーションは非同期です。テストでのタイミングを適切に処理するために、`async/await` または [`fakeAsync`](api/core/testing/fakeAsync) を使用してください。 +5. **エラーシナリオをテストする** - アプリケーションがエッジケースを適切に処理することを確認するために、無効なルート、失敗したナビゲーション、およびガードによる拒否のテストを含めてください。 +6. **Angularルーターをモックしない** - 代わりに、実際のルート設定を提供し、ハーネスを使用してナビゲートしてください。これにより、テストがより堅牢になり、Angularの内部更新で壊れる可能性が低くなります。また、モックは破壊的変更を隠す可能性があるため、ルーターが更新されたときに実際の問題を確実に捕捉できます。