🙌
LINEヤフーのインターン参加してきました!

2024/10/21に公開
Jest
 はじめにこんにちは、きむです!
LINEヤフーのインターンで2週間お世話になってきたので、学びをアウトプットしたいと思います。
今回自分は、Vue.jsを使用したPayPayほけんの新規機能開発を行ってきました。このインターンに応募した理由は、普段の業務でもVue.jsを使用しており、高いレベルの環境で新しい知見を得られると考えたからです。

 何をしたのか
 入力フォームの作成最初のタスクは、入力フォームの作成&カスタムバリデーションを作るというものでした。この入力フォームには、
文字数の制限がある
アルゴリズムによって正しい値かどうかを検証することができる
という二つの特徴があり、バリデーションをつける必要がありました。VeeValidateというVueのバリデーションライブラリを使用していたため、1に関しては既存のルールを、2に関してはカスタムルールを新しく作成しました。

 テストコード作成続いて、先ほど説明した、カスタムルールのユニットテストと、作成した画面全体をテストする、インテグレーションテストを行いました。
バリデーションのユニットテストには、Jestというツールを使用しました。自分はあまりテストコードを書いたことがなく、「テストケースってどれくらい必要なんだろう...」状態でした。そこで、毎日のメンターさんとの1on1の時間に質問してみると、「分岐網羅を最低限の基準にしてやっているよ~」とアドバイスを頂きました。
ホワイトボックステストには、命令網羅、分岐網羅、条件網羅、複合条件網羅という4つの基準があることを知り、この基準を基にテストケースを考えました。(知らなかったので後で調べました)以下の記事がとてもわかりやすかったです！
https://qiita.com/odekekepeanuts/items/8b6542467d2a0066e5af
インテグレーションテストにはcypressというツールを使用しました。本来はE2Eテスト(エンドツーエンドテスト)で用いられることが多いようですが、今回はコンポーネントのテストで使用しました。具体的には、
画面が表示されたときは、ボタンが非活性になっている&エラー文が表示されている
文字を入力しても文字数が足りなければボタンが非活性&エラー文が表示されている
文字数が正しくてもアルゴリズムを満たしていないとボタンが非活性&エラー文が表示されている
などページの一連の流れを細かくテストしていきました。自分はインテグレーションテストやE2Eテストは手動でやるものだと思っていたので、自動化できるのか...と感動してました笑

 ファイルのアップロード機能3つ目はファイルのアップロード機能と、それに伴うstoreの構造変更(piniaを使用)です。ここまでは、ほかの実装個所を参考にすることで実装することができていましたが、このタスクはそうはいきませんでした。なぜなら、もともとファイルの情報を保持するためのstoreは存在していたものの、1枚のファイルしかアップロードすることができない構造となっていたためです。
1枚のファイルしか情報を保持できないとは以下のようなイメージです。(変数名は適当です)
export const useFileStore = defineStore('file', {
  state: () => (
    { fileName: 'aaaa', url: 'example.com' }
  ),
  getters: {
    url: (state) => state.url
  },
  actions: {
    updateFileName(fileName) {
      this.fileName = fileName;
    },
  },
})
単純にプロパティを増やす方法
state: () => ({
    fileName1: 'aaaaa',
    fileName2: 'bbbbb',
    url1: 'example1',
    url2: 'example2'
  }),
オブジェクトとして管理する方法
state: () => ({
    fileName: {
      fileName1: 'aaaaa',
      fileName2: 'bbbbb'
    },
    url: {
      url1: 'example1',
      url2: 'example2'
    }
  }),
配列で管理する方法
export interface countState {
    count: number;
    name: string;
}

...
state: () => ({
    countArray: [] as countState[]
  }),
