ユニットテスト環境を導入

commit c5519e8
Author: oki07 <takashi.oki@uzabase.com>
Date:   Mon Oct 21 22:07:52 2024 +0900

    sp-buttonに無効なicon属性を設定したときの仕様が定まっていないため、一旦そのテストケースを削除

commit 57e8f82
Author: oki07 <takashi.oki@uzabase.com>
Date:   Sun Oct 20 15:51:27 2024 +0900

    CONTRIBUTING.mdを追加

commit c8c56e3
Author: oki07 <takashi.oki@uzabase.com>
Date:   Fri Oct 18 22:24:38 2024 +0900

    型チェック時に、依存ライブラリの中身までチェックしないように設定

commit 6f096a2
Author: oki07 <takashi.oki@uzabase.com>
Date:   Fri Oct 18 22:21:53 2024 +0900

    品質チェック用のGitHub Actionsワークフローを追加

commit ec0d211
Author: oki07 <takashi.oki@uzabase.com>
Date:   Fri Oct 18 22:21:33 2024 +0900

    prettierでフォーマットチェックするスクリプトを追加

commit cd4f5df
Author: oki07 <takashi.oki@uzabase.com>
Date:   Fri Oct 18 22:21:16 2024 +0900

    formatスクリプトとvscodeのprettier拡張機能のフォーマット結果が同じになるようにする

commit cf28d7e
Author: oki07 <takashi.oki@uzabase.com>
Date:   Fri Oct 18 22:12:06 2024 +0900

    Vitestを導入して、sp-buttonのテストを追加

.github/workflows/ci.yml

@@ -0,0 +1,17 @@
+name: CI
+
+on: push
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 20
+      - run: npm ci
+      - run: npm run format:prettier:check
+      - run: npm run format:lint
+      - run: npm run typecheck
+      - run: npm test

.prettierrc.json

@@ -0,0 +1,3 @@
+{
+  "trailingComma": "all"
+}

CONTRIBUTING.md

@@ -0,0 +1,75 @@
+# コントリビュート
+
+## 開発環境の準備
+
+開発を始めるには、リポジトリをクローンし、必要な依存パッケージをインストールしてください。パッケージマネージャーには[npm](https://www.npmjs.com/)を使用しています。
+
+```sh
+git clone git@github.com:uzabase/sp-design-components-web-components.git
+cd sp-design-components-web-components
+npm install
+```
+
+## テスト
+
+### テストの実行
+
+テストを実行するには、以下のコマンドを使用してください。
+
+```sh
+npm test
+```
+
+### ユニットテストの方針
+
+このリポジトリでは、[Vitest](https://vitest.dev/)を使ったユニットテストを導入しています。新しいコンポーネントを追加する際は、この方針に従ってユニットテストも作成してください。
+
+テストファイルは、`tests`ディレクトリ内に配置します。例えば、コンポーネントの実装ファイルが`src/components/button/sp-button.ts`の場合、対応するテストファイルは`tests/components/button/sp-button.test.ts`となります。
+
+テストケースを作成するときは、コンポーネントがどのように利用されるかを考慮してください。以下の点を参考にしてみてください。
+
+#### 属性のテスト
+
+Web ComponentsによるUIコンポーネントでは、利用者がコンポーネントの振る舞いを制御するために属性が使用されることが多いでしょう。そのため、属性を設定したときの振る舞いを確認するテストは重要だと考えられます。
+
+具体的には、以下のような状況についてのテストがあると良いでしょう。
+
+- 属性を設定した場合
+- 属性を設定しない場合
+  - 例えば、属性が存在しないときはデフォルトの状態になる仕様であれば、そのことを確認する
+- 属性を更新した場合
+  - 更新前の状態が残っておらず、正しく更新されていることを確認する
+- 特定の文字列のみを受け付ける属性に無効な値を設定した場合
+  - 例えば、`type`属性が`default`もしくは`destructive`のみを受け付ける場合、それ以外の値を設定した場合の状態を確認する
+
+これらの状況において、コンポーネントの振る舞いが正しいことを確認するテストを作成してください。例えば、以下のような振る舞いがあるかもしれません。
+
+- 属性値が画面上に表示される
+- コンポーネント内の要素に、特定のクラスが追加される
+- コンポーネント内の他の属性に、特定の値が設定される
+
+#### イベントのテスト
+
+TODO: コンポーネントのインタラクティブな機能には、イベントを利用することが多いでしょう。そのため、イベントのテストも重要だと考えられます。イベントのテスト方針については、今後検討し追加する予定です。
+
+#### 書くべきではないテスト
+
+以下のようなテストは、避けるようにしてください。
+
+- コンポーネントの描画結果に対するテスト
+  - 例えば、CSSスタイルのテストは避けてください。描画結果をテストする場合は、Visual Regression Testingなどを検討すると良いでしょう。
+- コンポーネントの責務以外に対するテスト
+  - 例えば、テスト対象となるコンポーネントが、内部で別のコンポーネントを利用している場合、その内部コンポーネントの責務に対するテストは避けてください。また、ブラウザの仕様（スクロールやリサイズなど）に依存するテストも避けてください。
+- コンポーネントの内部構造に強く依存するテスト
+  - 例えば、DOMの構造をチェックするテストは避けてください。コンポーネントの内部構造はリファクタリングなどで簡単に変更される可能性があり、その度にテストを修正する必要が生じます。振る舞いが変わらない限り、テストを修正する必要がないことが望ましいです。
+
+## CI
+
+このリポジトリでは、[GitHub Actions](https://github.com/features/actions)を利用して以下のようなチェックを行っています。
+
+- [Prettier](https://prettier.io/)によるコードのフォーマットチェック
+- [Stylelint](https://stylelint.io/)によるCSSのリントチェック
+- TypeScriptコードのコンパイルチェック
+- [Vitest](https://vitest.dev/)によるユニットテスト
+
+上記のいずれかのチェックに失敗した場合は、コードを修正してください。

README.md

@@ -1,3 +1,9 @@
-# storybook
+# sp-design-components-web-components
+
+## storybook
 
 [Here](https://uzabase.github.io/sp-design-components-web-components/)
+
+## コントリビュート
+
+開発に関するガイドラインは[CONTRIBUTING.md](CONTRIBUTING.md)を参照してください。