Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

結合テストを導入 #697

Open
wants to merge 9 commits into
base: main
Choose a base branch
from
Open

結合テストを導入 #697

wants to merge 9 commits into from

Conversation

HosokawaR
Copy link
Member

@HosokawaR HosokawaR commented May 4, 2023

背景

Resolves #689

変更点

この Issue では結合テストの導入までをスコープとし、テストの追加は最小限にします。
理由は出戻りを最小限にするために、導入に問題がないかを確かめることができる最小限の変更にとどめたいからです。

@vercel
Copy link

vercel bot commented May 4, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
twinte-front-staging ✅ Ready (Inspect) Visit Preview 💬 Add feedback May 5, 2023 7:51am

await expect(page.locator(".table")).toContainText("ダミー講義名");
});

test("検索結果の詳細と簡易を切り替えられる", async ({ page }) => {
Copy link
Member Author

@HosokawaR HosokawaR May 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Twin:te ではソースコード中のコメントなどが英語で書かれていますが、テストではなるべく日本語で書きたいと思います。理由は以下です。

  • 結合テストは UI と結びつきが強いので、UI で使われている言語と同じ言語を使うほうが便利
    • 例えば「詳細」「簡易」などは「詳細」「簡易」と書かれたボタンがあるのでわかりやすいですが、これを英語にすると UI のどの部分を指しているのかがわかりにくくなります
  • テストにおいてはテスト名やコメントが重要になるので、英語の時制や主体の間違いで大きく影響がでてしまうリスクがあるので日本語で書きたい

@HosokawaR HosokawaR marked this pull request as ready for review May 5, 2023 07:59
@HosokawaR HosokawaR requested a review from hayato24s May 5, 2023 07:59
@hayato24s
Copy link
Contributor

RepositoryをInterfaceを使用して抽象化しているため、APIをモックするというよりはRepositoryをモックした方が良いと思います。つまり、InMemoryで動くRepositoryをテスト用のRepositoryとして使用するのが良いかと。

また、それに伴って、本番環境などではapiを使用したRepositoryをテスト環境ではInMemoryで動作するRepositoryを自動で割り当ててくれるようなDIツールの導入も行った方が良いかもしれません。

以上を踏まえて、実施すべきテストは主に以下の2点になるかと思います。

  • RepositoryのInterfaceに対するUnit Test(jest)
  • frontend全体に対する結合テスト or E2Eテスト(playwright or vitest)
    • Repositoryを切り替えることでテスト時のバックエンドとの連携の有無を設定できると思います。

vitestというvue.js公式がおすすめしているツールがあったので共有しておきます。
また、下記のリンクはvue.jsでのテストに関する記事です。

@HosokawaR
Copy link
Member Author

HosokawaR commented May 5, 2023

RepositoryをInterfaceを使用して抽象化しているため、APIをモックするというよりはRepositoryをモックした方が良いと思います。つまり、InMemoryで動くRepositoryをテスト用のRepositoryとして使用するのが良いかと。

今回追加したいのはフロントエンドの範囲内においてユーザの行動フローの完遂を保証する結合テストという認識です。
そのため「フロントエンドの範囲内でなるべく結合してテストする」ことが重要だと考えています。
しかし、Repository をモックすると Production ( = Develop ではない)Repository のテストや、axios や aspida などのテストができなくなり、前述の目的が達成できないと考えています。

以上を踏まえて、実施すべきテストは主に以下の2点になるかと思います。
RepositoryのInterfaceに対するUnit Test(jest)
frontend全体に対する結合テスト or E2Eテスト(playwright or vitest)
Repositoryを切り替えることでテスト時のバックエンドとの連携の有無を設定できると思います。

そして、これらの 2 つのテストを分割するのではなく、Reposoitory も含めて結合してテストしたいと考えています。

この観点についてはいかがでしょうか?

@HosokawaR
Copy link
Member Author

ありがとうございます!
いいですね、単体テスト等で使えないか見てみます!

vitestというvue.js公式がおすすめしているツールがあったので共有しておきます。
また、下記のリンクはvue.jsでのテストに関する記事です。

https://ja.vuejs.org/guide/scaling-up/testing.html#component-testing

@hayato24s
Copy link
Contributor

@HosokawaR

しかし、Repository をモックすると Production ( = Develop ではない)Repository のテストや、axios や aspida などのテストができなくなり、前述の目的が達成できないと考えています。

説明が下手でした。すみません。
Repositoryをモックするのではなく、InMemoryで動作するRepositoryを使用してfrontend全体に対するテストを行うという認識です。

axiosなどを使用したRepositoryに対する動作確認はRepositoryに対する単体テストで対応しようと思っています。

ですので、playwrightを使用してモックを作成する必要は基本的にはないかと思います。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

結合テストの導入
2 participants