この記事は、次のような場合に注目してください。 高品質のソフトウェアを作成することに情熱を持っており、テストによってアプリの安定性を強化したいと考えています。 実稼働システムに予期せぬバグが発生することにうんざりしています。 自動テストとは何か、またそのアプローチ方法を理解するのに助けが必要です。 なぜ自動テストが必要なのでしょうか? 私たちはエンジニアとして、 たいと考えていますが、新しい機能を作成するたびに、必然的にアプリのサイズと複雑さが増大します。 機能する ものを構築し 製品が成長するにつれて、変更によって影響を受けるすべての機能を (手などで) テストするのはますます時間がかかります。 手動で 自動テストがないため、時間がかかりすぎて出荷速度が低下するか、速度を維持するためにあまりにも費用がかかりすぎて、PagerDuty からの深夜の電話とともにバックログに新たなバグが発生することになります。 逆に、 。そこで、 コンピュータは同じことを繰り返し行うようにプログラムすることができます テストをコンピューターに委任しましょう。 テストの種類 が提案されています。あらゆる種類を深く掘り下げて、それぞれが必要な理由を理解しましょう。 テスト ピラミッドのアイデアでは、 単体テスト、統合テスト、エンドツーエンド テストという 3 つの主要なタイプのテスト 単体テスト 、(他のコンポーネントに依存せずに) でテストする小さなロジックです。 ユニットは 単独 数秒以内に完了します。 依存するサービスを起動したり、API やデータベースの呼び出しを行ったりすることなく、いつでもローカルおよび CI 上で実行できます。 単体テストは高速です。 分離により、 2 つの数値を受け取り、それらを合計する関数。別の引数を指定して呼び出して、戻り値が正しいことをアサートしたいと考えています。 単体テストの例: // Function "sum" is the unit const sum = (x, y) => x + y test('sums numbers', () => { // Call the function, record the result const result = sum(1, 2); // Assert the result expect(result).toBe(3) }) test('sums numbers', () => { // Call the function, record the result const result = sum(5, 10); // Assert the result expect(result).toBe(15) }) さらに興味深い例は、API リクエストの終了後にテキストをレンダリングする React コンポーネントです。 API モジュールをモックしてテストに必要な値を返し、コンポーネントをレンダリングし、レンダリングされた HTML に必要なコンテンツが含まれていることをアサートする必要があります。 // "MyComponent" is the unit const MyComponent = () => { const { isLoading } = apiModule.useSomeApiCall(); return isLoading ? <div>Loading...</div> : <div>Hello world</div> } test('renders loading spinner when loading', () => { // Mocking the API module, so that it returns the value we need jest.mock(apiModule).mockReturnValue(() => ({ useSomeApiCall: jest.fn(() => ({ // Return "isLoading: false" for this test case isLoading: false })) })) // Execute the unit (render the component) const result = render(<MyComponent />) // Assert the result result.findByText('Loading...').toBeInTheDocument() }) test('renders text content when not loading', () => { // Mocking the API module jest.mock(apiModule).mockReturnValue(() => ({ useSomeApiCall: jest.fn(() => ({ // Return "isLoading: false" for this test case isLoading: false })) })) // Execute the unit (render the component) const result = render(<MyComponent />) // Assert the result result.findByText('Hello world').toBeInTheDocument() }) 結合テスト あなたの 他の を、私たちは 呼びます。これらのテストは単体テストよりも時間がかかりますが、アプリの各部分がどのように接続されるかをテストします。 ユニットが ユニットと相互作用すること (依存関係) 統合と データベースにユーザーを作成するサービス。これには、テストの実行時に DB インスタンス ( ) が使用可能である必要があります。サービスが DB からユーザーを作成および取得できることをテストします。 統合テストの例: 依存関係 import db from 'db' // We will be testing "createUser" and "getUser" const createUser = name => db.createUser(name) // creates a user const getUser = name => db.getUserOrNull(name) // retrieves a user or null test("creates and retrieves users", () => { // Try to get a user that doesn't exist, assert Null is returned const nonExistingUser = getUser("i don't exist") expect(nonExistingUser).toBe(null); // Create a user const userName = "test-user" createUser(userName); // Get the user that was just created, assert it's not Null const user = getUser(userName); expect(user).to.not.be(null) }) エンドツーエンドのテスト これは、 テストするときの テストであり、そのすべての依存関係が利用可能です。これらのテストは、実際のユーザーの動作を最もよくシミュレートし、アプリ内で を捕捉できますが、 タイプのテストです。 完全にデプロイされたアプリを エンドツーエンドの 考えられるすべての問題 最も遅い エンドツーエンドのテストを実行する場合は、すべてのインフラストラクチャをプロビジョニングし、環境内でサードパーティのプロバイダーが利用可能であることを確認する必要があります。 これらは、アプリの 機能のために 必要です。 ミッションクリティカルな のみ 。アプリにアクセスし、ログインの詳細を入力して送信し、ウェルカム メッセージを確認します。 エンドツーエンドのテスト例、ログイン フローを見てみましょう test('user can log in', () => { // Visit the login page page.goto('https://example.com/login'); // Fill in the login form page.fill('#username', 'john'); page.fill('#password', 'some-password'); // Click the login button page.click('#login-button'); // Assert the welcome message is visible page.assertTextVisible('Welcome, John!') }) どのような種類のテストを作成するかをどのように選択しますか? 、 に注意してください。 エンドツーエンド テストは統合テストよりも遅く 統合テストは単体テストよりも遅いこと 取り組んでいる機能がミッションクリティカルである場合は、少なくとも 1 つの テストを作成することを検討してください (認証フローの開発時にログイン機能がどのように動作するかを確認するなど)。 エンドツーエンド ミッションクリティカルなフローに加えて、できるだけ多くのエッジケースと機能のさまざまな状態をテストしたいと考えています。 アプリの各部分がどのように連携して動作するかをテストできます。 統合テストを使用すると、 エンドポイントは操作を実行し、期待どおりの結果を生成し、予期しないエラーをスローしない必要があります。 エンドポイントとクライアント コンポーネントの統合テストを行うことは良い考えです。 クライアント コンポーネントは、正しいコンテンツを表示し、ユーザーの応答に期待どおりに応答する必要があります。 最後に、いつ を選択すべきでしょうか?数値を合計する や タグをレンダリングする など、個別にテストできる小さな関数はすべて、単体テストの優れた候補です。 アプローチに従えば、単元は完璧です。 単体テスト sum <button> Button テスト駆動開発 次は何ですか？ （ただし、小さなことから始めてください） いくつかのテストを書いてみましょう！ プロジェクト/言語に合った 。各言語には、JavaScript 用の / 、エンドツーエンド用の / (JavaScript も使用)、Java 用の など、テスト用の一般的なライブラリがあります。 テスト フレームワークをインストールします Jest Vitest Cypress Playwright JUnit プロジェクト内で小さな関数を見つけて、その を作成します。 単体テスト コンポーネント/サービスとデータベースの相互作用のための テストを作成します。 統合 簡単なログイン フローなど、すぐにテストできる重要なシナリオを選択し、そのための テストを作成します。 エンドツーエンド 仕組みを理解するために、上記のことを一度実行してください。その後、機能やバグの作業中にもう一度実行します。それを同僚と共有すれば、全員がテストを作成し、時間を節約し、夜の睡眠を良くすることができます。 役立つリソース: 私の 個人的なブログ 著 Ham Vocke 「実技試験ピラミッド」 by テスト駆動開発 Martin Fowler
