# 2021/03/14 メンター相談

###### tags: `メンター相談`,`3月`

---
### 1.`describe` や `it` の切り分け方について、分け方の方針などはありますか？

[質問全文]
https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recbSg7zAzMzjkCLD

[解答]
describeやitに書いた内容は、そのままテスト結果に出てくるので書き過ぎると分かりづらくなります。
そのため、prahaでは３階層でテストを書いています。
また、itのプレフィックスに()で異常系などが識別できるように書いたりすることもあります。

１階層：ファイル名／２階層：メソッド名／３階層 it(テスト内容)

prahaではitをグルーピングするなどはやったことはないですが、やるのはありかと思いました。
グルーピングして階層化したテンプレーをチームに配布することで抜け漏れなども防げそう。

--

複雑な対象の説明が長くなるのは仕方ない。
過去のテストでは、テストだけで1,000行近くなったこともありました。

--
jestだとjavaDocのようにかけるか？
書けた気はしますが、自分はitに具体的な中身は書かない (仕様が変わった時に修正が大変なので)
例えば、足し算機能のテストコードに「3+5=8」と書くのではなく「足し算が正常に完了する」など抽象化した内容としている。
ここは流派によるかもしれません。

テスト内容は、基本はソースコードに書いており、別のドキュメントは用意してません。
（ドキュメントを外に出す場合は、また違ってくるかもしれない）

prahaはあまりドキュメントを書かない文化

---
### 2.「結果が1000より大きい場合は "too big" という文字列を返す」 のテスト構造について

[質問全文]
https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recPBeUWKgFzM9vs4

[解答]
自分ならAの方にいれちゃうかなと思います。

---
### 3.フロントエンドの開発でTDDは導入されていますか？
[質問全文]
https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recJmXaSu6HFz7glJ

[解答]
これまでやったことはない。
フロントエンドのTDD導入は優先度を低く考えており、
実際にコスパも合わないため、やっていない。（サーバを優先）
（優先度が低い理由）
　・すぐ気づける（サーバは気づきにくい）
　・すぐに直せる（マイグレーションなどがないため、データ生合成などが発生しない）
　・致命的になりづらい（上記と同様）
　・フロントエンドは、サーバーエンドより変更回数が多く、テストが壊れやすい

プロジェクトの作りによるが、PrAhaではロジックと見た目を完全に分けている。
ロジックはHooksにまてめており、Hooksのテストはしっかり書いている。
（切り離したロジックの部分のみテストしている）

---
### 4.浮動小数点を扱う場合、テスト時に toBeCloseTo の近似桁数を考慮しないといけないと思うが、どのような判断基準で近似桁数を指定しているのでしょうか？
[質問全文]
https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recUgXxfFXQBMNS74

[解答]
今までここまで細かい桁数を扱うシステムに関わったことはないです。
過去関わったM&Aのシステムでは数百億規模を扱うプロジェクトでしたが、万円以下はいらないなどの仕様に落ち着いていました。

もし、扱う場合はMath.Roudnなどで削ってしまって計算に仕様するかなと思います。
（実務での使用実績はない）

また、金融などではjavascriptは使わないかも、取引所などではC++などを使っているかもしれません。
そのため、javascript開発では、そこまで気にしなくても良さそう。

---
### 5.Storybookを導入した際に自動生成されたButton.jsを確認してみると、PropsにCSSのスタイルを追加していました。この形式だとCSSの属性が増えていくごとにPropsが肥大化しそうな印象ですが、実際にはどのように子コンポーネントに動的にスタイル情報を渡しているのでしょうか？
[質問全文]
https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recB4nUfexoy3LSHE

[解答]
指定した値が多い場合は、Propsが肥大化するのは仕方がないと感じる。

コンテキスは、システムで固定値のやり取りするのに使うことが多く、
Propsのやり取りを減らしたいためには使うことは、あまりしない。

また、コンテキストを使用した場合は、コードから見えなくなるというデメリットもあるため、
Propsで渡す方が良い。

