0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【デジタル名刺アプリ作成】Vitestへの切り替えと単体テストの重要性

Posted at

はじめに

JISOUでのアプリ作成課題の3つ目としてデジタル名刺アプリを開発しましたのでその中で学んだことや感じたことをまとめました。

アプリ紹介

レコーディング 2026-01-27 185532.gif

課題アプリ開発の中で学んだこと

JestからVitestへの移行

課題1と2ではJestを使っていましたが今回からVitestを使うようにしました。Vite環境なのでVitestと相性が良いという理由と、シンプルに使ってみたかったからです。

VitestはESMで動作できるので、Viteサーバー上でテストをするという点では、Jestと比べると圧倒的に設定が楽に感じました。
JestはCJSで動作するので、UIコンポーネントのChakraの型ファイルを読みに行けなかったり、import.meta.envを参照できないなど、ややかゆいところに手が届かない印象がありました。

Vitestの方が実行速度が速いということでしたが、今回はシンプルな試験が多かったので、Jestよりもすごいとは感じませんでした。

supabaseの制約

Postgresを利用できるので普段の業務で使っている自分にとってはとてもとっつきやすかったです。まだ使い始めたばかりですが、アプリ側からSQLを投げる際の記述で少し戸惑いが多かったです。

アプリ側から記述する際にはトランザクション的な構文が無いので、supabase側でストアドプロシージャを記載する必要があるなど。(でもよく考えれば通常のDBリクエストもそうなので、この部分はsupabaseを神格化しすぎていただけでもあります。)

制約というよりは慣れが必要な部分ですね。supabaseの案件になったらもっと積極的にいろんな記述を勉強します。
(その前にDB設計の勉強もしたい…!)

UIコンポーネントのメリデメ

今回もChakra V3を使ってスタイルを構築しました。

メリット

  • 統一感のあるいい感じのスタイルがすぐに実装できる
  • レイアウトパターンも豊富
  • justify-contentやwidthを略称で指定できる

おしゃれなデザインをほぼコピペで実装できるのはとてもありがたいですね。なんかダサいというところからひとまず脱却できるので、ドメインロジックに集中できる部分ではあります。
またよく使うcssプロパティには略称があるので、コード記述量も少し減ります。

デメリット

  • 公式ページの記載が少ない
  • 他ライブラリと併用したい際の調査に時間がかかる

使いやすいとは思いますが自分が個人開発する場合は、tailwindcssを使うと思います。理由は上記デメリットです。
公式ページにソースサンプルはあるのですが、各コンポーネントの用途が何なのかなどの記載は少なかったです。今回React-hook-formと併用したのですが、そういった場合の記述はありました。
ですが、Vitestでテストする際にselectのchangeイベントが発火しないなど、タイポなのかChakraの仕様なのかの切り分けに時間がかかりました。

UIコンポーネントの提供で時短になりますが、レスポンシブにしたいとかちょっと変わったレイアウトにしたい時など、Chakra特有のルールに時間がとられてしまうと思うので、個人で開発するにはtailwindcssがいいなと感じました。

GithubActionsのスケジュール実行

普段の業務でGithubActionsをよく目にするのですが、自分で構築したことが無いため大変勉強になりました。CI/CDはまだまだ勉強不足で、現状はテストをしてデプロイして、という基本的なことしかできません。
AWSなどが入ってくれば難易度は各段に上がると思うので、もっと実践投入してみようと思います。

単体テストの目的と意味

今回の課題ではないのですが、JISOU代表の渡邉さんより紹介していただいた以下書籍が大変勉強になりました。
単体テストの考え方/使い方

一部内容を紹介しますと以下のようなことが書かれています。

  • 単体テストの目的はなにか
  • 良い単体テストとはなにか
  • 単体テスト作成からアプリの設計を考える方法

単体テストはソースコードが動いているか確認さえできれば良いと思っていたのですが、この書籍を読んで考え方が変わりました。
長くわかりにくいソースコードが嫌いな自分にとって、どうしたらわかりやすいソースコードをかけるのか、その指標としても単体テストが役に立つと感じました。
あと影響を受けた部分として、Vitestでの書き方も変わりました。前まではByRoleなどソースの構成を重視してテストコードを書いていました。
(tableのroleを指定して、querySelectorで取得、といった感じです。)

ただこれだとソースコードに依存した書き方であり、振る舞いを検証する単体テストには不向きな書き方でした。(ソースコードに依存した書き方は、リファクタリングする度にテストコードも直さないといけなくなります)

あくまで振る舞いを検証するので、そのあたりを意識するようになれたのは今回気付けて良かったと思う一番の点です。

おわりに

内容はまだまだですが、少しずつアウトプットになれてきたような気がします。動いているソースコードが何なのか、このプロパティやメソッドは何のためにあるのかなど理解できた瞬間が今の自分にとってはとても楽しいです。

JISOUのメンバー募集中!

プログラミングコーチングJISOUでは、新たなメンバーを募集しています。
日本一のアウトプットコミュニティでキャリアアップしませんか?
興味のある方は、ぜひホームページをのぞいてみてください!
▼▼▼

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?