最終的には、3番目の「配列で管理する方法」を採用しました。各方針のメリット・デメリットを、可読性や拡張性などの観点から考慮し、メンターさんと議論しながら意思決定することができたのは、とても楽しく、貴重な経験になりました。(ちなみに、stateの構造変更に伴って、gettersとactionsの引数にインデックスを持たせるなどの変更も必要でしたが、その際も何度もメンターさんに相談させていただきました🙌)

 何を学んだのか本当にたくさんのことを学ぶことができたのですが、特に大切だと感じたことを2つ挙げたいと思います。

 テストコードを書くことの重要性これまでに自分は、Ruby on RailsでRspecとFactory Botを使用したテストしか書いたことがなく、フロント側のテストコードを書くのは今回が初めてでした。普段からテストコードは書かずとも、PRを出す前に何度もチェックを行うという習慣がついており、今回も入力フォームの実装を終えた時点で「まぁ一応テストコードは書くけど、特に問題はないだろう」と若干高を括っていました。
ところが、カスタムバリデーションのテストコードを書いてみると、通るはずのテストが通らないという事態が発生しました。その原因を調査してみたところ、自分自身が書いたバリデーションのロジック部分にミスがあることが判明しました。
確かに、今回作成したページでは文字数制限があるため、実際の動作ではエラーは起こりえなかったのですが、別のフォームを作成した際にこのバリデーションを使用した場合、バグを仕込んでしまうリスクがあったと考えると、冷や汗がでました笑
テストコードを書くことの重要性を身をもって体感することができたこと、テストに関する知見が少し広がったのは個人的にすごくよかったなと感じます。(ちょうどテストを書いているときに、以下の記事を発見し、読ませていただきました!)
https://zenn.dev/coconala/articles/f048377f314507

 その実装を選択しない理由を明確に持つこと今回、自分自身の目標として、「複数の実装方針を挙げて、それぞれのメリット・デメリットを考慮して選択する」というものを掲げていました。ファイルのアップロード機能の際、stateの構造について複数の方針を検討したことを先ほどお話しましたが、それ以外にも、自分で実装方法を選択できるシーンが多々ありました。
その際に「とりあえずこれでいいか」とコードを書き始めるのではなく、ほかに考えられる実装方法はないのか、それぞれどのようなメリットとデメリットがあるのかを自分なりに精一杯思考することができました。これらをメンターさんに伝えることで、議論の土台を作ることができ、不要なコミュニケーションを省きつつ、より深い内容の対話ができたのかなと思っています。
メンターさんと議論をする中で特に印象に残っていることがあります。それは「なぜその実装が適さないのかを正確に言語化する」ということです。自分の場合は、例えばA案、B案、C案があって、A案がなんとなく良さそうだと感じた場合、B案とC案のデメリットを深く検討せず、「A案はこういう良さがあって、B案とC案は劣るよね」みたいな思考に陥りがちなことに気づきました。その状態で自分の意見をメンターさんのところに持っていくと、B案やC案の問題点を明確に指摘していただきました。
自分の中では十分に調査したつもりになっていても、考え切れていないことがたくさんある(もちろん経験の差によるものも大きいと思うが)ことを学ぶことができ、今後の開発ではこの点を意識していきたいと強く感じました。

 最後に2週間本当にお世話になりました!!基本的にはフルリモートだったのですが、最終日には出社してチームのメンバーでご飯に行くことができました!2週間を通して関わってくださった皆さんは本当に温かく、技術的なキャッチアップにも積極的でたくさんの刺激を受けることができる、最高の環境だなと感じました✨
このインターンに応募する前までは「まさか自分なんかがLINEヤフーのインターンなんていけないだろう」と思っていました。26卒以降の方でもしかしたら同じようなことを考えている方もいるかと思いますが、プロジェクトがたくさんあって、自分自身の強みがしっかりとアピールできれば参加するチャンスはあると思うので是非応募してみると良いと思います！
はじめに

何をしたのか

入力フォームの作成

テストコード作成

ファイルのアップロード機能

何を学んだのか

テストコードを書くことの重要性

その実装を選択しない理由を明確に持つこと

最後に

Discussion