Propsの他にStyleオブジェクトをそのまま渡すという方法もあるが、
この場合、なんでも渡せてしまう危険性がある。

自分であればPropsで限定的に公開する。
例えば、fontだけをPropsで公開して、他は変えられないように非公開とするなど。
Propsで全て公開してしまうと、コンポーネントで定義しても、外部から何にでも変えられてしまい、
コンポーネント化している意味が薄れてしまう。
コンポーネントのルールを強制する意味でもPropsを限定する方が良いかなと感じる。

Styleの書き方でも同じようなことはできるが、Propsで渡すの方がよく見かける。
CSSinjsの方が動的にスタイルを変えやすくなる。

---
### 6.storybookの管理の仕方に関して、実務での管理方法はどうしているのでしょうか？

[質問全文]
https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/rechBsze5jEevE5rn

[解答]
開発者だけが使うならローカル環境に立ち上げる。
デザイナーさんに見せたいなど、共有したい場合はホスティングする場合もある。

下記のサービスを過去のプロジェクトで使用したことがある。
サービス：Chromatic
https://www.chromatic.com/

PrAhaでは変更した際にすぐに適用できるため、
テストのしやすさの観点からローカルに入れて使用している。

---
### 7.テストコード（今回だとstories.jsやtest.js）も本番コードと同ディレクトリに含めている場合、実際のプロジェクトではどのようにリリース対象コードのみを抽出しているのでしょうか（webpackの設定などで除外している？）
[質問全文]
https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recNdC2QnsMgzvHms

[解答]
実務でPrAhaはnext.jsを使用している。
next.jsでは裏でWebpackが動いており、Productionビルド時にrootからimport文を辿って、
ビルドにどこまで含めるべきかを判断している。
そのため、明示的にimport文に指定しない限りは、ビルドに含まれない。

注意点として、ダイナミックインポート（実行時にパスが決まる）を使用すると、
ドメイン配下の全てのファイルをバンドルしてしまうので、ドメイン配下のテストコードも含まれる場合がある。

上記より「import文に書かない」且つ「ダイナミックインポートをしない」ければ、
基本的にはテストコードが含まれることはない。

ただ、どうしても含まれてしまう場合は、
(next.jsであれば)next.confignのwebpack設定でファイルを除外することになる。

中野さんの補足で正しいです！

---
### 8.Pre-commitは実務でよく使うのか、またCIを併用する場合は、CIとの役割分担はどうしているのでしょうか？
[質問全文]
https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recB3FJXpZLECG479

[解答]
自分のぽかミス防止のためにつけています。(pre-commitは各自で無効にすることができてしまうので)

自分はpre-commitでlint/pritterをかけて、pre-pushでテストをまわしています。

ローカルとの環境差異があるため、必ずCIでもテストはまわします。

単体と統合は必ず分けて書き、単体テストは早いので必ずpre-pushでやるようにして、CIで統合テストを実行していたりしている。(**.integration.test のファイルを統合テストとして分けてテストしている)

テストは、一部の修正であろうと、必ず全て通すようにしている。

---
### 9.スナップショットテストは画面表示に関するテストが中心のイメージですが、実務でそれ以外のこのテストを採用するユースケースはあるでしょうか？
[質問全文]
https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recqBEIKgYtlW3RHa

[解答]
jestでは、consoleメッセージまでテストで見ていることもあるようですが、自分はやったことはなかったです。

---
### 10.スナップショットが保存される、snapshotsフォルダをどう管理しているのでしょうか？
[質問全文]
https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recqBEIKgYtlW3RHa

[解答]
過去のスナップショットを貯めたことはなく。
直前のスナップショットとのみ比べている。

それは、スナップショットが他のテストを代替するものではなく、おまけのようなものなので、そこまで信頼していないため。

スナップショットは、開発者のリテラシーに左右される。
例えば、上手くいかないために開発者がスナップショットを一旦全て削除しまった場合、
もし、それでレビューがとおり、マージしてしまったら、その瞬間にスナップショットは破綻してしまう。

