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?

【日記】Jest/Chakra/Typescript/Reactはおもろ難しい

Posted at

はじめに

私は34歳から本腰入れてプログラミングを勉強し始めたSEです。
JISOUでの学習課題に取り組む中で今まで触れてこなかった部分(JestやChakra)から、普段の業務の中で分かっていた気になっていただけのReactのことについて記事にしました。

作成したアプリ

課題アプリの開発はVite環境にてReact + TypeScritpで行いました。
レコーディング 2026-01-18 221404.gif

直面した問題

上記アプリの実装後、単体テストツールとしてJestによるテスト方法を学びました。Jestは存在だけ知っており基本構文などがからっきしだったので、Jestの書き方を覚えるだけだと思っていましたが、そう簡単にはいきませんでした。

Vite環境でJestが動かない...!

Vite + Typescript環境下で何もせずそのままJestを使おうとすると、以下のような問題が起きます。

  • Jestでは、import.meta.env()によるenvパラメータの読み込みができない
  • Jestが@エイリアスのパスを解析してくれない
  • structuredCloneといったnodeが提供する機能の型ファイルを見つけられない
  • JestはそもそもJavascript用のテストランナーなのでtsやtsxをテストしてくれない
    etc...

これらの問題は、tsconfig.jsonやjest.setup.tsなど、typescript側、jest側それぞれの設定に漏れがあることが原因です。
まずJestを使う前にこれらの問題を解決しなければなりません。解決方法の記事が上がっていたおかげで何とかなりましたが、各設定が何のためのものなのかということを理解する必要がありました。

Chakra V3のコンポーネントの型ファイルをJestが読み込んでくれない...!

Chakraを使いコンポーネントのUIはいい感じになった!よし、Jestでテスト実行...!あれ?型エラー?開発中はそんなのまったくでなかったのになぜ???

エラー内容
<Dialog.Content> 
Type '{ children: Element[]; }' has no properties in common 
with type 'IntrinsicAttributes & DialogContentProps & RefAttributes<HTMLDivElement>'.  

エラー原因はChakra V3とJestのモジュールシステムの違いと認識していますが、現時点でもまだ明確に原因の特定ができていません。
Vite環境下で利用するChakra V3はECMAScript Modules(ECS)で動作する前提となっている一方、JestはCommonJS(CJS)で動作する前提となっています。
あくまで推測ですが上記型エラーはJestがChakraの複雑な型定義の解釈を正常に動作できていないのではと考えています。
JestというよりCJSでは、Node.js でサポートされていない構文 (JSX、TypeScriptの型など) を対象にする場合、プレーンなJavaScriptに変換する必要があり、その変換内容をカスタマイズすることもできるとのこと。この設定をいじればどうにかすることができるのかもですが、いったん今回は他の方法で解決することに。
https://archive.jestjs.io/docs/ja/next/code-transformation

以下の記事に掲載されていたchildrenプロパティを追加する方法で型エラーはなくなりました。
https://qiita.com/ritsu21ctws/items/f2cc2af9d4b2cb580ada

ただこれが根本解決になっているかどうかは未熟のため判断ができません。もっと精進せねば。

testingLibraryで狙ったHTML要素が取得できない...!

テーブル一覧や入力フォームの値が想定通りかどうか確認するため、対象のHTML要素を取得する必要があります。
@testing-library/reactというreactアプリケーション向けのパッケージがあり、これも今回使うのが初めて。
取得するためのメソッドはいろいろと用意されていましたが、個人的にユーザ目線でテストできるということと、変更が少なそう(classやIDを指定すると開発中に変更される可能性が高い)という理由から、ByRole系の取得方法を優先的に使おうとしました。

当初この"Role"というのが、HTML要素のタグと1対1で紐づいていると思い、ガンガン使うとテスト結果が失敗ばかり...。
Roleの指定方法がおかしいのか、そもそもプロダクトコードが間違っているのか。その線引きからまずしなければならず、ゆっくりとしか解決ができない状態でした。
(ByRoleはクリアしても、今度はmockの理解が足りていないなど)

現在はいろいろと書き方を試したおかげでByRoleを使い狙ったHTML要素を取得できるようになりました。

単体テストの考え方が分かっていない...!

単体テストはプロダクトコードを追従し、いろんなパラメータパターンを網羅的に実施すればいい、と本心で思っていました。
もちろん上述は品質を担保する上で必要なことだと思います。

今回単体テストの初歩を学習する中で、単体テストは機能の動作確認ではなく、良いコードを設計するための工程だと教えていただきました。

今回実装~テストまでのカリキュラムの中で学ばせていただくことが多くありましたが、この単体テストの重要性を認識できたことが特に一番の収穫だと思っています。

さいごに

当然ですが難しいです。わからないことが何かを知ることから始め、解決方法を模索するので、時間もかかりました。
でもエラー原因が理解できた時、解決方法の糸口がわかった時などテンションが上がりますね。自分が思った通りに実装できることがうれしいですが、今の自分にとっては理解しながら開発ができていることに成長を感じています。

おそらくAIを使ったら一発で回答がくるような問題もありました。ただそれをやってしまうと解決はできたとしても従来通り、わかった気になっただけで何も変わらないと思っています。
AIに解決方法を求めず、自分の考えの相談役として利用していこうと思います。

JISOUのメンバー募集中!

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

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?