過去のスナップショットを残す場合、
Git-hubアクションなどで、S3にスナップショットを投げるなどはできるかもしれないが、
そこまではやったことはない。

Chromatic(https://www.chromatic.com/)で過去の成果物を残す際、無料プランでは消えてしまうかもしれないが、有料プランでは残せる。
（一番高いプランであれば、ヒストリー機能がある模様）

---
### 11.ビジュアルリグレッションテストをする際に、テストの差分閾値（どの程度の差分でテストを失敗とするか）は設定しているでしょうか？
[質問全文]
https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recH1vxmazDtwYFif

[解答]
デフォルトから変えたことはない。
何回やっても差分が出る場合は、差分が生まれる背景に目を向ける必要がある。
（テスト内容や環境差異など　→　それにより環境を統一するなどの対応）

機械学習で過去の差分を学習してくれるサービスもある
applitools:https://applitools.com/

環境際の発生などを考慮し、
差分スナップショットは、CI環境に別にコンテナを用意してそこで取ることが多い。

過去に閾値を変えたことはないが、変える場合はfailureThresholdの値を変えることであっている。

---
### 12.クライアントのOSやブラウザなどユーザエージェントに基づいた処理分岐を行いたい場合は、JavaScriptではどのように分岐を行っていますか？
[質問全文]
https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recI8PDDYciqblt36

[解答]
できるだけ使うのを避けます。
user-Agentには問題があり確実ではないため。
また、新しい機種が増えた場合に、それに毎回追従しなければならず、不確実性が高い。

そのため「レスポンシブCSS」で出来ないかを考えます。

・表示内容であればWindows情報(width,height)を参照して変更
・IE対応であれば、IEなどが独自に定義している属性(ベンダープリフィックス)などを参照して対応

※OSの検知はやったことがないが、
検知が必要な時として考えられることとして以下２つが考えられる
・ファイルをダウンロードする時にCPUの型によって、最適なダウンロードパッケージを出し分けるなど
　→実務で直面することは、まずなさそう
・iOS/Androidを識別してデザインがインドラインに適した表示にする

user-Agent自体は、そのまま受け取ってログに出力する程度。

---
### 13.実際にリグレッションテストについて、実務経験ではどういったテスト環境を構築していたかお聞きしたいです。
[質問全文]
https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recHFY48zlPLFBfzO

[解答]
質問に記載いただいた作りでやっていました。
今後、ビジュアルリグレッショnテストをやる機会があれば以下のサービスを使いたい。
persy　Saasのサービス (コマンド一つでビジュアルリグレッションテストまでやってくれる)

開発状の利便性を上げるためにバンドルサイズが大きくなり、サーバーも立ち上げるため遅くなりがち。
そのため、yarn build storybookでテストすることの方が多い。

> （実際にStorybookを使っているCIパイプラインのコードを見てみたいです）

→ storybookのチュートリアルにCIのチュートリアルがある
chromaticを使ってPRを作成するごとにstorybookをホスティングするgithub-actionsのworkflow
https://storybook.js.org/tutorials/design-systems-for-developers/react/en/review/

また、javascriptでも分岐はしない。
どうしても分岐が必要な場合は、window情報を使う

[最後の質問タイム]
・Backendでは、TDDを導入しいるか？
プロジェクト10個中の1個くらいの頻度でやっていた。

バッチ処理系の機能など難易度が高い場合は先にテストを書いたりするが、
チーム全体でTDDで書こうというのを、あまり強制したことはない。
学習するという用途でテストを書いてもらうことはある。

TDDのメリット
・機能がシンプルになる
（テストケースを書く時に、複雑なことをやろうとする、すごく書きづらくなるため）
・仕様の抜け漏れ確認ができる

TDDを導入した時は、細かくルールなど決めず、
まずはやってみよう〜...というのでテストを書き始めた感じでした。
（自社サービスだったため）