
この記事は [YAMAP エンジニア Advent Calendar 2021](https://qiita.com/advent-calendar/2021/yamap-engginers) の23日目の記事です。

自分は普段ターミナルでgitの操作をしているのですが、開発とレビューを並行して多くのブランチを切り替えたりするなど地味にgitの操作に時間を要する事が多く、効率化を求めて色々とgitエイリアスを設定したら良い感じになったのでまとめてみました。

## git switch-pr

### 課題
自分がPRレビューをするためにブランチを切り替える時は「GitHub上でブランチ名をコピーしてターミナルに貼り付けて...」という作業をよくやっていました。
1日に3,4件かそれ以上のPRレビューをしていると、この作業が地味にストレスとして感じていました。

### 改善

<img src="/images/posts/good-git-alias/swpr.gif" alt="switch-prコマンドの実行の様子" width="641" height="296" />

`git switch-pr` はリモートリポジトリのプルリクの一覧からブランチ移動をするためのエイリアスです。

ブランチ名をコピペする手間が減りPRレビューが非常に快適になりました！

プルリクの一覧は [GitHub CLI](https://github.com/cli/cli) で取得をしています。

自分が管理しやすいように `switch-pr` としてエイリアスを作成してから、その短縮形として別に `swpr` を設定するという設定をしています。

```shell
// ~/.gitconfig
[alias]
  switch-pr = !gh pr list | awk '{print $(NF-1)}' | peco | xargs git switch
  swpr = switch-pr
```

## git history

### 課題
feature ブランチで開発を進めながらPRレビューをしていると、1日に3,4個のブランチを移動することもあります。
複数のブランチを行き来する時に、わざわざブランチ名を思い出しながらブランチを切り替えるのは非常に面倒でした。
特にチケットとPRを紐づけるためにブランチ名にチケット番号などを記載していると、余計に入力が大変になります。

### 改善

<img src="/images/posts/good-git-alias/history.gif" alt="historyコマンドの実行の様子" width="641" height="296" />

`git history` は過去に移動したブランチ一覧からブランチを選択して移動ができるエイリアスです。

`peco` を使って一覧からブランチを選択可能にしているので、ブランチ名を覚えていなくてもスムーズに移動ができるようになりました。

```shell
// ~/.gitconfig
[alias]
  history = !git --no-pager reflog | awk '$3 == \"checkout:\" && /moving from/ {print $8}' | awk '!a[$0]++' | head | peco | xargs git checkout
```

## push.default current
### 課題
作業後に初めてブランチをプッシュする時は `git push origin feat/123-feature1` というような形式でプッシュをしていました。
これは上流ブランチの紐付けが存在しないためです。

### 改善
`git push` の引数を省略した場合の挙動は `push.default` で設定することができ `push.default current` を設定することで、作業中のブランチと同名のリモートブランチに対してpushしてくれるようになります。

この設定をすることで、初めてのプッシュでも `git push` だけでプッシュができるようになります。

```shell
$ g config --global push.default current

~/.gitconfig
[push]
	default = current
```

## git create-pr

### 課題
GitHub上でプルリクエスト(PR)を作成する場合に、初回プッシュをした場合はターミナル上にPR作成のURLを表示してくれます。
しかし、2回目以降の場合はこのURLが表示されずGitHub上からPR作成を進める必要があります。
正直、1回目のURLクリックだけでも面倒だと思っていたので、GitHub上で数クリックの操作が発生するのは非常に手間でした。

### 改善

<img src="/images/posts/good-git-alias/create-pr.gif" alt="create-prコマンドの実行の様子" width="1425" height="810" />

`git create-pr` は現在の作業ブランチのプルリクエストを作成するGitHubのページをブラウザで表示するエイリアスです。
ターミナル上でコマンド一つでPR作成の準備が整うので非常に快適になりました。

仕組みとしては GitHub CLI のコマンドをエイリアスで登録しているだけなので、複雑なことは何もしていません。

```shell
~/.gitconfig
[alias]
  create-pr = !gh pr create --web
```

## git open-pr

### 課題
コードレビュー時にローカルでコードを確認したり、レビューで指摘をもらった箇所の修正後に、改めてGitHub上のPRを表示したい時にいちいちブラウザでページ移動するのが面倒なことがあったりします。

### 改善

<img src="/images/posts/good-git-alias/open-pr.gif" alt="open-prコマンドの実行の様子" width="1425" height="810" />

`git open-pr` は現在の作業ブランチのPRをブラウザで表示するエイリアスです。

これも GitHub CLI のコマンドをエイリアスで登録しているだけです。

```shell
~/.gitconfig
[alias]
  create-pr = !gh pr view --web
```


この記事は YAMAP エンジニア Advent Calendar 2021 の23日目の記事です。自分は普段ターミナルでgitの操作をしているのですが、開発とレビューを並行して多くのブランチを切り替えたりするなど地味にgitの操作に時間を要する事が多く、効率化を求めて色々とgitエイリアスを設定したら良い感じになったのでまとめてみました。

開発効率を劇的に改善しているgitエイリアスと設定


この記事は [YAMAP エンジニア Advent Calendar 2021](https://qiita.com/advent-calendar/2021/yamap-engginers) の21日目の記事です。

## ts-jestの課題感

ts-jestを使っているとコンパイル時間の問題で地味にテストに実行がかかります。

YAMAPではフロントエンドでもユニットテストを書き始めたので、約180ケースで1分ほどCIでテスト実行に時間がかかるようになりました。
またTDDで開発を進めていると、開発中に非常に多くユニットテストを実行するので ts-jest の実行時間の遅さが開発効率に直結してきます。

そこで、ts-jest を @swc/jest に置き換えて、実行時間の改善を試みました。

## 導入効果

@swc/jest に置き換えた結果、CIでのユニットテストの実行時間が1/2に短縮されました🎉

|変更前|変更後|
|--|--|
|53s|21s|

## @swc/jest とは
@sec/jest は Rust製の TypeScriptコンパイラーの swc を利用して作られた Jest の Transformer です。
個人的に感じる @swc/jest のメリットは次の点です。
- swc が Rust製のため ts-jest(tsc) と比較して、高速に動作する
- 設定を `jest.config.js` 内に書くことができるので、`tsconfig.test.json` のようにテスト用の tsconfig ファイルを持つ必要がない

## ts-jest を @swc/jest に置き換える
まずはコンパイラー本体の`@swc/core`と Transformer の`@swc/jest`をインストールします。

```shell
$ yarn install -D @swc/core @swc/jest
```

変更前のJestの設定ファイルはこんな感じです。

```js
/** @type {import('@jest/types').Config.InitialOptions} */
module.exports = {
  preset: 'ts-jest/presets/js-with-babel',
  testEnvironment: 'jsdom',
  (省略),
  globals: {
    'ts-jest': {
      tsconfig: '<rootDir>/tsconfig.test.json',
    },
  },
};
```

これを @swc/jest を使うように変更します。
設定ファイル内に swc の設定を追加して `transform` を @swc/jest を使うように修正しています。
また、tsconfigは不要になったので `globals` の設定ごと削除しています。

swc の設定項目についてはコメントに記載してあります。詳細は[公式ドキュメント](https://swc.rs/docs/configuration/compilation)を参照ください。

```js
/** @type {import('@swc/core').Config} */
const swcConfig = {
  // ソースマップの出力を有効にする
  sourceMaps: true,
  module: {
    // JestがCommonJSでモジュールを読み込むのでCommonJS形式で出力する
    type: 'commonjs',
  },
  jsc: {
    parser: {
      // TypeScriptとしてコンパイルする
      syntax: 'typescript',
      // Reactのコンポーネントをテストしたいのでtsxのコンパイルを有効化
      tsx: true,
    },
    transform: {
      react: {
        // React の JSX トランスフォームの指定
        // Reactインポートの手間を省略するために React17 から導入された 
        // _jsx(react/jsx-runtime) の形式にコンパイルする
        runtime: 'automatic',
      },
    },
  },
};

/** @type {import('@jest/types').Config.InitialOptions} */
module.exports = {
  transform: {
    '^.+\\.(t|j)sx?$': ['@swc/jest', swcConfig],
  },
  (省略),
};
```

## コンパイラーが異なることによる懸念

babelで設定を書いている影響でプロダクションのコンパイルは引き続き tsc を使用しており、テストとプロダクションの実行環境でコンパイラーが異なる状況になってしまっています。コンパイラー依存の問題でテストでは正常に動くみたいな事が起こる可能性はあるかもとという懸念は少し持っています。

ただ、それによるバグが起こる可能性はかなり低くテスト実行の速度向上による開発効率化の方がメリットが大きいと判断しているので、そこは許容範囲かなと考えています。

## さいごに

思ったよりもスムーズに導入ができて特に問題が発生することもなく、今までと変わらずにテスト実行が使い続けれているので、導入して良かったです。


この記事は YAMAP エンジニア Advent Calendar 2021 の21日目の記事です。ts-jestを使っているとコンパイル時間の問題で地味にテストに実行がかかります。YAMAPではフロントエンドでもユニットテストを書き始めたので、約180ケースで1分ほどCIでテスト実行に時間がかかるようになりました。またTDDで開発を進めていると、開発中に非常に多くユニットテストを実行するので ts-jest の実行時間の遅さが、開発効率に直結してきます。そこで、ts-jest を @swc/jest に置き換えて、実行時間の改善を試みました。

実務でts-jestを@swc/jestに置き換えてCIの実行時間を1/2に短縮した


この記事は [YAMAP エンジニア Advent Calendar 2021](https://qiita.com/advent-calendar/2021/yamap-engginers) の22日目の記事です。

## はじめに
現在、輪読会で [テスト駆動開発](https://www.amazon.co.jp/dp/B077D2L69C/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1)（TDD）を読み進めています。  
本を読んで色々と知識が入ってきているので、業務でアウトプットしてみたいなと思い、バグ修正からTDDを初めてみたら良かったので紹介します。

## なぜバグ修正から始めるのか？
TDDをする上で一番難しいなと感じるのが、**実装前に何のテストを書けば良いか分からない**という部分です。  
今までテストを書いた経験が少ないと、対象となるコードが無い状態からテストを書き始めるのはイメージがしづらく中々テストを書くことができません。

その点、バグ修正の場合は既にコードが存在しており、バグを再現するテストを書けば良く何をテストするかも明確になっているので、非常にテストコードが書きやすいという利点があります。

そのため、バグ修正は比較的スムーズにTDDのフローを回しやすく手軽にTDDを体験することができます。

## TDDでバグ修正に挑戦する
### 概要
ユーザーのアバター画像とユーザー名を表示する `UserBio` コンポーネントについて考えてみます。

このコンポーネントはアバター画像について考慮が漏れておりリンク切れのバグが発生する可能性があります。
- バグ: アバター画像が未設定の場合にリンク切れで画像が表示される  
- 期待する動作: アバター画像が未設定の場合はサムネイル画像を表示する

```tsx
// src/components/UserBio.tsx
import { FC } from 'react';

type Props = {
  user: {
    name: string;
    avatar?: string;
  }
}

export const UserBio: FC<Props> = ({ user }) => {
  return (
    <div>
      <img src={user.avatar} />
      <span>{user.name}</span>
    </div>
  )
}
```

### バグを再現するテストコードを書く
コードのバグを修正したい気持ちをぐっ！と抑えて、先にテストコードを書いていきます。

どんなテストコードを書けば良いでしょうか？  
今回の目的はバグ修正のため**バグを再現する**テストコードを書けば良いので、何をテストするかは非常に明確です。

本来であれば、テストが全く書かれいない場合はアバター画像を表示するテストも先に書いておいた方が良いですが説明の都合で割愛しています。

```typescript
// src/components/UserBio.spec.tsx
import "@testing-library/jest-dom";
import { render, screen } from "@testing-library/react";
import { UserBio } from "./UserBio";

describe("UserBio", () => {
  it("アバター画像が未設定のときにサムネイル画像を表示する", () => {
    render(<UserBio user={{ name: "テスト太郎" }} />);

    const expected = "https://example.com/images/avatar";
    expect(screen.getByRole("img")).toHaveAttribute("src", expected);
  });
});
```

テストを実行してみます。  
正常にテストが失敗してくれたので、これでバグを再現するテストコードが実装できました。

```shell
$ yarn jest src/components/UserBio.spec.tsx

 FAIL  src/components/UserBio.spec.tsx
  UserBio
    ✕ アバター画像が未設定のときにサムネイル画像を表示する (85 ms)

  ● UserBio › アバター画像が未設定のときにサムネイル画像を表示する

    expect(element).toHaveAttribute("src", "https://example.com/images/avatar") // element.getAttribute("src") === "https://example.com/images/avatar"

    Expected the element to have attribute:
      src="https://example.com/images/avatar"
    Received:
      null
```

### バグ修正対応
バグを再現するテストができたので、後は楽しくバグ修正のコードを書くだけです。

```tsx
const AVATAR_THUMBNAIL = 'https://example.com/images/avatar';

export const UserBio: FC<Props> = ({ user }) => {
  return (
    <div>
      <img src={user.avatar ?? AVATAR_THUMBNAIL} />
      <span>{user.name}</span>
    </div>
  );
}
```

バグ修正ができたので、改めてテストを実行してみます。  
無事にテストが通りバグが修正されたのを確認できました！ ⸜(｡˃ ᵕ ˂ )⸝

```shell
$ yarn jest src/components/UserBio.spec.tsx

 PASS  src/components/UserBio.spec.tsx
  UserBio
    ✓ アバター画像が未設定のときにサムネイル画像を表示する (61 ms)
```

### ブラウザ不要の検証
今回のバグ修正ではコードを変更してバグが修正されたことを確認する過程全くブラウザを利用しませんでした。  
PR作成前に念の為のブラウザ確認はしますが、検証でブラウザ操作をするのはその1度だけに抑えることができます。

フロントエンドをTDDで開発するメリットの一つとしてこの検証の簡略化があります。  
フロントエンドで検証を進めるために何度もコードとブラウザを行き来してブラウザ操作をする事が多いですが、この実装途中におけるブラウザ操作が地味に面倒で開発コストとして発生します。

TDDでテストを先に書いて検証を自動化することで、この検証コストを減らして開発効率を上げられるメリットがあります。

## さいごに
今回は非常に簡単なバグ修正を例にフロントエンドでのTDDについて紹介しました。

TDDやテストを書くには、どんな簡単なモノでも良いので**たくさんテストを書いて経験を得る**ことが何より大事だと思います。  

TDDで開発をしてみたいけどなかなか初めの一歩が踏み出せない場合は、今回のケースのようなすごく簡単な修正からテストを書き始めてみましょう。


この記事は YAMAP エンジニア Advent Calendar 2021 の22日目の記事です。現在、輪読会で「テスト駆動開発」（TDD）を読み進めています。本を読んで色々と知識が入ってきているので、業務でアウトプットしてみたいなと思い、バグ修正からTDDを初めてみたら良かったので紹介します。

バグ修正から始めるフロントエンドのTDD入門


この記事は [YAMAP エンジニア Advent Calendar 2021](https://qiita.com/advent-calendar/2021/yamap-engginers) の14日目の記事です。

## 経緯
ある時、チーム内のコードレビューをしていてスペルミスの指摘が目立つようになってきました。

スペルミスのチェックは人がやるより機械がやった方が早いということで、CIでスペルチェックを自動化してコードレビューで自動でスペルミスを指摘する仕組みを導入してみたので、導入方法とその後の効果をまとめました。

この記事で書いているコードは全て [t-yng/ci-spell-check-sample](https://github.com/t-yng/ci-spell-check-sample) に置いてあります。

## 導入手段の検討
### 既存のGithub Actions
マーケットプレイスの GitHub Actions をリポジトリに導入するパターン。  
いくつか試したが期待する結果が得られなかったので、後述する GitHub Actions を自作する形式にした。

- [Typo CI](https://typoci.com/)
  - Github Actions でリポジトリにスペルチェックを導入可能
  - 調査段階では Github が 404 になっていたので詳細は調べてない
  - 執筆時点(2021/12/13 時点）で確認したら参照可能になっていた
- [Check spelling](https://github.com/marketplace/actions/check-spelling)
  - 調査時点では β版 の状態だった
- [misspell-fixer-action](https://github.com/marketplace/actions/misspell-fixer-action)
  - Developers.ioで[オススメ記事](https://dev.classmethod.jp/articles/spellcheck-on-actions/)があった

### スペルチェックのライブラリを GitHub Actions に組み込む
自前でスクリプトを書いて Github Actions を構築するパターン。  
[cspell](https://github.com/streetsidesoftware/cspell) を GitHub Actions に組み込みCIを構築することにしました。

- [misspell](https://github.com/client9/misspell)
  - 試してみたが期待したようにスペルミスを判定してくれなかった
  - ライブラリとして JavaScript などの言語はサポート外に見えた

- [misspell-fixer](https://github.com/vlajos/misspell-fixer)
  - ↑で挙げた misspell-fixer-action で利用されているライブラリ
  - 環境構築が面倒そうだったので試してない

- [cspell](https://github.com/streetsidesoftware/cspell)
  - VSCode の拡張で圧倒的な人気を誇る [Code Spell Checker
](https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker) で利用されているライブラリ
  - cliがあり手軽に実行できるのとVSCodeの拡張として使われている実績がある
  - prismjs などのライブラリ名や固有名詞がスペルミスとして扱われる点だけがデメリット  
     (単語辞書を作成すればスキップは可能）

## CIの構築
### cspellの導入とnpmスクリプトの作成
cspell のインストール

```shell
$ yarn add -D cspell
```

cspellの設定ファイル(.cspell.json)を作成

```json
// .cspell.json
{
  "version": "0.2",
  "language": "en",
  "words": [], // 固有名詞などチェックをスキップしたい単語を登録する
  "dictionaries": [
    "softwareTerms", 
    "misc",
    "companies",
    "typescript", 
    "node", 
    "html", 
    "css", 
    "fonts", 
    "filetypes", 
    "npm"
  ],
  "ignorePaths": [
    "**/node_modules/**",
    "**/.git/**",
    "**/.vscode/**",
    "**/.next/**",
    "**/__generated__/**",
    "**/package.json",
    "**/yarn-error.log",
    "**/yarn.lock"
  ]
}
```

npmスクリプトの作成

```json
{
  "scripts": {
    "spell-check": "cspell lint -c .cspell.json --show-suggestions"
  }
}
```

適当にタイポがあるコードを作って実行してみる。  
スペルチェックが正常に動作して代替の単語の提案してくれる部分ができた。

```javascript
// src/index.js
const heloo = (name) => console.log(`hello, ${name}`);
```

```shell
$ yarn spell-check
1/1 ./src/index.js 597.00ms X
/Users/tomohiro/workspace/examples/ci-spell-check/src/index.js:1:7 - Unknown word (heloo) Suggestions:  [helot, helio, hello, Helot, holo]
```

### GitHub Actions の実装
スペルチェックを実行するスクリプトは作れたので、あとは GitHub Actions でスクリプトを実行するだけです。  
`.github/workflows/spell-check.yaml` を作成してプッシュしたタイミングでスペルチェックが走るようにします。

```yaml
# .github/workflows/spell-check.yaml
name: review-on-push

on: push

jobs:
  spell-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2

      - uses: actions/setup-node@v1
        with:
          node-version: '16.x'

      - name: Install Dependencies
        run: yarn install
        env:
          NODE_AUTH_TOKEN: ${{ secrets.AUTH_TOKEN_FOR_GITHUB_PKG }}

      - name: execute spell-check
        run: yarn spell-check
```

### Reviewdog でPRにコメントする
今の状態はどこのコードでスペルミスが発生しているのか分かりにくい状態なので Reviewdog でPRにコメントします。  
さらに cspell はスペルミスが見つかった時にエラーとしてスクリプトが終了するので Reviewdog を通すことでCIがエラーとなるのを防ぐこともできます。

```yaml
# .github/workflows/spell-check.yaml
- uses: reviewdog/action-setup@v1
- run: reviewdog -version

(省略)

- name: execute spell-check
  env:
    REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  run: |
    yarn spell-check \
      | reviewdog -level=warning -efm="%f:%l:%c - %m" -reporter=github-pr-review
```

これでスペルミスがあった時に Reviewdog がPRに自動でコメントしてくれます。

<img src="/images/posts/spell-check-ci/spell-check-reviewdog.png" alt="Reviewdogのコメント" width="1844" height="794" />

### 修正差分に対してのみスペルチェックを実行する
リポジトリが肥大化していくとスペルチェックの対象コードが膨大になりスペルチェックの実行に時間がかかるので、修正差分だけを対象としてスペルチェックを実行するようにします。

```yaml
- uses: actions/checkout@v2
  with:
    fetch-depth: 0 # 差分取得のために全てのブランチを取得する

(省略)

- name: execute spell-check
  env:
    REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  run: |
    git diff remotes/origin/$GITHUB_BASE_REF --name-only \ 
      | yarn spell-check \
      | reviewdog -level=warning -efm="%f:%l:%c - %m" -reporter=github-pr-review
```

## 導入後の結果
導入後はPRでスペルミスが自動で見つかり一定の効果を得ることができました。

しかし、デメリットでも書いたようにライブラリ名や固有名詞がスペルミスとして判定されてしまい、スペルミスでない単語もコメントで指摘されてしまっていました。この指摘が非常にノイズとなりコードレビューがやりづらくなってしまったので、結局CIは廃止する流れになりました。:smiling_face_with_tear:

## 結局どうしたか？
最終的には個々人の開発エディタにプラグインとしてスペルチェックの拡張を導入して、開発中にスペルチェックに気づけるようにする形で落ち着き、結果としてコードレビューでスペルミスを指摘することはほぼ無くなりました！

正直言うと最初からこの方法で良いとも思っていたのですが、個々人の開発環境に依存する解決策はできれば避けたく個人的にやってみたかったという理由でCIを導入を試していました。

CIは廃止する流れになりましたが、チームの問題への意識が高まって結果としてスペルミスの問題を解消されたので良かったです。


この記事はYAMAP エンジニア Advent Calendar 2021の14日目の記事です。ある時、チーム内のコードレビューをしていてスペルミスの指摘が目立つようになってきました。スペルミスのチェックは人がやるより機械がやった方が早いということで、CIでスペルチェックを自動化してコードレビューで自動でスペルミスを指摘する仕組みを導入してみたので、導入方法とその後の効果をまとめました。

CIでスペルチェックを自動化してみたけど最終的にやめた話


この記事は [YAMAP エンジニア Advent Calendar 2021](https://qiita.com/advent-calendar/2021/yamap-engginers) の10日目の記事です。

## はじめに
コードレビュー難しいですよね。  
今年で6年目になりますが未だにコードレビューが出来ると胸を張って言うことができません。

予定よりも時間をかけてしまったり、そこまで指摘しなくても良かったなーという点を細かくレビューしてしまったり、逆に指摘すべき箇所を見逃してしまったり問題点を挙げればキリがありません。

コードレビューのことを考えるにあたり、自分が普段どんな感じでレビューしているか意識したことをがないなと思い、一度自分がレビュー時に意識していることを整理してみました。

## 仕様の把握
コードレビューを始める時に自分が最初にやることは、修正内容の仕様の把握です。ここでいう仕様とは、「どういう場合にどういう状態になるか」を指しています。

コードレビューとは修正されたコードに問題がないかを客観的な目線でチェックする作業です。  
このとき、**何が正しいか** の基準が無いと問題が無いことを判断することはできないため、最初に**何が正しいのか** 知るためにも対象のPRでの仕様を理解することを意識しています。

### 概要欄を読み込む
チームでレビューをしていると、PRの概要欄には修正の目的などが記載されています。  

まずは概要欄を読むことでざっくりと全体を把握できる事が多いので、最初に概要欄をしっかりと読むようにしています。（しっかり書かれている前提ですが）

### ブラウザで動作確認
修正内容を理解するために、ソースコードを読む前にブラウザで実際に動作確認をします。

先に実際に動かして確認をした方が理解を深めやすく、何をやっているかをイメージしながらコードリーディングができるので、コードレビューがやりやすくなります。

最初の動作確認で分からない点や気になった箇所があれば、そこだけピンポイントでコードを読んで仕様を理解するようにしています。この時にバグが見つかることも多々あります。

### APIリクエストの仕様について
APIリクエストをしている場合はAPIレスポンスのデータ構造も意識的に確認するようにしています。
フロントエンドはAPIのレスポンスデータを画面上に表示する事が主な役割なので、表示するデータの仕様を把握しないと正しくデータを扱えているかの判断が難しいためです。

外部APIのレスポンスでデータの意味が分からない場合は、念の為API仕様書でレスポンスの仕様を把握してレビューができると、予想外のバグが見つかったりします。

##  レビューの優先度
レビューをする時は自分の中で項目を分けて優先度を付けてレビューをしています。

1. バグ・デグレが発生しないか
2. セキュリティは問題ないか
3. 変更は容易か（設計）
4. コードは読みやすいか

レビュー項目を分けて優先度を付けておくと、PRの内容に応じてレビューにかける時間配分をコントロールできるようになります。
- コードレビューをする時間が少ない場合は最低限 2 まではしっかり確認して 3,4 にかける時間を短くする。
- 今後も変更が多い重要な機能は、多少を時間をかけてでも全ての項目について細かく確認する。

## 重点的に見る箇所
- サービスとして重要な機能やお金が絡む部分
- XSSなどのセキュリティバグが発生しやすい部分
    - クエリパラメーターを内部で参照する場合など
- 多くの場所から参照されているファイル
    - 共通ライブラリやコンポーネント

## バグ・デグレが発生しないか
- 意地悪な気持ちになって特殊な操作をしてみる
- PC,スマホの両方のviewportでデザイン崩れが発生しないか
- CSS, JS はサポートしているブラウザで利用可能か
 - ここら辺はESLintで自動テストをかけて、ある程度チェックを省略することもできます
- 条件分岐の条件は適切か
- 修正箇所を呼んでいる他の部分に影響がないか

### バグ・デグレが発生やすい箇所
次の箇所は経験的にバグ・デグレが発生しやすいので注意深くレビューをすることが多いです。

- コードの可読性が低い部分
- コードから実装者の意図が読み取れない箇所
  - 裏側に複雑な仕様が隠れていることがあるので、デグレが発生しやすい
- データ構造が複雑な箇所
  - 多くのことをやり過ぎている可能性が高く処理が複雑になっている可能性が高い
- 条件分岐が複雑な箇所
  - 多くのことをやり過ぎている可能性が高く処理が複雑になっている可能性が高い
- 多くの箇所から参照されている部分
  - 呼び出し元に応じた処理が1箇所に書かれて、処理が複雑になりやすい
- パッと見で特殊なことをやっている箇所
  - 読んでいて普通だったらこんな実装しないなと感じる箇所は裏側に複雑な仕様が隠れていることがあるのでバグが発生しやすい
- なんかモヤモヤとした不安感を感じる箇所
  - モヤモヤの正体は経験則による直感であることが多く、過去に似た箇所でバグに遭遇したことがあったりするので、その直感は当たることが多い

## セキュリティに問題はないか
- URLパラメーターなどユーザーが入力可能な値を参照している場合は、XSSなどに問題がないか
- 権限などで機能制限をしている場合は、ローカルプロキシなどでレスポンスを改竄して悪さできないか
  - レスポンスを改竄して制限をすり抜けられる場合は、それをやられた場合のサービスのリスクを考える

## 変更は容易か（設計）
- 発生する可能性のある仕様変更を想像して、その仕様変更に対して容易に対応可能か
  - 仕様変更があった場合に複数箇所を修正する必要があると1箇所だけ修正を忘れてデグレが発生しやすい
  - 修正時の影響範囲が多いとデグレが発生しやすい
- 一つのファイルが責務を持ち過ぎていないか
    - 1箇所で多くのことをしていると処理が複雑になりデグレが発生しやすい
    - 修正時の影響範囲も把握がしづらくなる
    - 修正時に考慮することが増えるので機能改修に時間がかかる

## コードの可読性
- 1か月後の自分が同じコードを読んで理解できそうか
- 無駄に複雑に書かれていないか
- 変数名は誤解を生むような名前になっていないか
- 自分が実装する場合にどう実装するかをイメージする

## レビューコメント
- 可読性や設計を指摘する場合は、極力ダメな理由と改善案（サンプルコード）を一緒に提示する
  - 一方的にダメと言われるとレビュイーも困りますし、気分が悪くなっちゃいます。
- ラベルをつける
  - レビュイーがコメントに対して優先度をつけて対応ができるので効率が上がります
  - FIX(バグ修正）, REFACTOR、COMMENT など
  - [レビューコメントにラベルをつけるだけで開発効率があがって幸せになれそうな話 - Qiita](https://qiita.com/godgarden/items/3ea57a7ee6dbff1df6e6)
- 絵文字やAAを使う
  - コードレビューは書いたコードに対して何かしらの指摘が発生する作業なので、ギスギスしてしまう可能性があります。
  - 少しでもギスギスしないように絵文字やAAを使って雰囲気が柔らかくなるようにしています。
- 良い点があれば Good なリアクションをする
  - 褒められると嬉しい👍
- 人を否定しない
  - こんなコードを書くなんて全然ダメだ！などと個人に対しての言及はダメ。ゼッタイ。
  - 自分が言われたら辛い🥲
- 宗教戦争になり得ると思った指摘はしない
  - ただ、宗教戦争になるかどうかの判断はかなり難しい
  - 書き方の問題であれば、コーディング規約を決めてLinterでチェックできると良い
  - 宗教戦争になりそうだと思ったら、「好みの問題かもしれないですが...」などと前置きをおいてお茶を濁す
  - COMMENT ラベル等でお気持ちの表明だけをする

## コードレビューを楽しむ🎉
自分はコードレビューをゲーム感覚で実施することを心がけています。バグを見つけらたらレビュアーの勝ち！バグが無ければレビュイーの勝ち！という具合です。目標を持ってコードレビューをするとレビューをしていて楽しいですし、バグを見つけることに全力になります。

※ 勝ち負けは自分の中だけに留めておいてください。

## 参考資料
丁寧にまとまっているので、併せて読んでみてください。

- [より良いコードレビューをするために気をつけていること | メルカリエンジニアリング](https://engineering.mercari.com/blog/entry/2019-12-22-080000/)
- [コードレビューの際に気をつけること - Qiita](https://qiita.com/awakia/items/8344ba751426e386e0f5)
- [僕がコードレビューの時に気をつけていること｜su-｜note](https://note.com/su_k/n/nf23ab5c6dba2)


この記事はYAMAP エンジニア Advent Calendar 2021 の10日目の記事です。コードレビュー難しいですよね。今年で6年目になりますが未だにコードレビューが出来ると胸を張って言うことができません。予定よりも時間をかけてしまったり、そこまで指摘しなくても良かったなーという点を細かくレビューしてしまったり、逆に指摘すべき箇所を見逃してしまったりします。

僕がフロントエンドのコードレビューをする時に意識していること


この記事は [YAMAP エンジニア Advent Calendar 2021](https://qiita.com/advent-calendar/2021/yamap-engginers) の7日目の記事です。

## はじめに
初めてフロントエンドでコンポーネントのユニットテストを書く時に「何をテストするのか」が分からず、上手くテストが書けないという事があります。

この記事ではコンポーネントの入力と出力を意識することでユニットテストで「何をテストするか」について、まとめています。

## 自動テストは何をテストするのか？
最初に一般的に自動テストでは何をテストするのかを明確にします。

自動テストでは**与えた入力に対して期待した出力が得られるか？** をテストします。基本的にはこれだけ意識しておけば大抵の自動テストは書くことができます。（暴論）

例えば次ような url が Googleのドメインかどうかを判定する関数のテストを考えてみます。

```typescript
const isGoogleDomain = (url: string): boolean => {
  return url.match(/^http[s]:\/\/google.com\//) != null;
}
```

この関数をテストしてくださいとお願いされたら、どのようなテストを書くでしょうか？  
大抵は最低限、次の2つのテストを考えるのではないでしょうか？
1. https://google.com/search?q=テスト の時に true を返すか
2. https://example.com の時に false を返すか

このテストケースの入力と出力をまとめると次のようになります。

|入力|出力|
|--|--|
|https://google.com/search?q=テスト|true|
|https://example.com|false|

## コンポーネントのテストが難しい理由
先ほど見たように、util 系の関数は入力と出力が分かりやすいので、比較的テストが書きやすい部類になると思います。それに比較してコンポーネントは意識しないと入力と出力が分かりにくいのではないでしょうか？

コンポーネントのテストが難しいと感じる理由は **テストの書き方が分からない** のではなく **入力と出力が分からない** ことが大きな原因となっていると考えています。

逆に言えばコンポーネントの入力と出力が把握できれば、コンポーネントのテストも util系の関数と同じように書くことができます。

## コンポーネントの入力と出力
ここからReactの関数コンポーネントを例に話を進めますが、基本的な考え方は Vue のコンポーネントでも同じです。
Reactの関数コンポーネントは名前の通りただの関数です。ただの関数ということは入力と出力が定義できるということです。

では、関数コンポーネントの出力とは何でしょうか？
それは、**HTMLのDOM構造** です。

それに対して入力は主に次の3種類です。
1. props
2. クリックなどのユーザーイベント
3. Reduxなどのグローバルストア

以上のことから、それぞれ**3種類の入力に対して正しくHTMLの構造が出力されるか**を確認することで、コンポーネントのテストを書くことができます。

## コンポーネントはテストを書かない違和感
このように入力と出力を意識して考えると、関数コンポーネントもutil系の関数も同じ関数です。

関数コンポーネントを実装する時には、〇〇なpropsの場合は△△なDOMを出力するといったように条件分岐や、開始日や終了日から滞在日数を計算してテキストを表示するといったような実装をすることがあります。

これらは明らかなロジックにも関わらず、util系の関数のロジックはテストを書くのにコンポーネントのロジックのテストは書かないのは明らかに違和感を感じてしまいます。

なので、コンポーネントのテストもutil関数と同じような感覚でテストを書いていって良いと思います。

## 入力と出力を考えてテストを書いてみる
### 入力と出力を考える
実際に次のカウンターコンポーネントの入力と出力を考えてみます。

次に進む前に試しに自分で入力とを出力を考えてみてください。

```tsx
const Counter = ({count}: {count: number}) => {
    const [countState, setCount] = useState(count);

    const handleClick = () => {
        setCount(count => count + 1);
    }

    return (
        <div>
            <span>{count}</span>
            <button onClick={handleClick}>カウントアップ</button>
        </div>
    );
}
```

入力と出力はこんな感じになります。

|入力|出力|
|--|--|
|count props|count値のテキスト|
|ボタンクリックイベント|現在のcountに+1された値のテキスト|

ここでは、span要素として出力されのるが重要ではなく、**カウントの値がテキストとして出力される**ことが期待している結果なので、出力はテキストという表現をしています。

### テストを書いてみる
入力とを出力を洗い出せたのでテストを書いてみます。

テストの記述には jest + testing-library を利用しますが、触ったことない方でも何をやっているかを把握できると思うので、こんな感じでテストを書くんだという雰囲気を掴む程度で大丈夫です。

最初に props の入力に対する出力のテストを書いてみます。
|入力|出力|
|--|--|
|count props|count値のテキスト|

期待する振る舞いが「props として渡したカウントの値がHTMLのテキストとして出力されるか」なので、入力としてpropsで渡した値(5)が出力としてDOM上にテキストとして表示されているかを確認すればテストを書くことができます。

```tsx
import { render } from '@testing-library/react';
import { Counter } from './Counter';

describe('Counter', () => {
    it('propsで指定したカウント数を表示する',  () => {
        render(<Counter count={5} />);
        const count = screen.queryByText(5);
        expect(count).toBeInTheDocument();
    }
});
```

次にボタンクリックの入力に対してもテストを書いてみます。

|入力|出力|
|--|--|
|ボタンクリックイベント|現在のcountに+1された値のテキスト|

ユーザーイベントの場合もpropsの場合と考え方は同じです。

入力としてボタンクリックイベントを与えた時に、現在のカウントを+1した値がテキストとして出力されるかを確認すればテストを書くことができます。

```tsx
import { render } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { Counter } from './Counter';

describe('Counter', () => {
    it('propsで指定したカウント数を表示する',  () => {
        render(<Counter count={5} />);
        const count = screen.queryByText(5);
        expect(count).toBeIntTheDocument();
    }

    it('ボタンをクリックすることで表示するカウント数が増える',  () => {
        render(<Counter count={5} />);
        const button = screen.getByRole('button');
        userEvent.click(button);
        userEvent.click(button);
        const count = screen.queryByText(7);
        expect(count).toBeInTheDocument();
    }
});
```

## 具体的なコンポーネントのテストを考えてみる
サンプルのカウンターコンポーネントではピン来ないと思うので、もう少し具体的なコンポーネントとして通知内容に応じてリンクを表示する `NotificationLink` というコンポーネントのテストを考えてみます。

`NotificationLink` は props で `Notification` オブジェクトを受け取り、プロパティの値に従ってaタグを返す関数コンポーネントです。

仕様は次の通りです。
- `webLaunchUrl` が null or 空文字の場合は span要素でテキストを表示する
- `webLaunchUrl` が外部リンクの場合は、別タブで対象のリンクを開くa要素を表示する
- `webLaunchUrl` が内部リンクの場合は、相対パスをリンクとしたa要素を表示する

これらの情報を元に今までの例に習って、入力と出力を考えみましょう。

```tsx
export const NotificationLink = ({notification}: Notification) => {
    const webLaunchUrl = notification.webLaunchUrl;

    if(webLaunchUrl == null || webLaunchUrl === '') {
        return <span>{notification.text}</span>
    }

    if (isExternalLink(webLaunchUrl)) {
        return <a href={webLaunchUrl} target="_blank">{notification.text}</a>
    }

    const relativePath = getRelativePath(webLaunchUrl);
    return <a href={relativePath}>{notification.text}</a>   
}
```

入力と出力はこんな感じです。

|入力|出力|
|--|--|
|webLaunchUrl が null の notification|notification.textのテキスト(a要素でない)|
|webLaunchUrl が外部リンクの notification|別タブで外部リンクを開くa要素|
|webLaunchUrl が内部リンクの notification|相対パスがリンクとして指定されたa要素|

入力と出力が分かったので、これを元にテストを書いてみます。

```tsx
import { render } from '@testing-library/react';
import { NotificationLink } from './NotificationLink';

describe('NotificationLink', () => {
    it('webLaunchUrlがnullのときにテキストのみを表示する', () => {
        const notification = { webLaunchUrl: null, text: 'test' };
        render(<NotificationLink notification={notification} />;
        const text = screen.queryByText(notification.text);
        const link = screen.queryByRole('link');

        expect(text).toBeInTheDocument();
        expect(link).not.toBeInTheDocument();
    });

    it('webLaunchUrlが外部リンクの時に別タブのリンクを表示する', () => {
        const notification = { webLaunchUrl: 'https://example.com', text: 'test' };
        render(<NotificationLink notification={notification} />;
        const link = screen.queryByRole('link');

        expect(link).toHaveAttribute('href', notification.webLaunchUrl);
        expect(link).toHaveAttribute('target', '_blank');
        expect(link).toHaveTextContent(notification.text);
    });

    it('webLaunchUrlが内部リンクの時に相対パスでリンクを表示する', () => {
        const notification = { webLaunchUrl: 'https://t-yng.jp/tag/typescript', text: 'test' };
        render(<NotificationLink notification={notification} />;
        const link = screen.queryByRole('link');

        expect(link).toHaveAttribute('href', '/activities');
        expect(link).not.toHaveAttribute('target', '_blank');
        expect(link).toHaveTextContent(notification.text);
    });
})
```

## コンポーネントのテストを書くメリット
### 設計の良し悪しの基準になる
「テストが書きにくいコードは設計が良くない」というのはテストを書くときに頻繁に言われる話ですが、コンポーネントでもこの考えは当てはまります。

色々な責務を持っている複雑なコンポーネントに対してテストを書いてみようとすると、入力と出力が分かりにくくなり、様々なモックを利用する必要が出てくるので非常にテストを書くのが困難になります。

特にコンポーネントの設計は良し悪しが難しい部分があるので、テストを書くことでテストが書きやすい=設計が悪くない、と判断して自信を持って実装を進めることができるのは大きなメリットです。

### 安心してリファクタリングができる
一般的に自動テストが効力を発揮するのはリファクタリングをしたときです。つまり、既存コードを修正するタイミングです。

コードレビューをしていると、レビューの指摘を受けてコンポーネントをリファクタするのは日常茶飯事なので、この時にテストを書いておけば安心してコード修正することができます。

テストはリリース前のタイミングでも書いてあるだけで十分に恩恵を得ることができます。

### 検証コストの削減
先ほどの `NotificationLink` コンポーネントに渡される `notification` オブジェクトがAPIレスポンスとして取得される場合には、手動検証をするにはパターンごとにAPIのレスポンスをモックしてブラウザ操作をする必要があり非常に面倒です。準備なども含めると10~15分ほどかかる場合もあるかもしれません。

コンポーネントのテストを書けば入力をモックできるので、1回テストを書けばボタンをポチッと押すだけで、5秒で検証することができます。

このように、APIレスポンスによって表示を切り替えるようなパターンでは手動検証よりもテストを書いた方が圧倒的に検証コストを減らせるメリットがあります。

## まとめ
- コンポーネントのテストも入力と出力を明確にして、期待した出力が得られるかを確認するようにするとテストが書きやすくなる。
- コンポーネントの単体テストは検証コストの削減など十分にテストを書くメリットは多い

コンポーネントのテストは実際に書いてみないと分からないことが多いので、とりあえず簡単な1ケースだけからでも良いので書き始めてみましょう！


初めてフロントエンドでコンポーネントのユニットテストを書く時に「何をテストするのか」が分からず、上手くテストが書けないという事があります。この記事ではコンポーネントの入力と出力を意識することでユニットテストで「何をテストするか」について、まとめています。

コンポーネントの入力と出力を意識してユニットテストを書いてみよう


この記事は
[タイムリープTypeScript 〜TypeScript始めたてのあの頃に知っておきたかったこと〜](https://qiita.com/advent-calendar/2021/timeleap-typescript)  
5日目の記事です。

## はじめに
自分がTypeScriptを書き始めた頃に苦労したのが、Jestでテストを書くときのモックの型をどう書けば良いか分からないことでした。

調べても型の指定方法が分からず、泣く泣く `as any` でコンパイラーを黙らせて、補完が効かなくなりモヤモヤしながらテストコードを書いていました。

TypeScriptで型を妥協してテストコードを書いていた時は次のような弊害もあったので、どう型安全にテストコードを書けば良いのか非常に知りたかったです。  
- 補完が効かなくなるのでコーディングが面倒になる
- プロパティをタイポした事に気づかずに、テストが失敗しても失敗している原因に気付けず疲弊する

## もくじ
- [モジュールモックの型指定](/post/jest-typescript-types#モジュールモックの型指定)
- [関数モックの型指定](/post/jest-typescript-types#関数モックの型指定)
- [スパイモックの型指定](/post/jest-typescript-types#スパイモックの型指定)

## モジュールモックの型指定
APIからユーザーの一覧を取得する関数のテストを考えてみます。

```typescript
// users.ts
import axios from 'axios';

export const all = () => {
  return axios.get('/users').then(res => res.data);
}
```

APIを直接リクエストせずにモックデータを返してテストが出来るように axios のモジュールをモックしてテストを書いてみます。

次の例では TypeScript は axios がモック化されたモジュールとして認識ができないので `axios.get.mockResolvedValue()` は型エラーとなります。  

当時はこの型エラーを解消するために `(axios.get as any).mockResolvedValue()` と書いていました。

```typescript
// users.spec.ts
import axios from 'axios';
import Users from './users';

jest.mock('axios');

test('should fetch users', async () => {
  const usersMock = [{name: 'taro'}];
  // error TS2339: Property 'mockResolvedValue' does not exist on type
  axios.get.mockResolvedValue({ data: { users: usersMock } });  
});
```

モジュールをモックする場合は、モジュールを別の変数に代入して型指定を行うことでモック化されたモジュールとして扱うことができます。

Jestにはモック化の型定義が複数用意されており、モジュールモックの場合は `jest.Mocked<T>` の型定義を利用してモック化されていることを表現できます。  

`typeof axios` と指定することで、ジェネリクスの型もモジュールから自動生成ができます。

```typescript
// users.spec.ts
import axios from 'axios';
import * as users from './users';

jest.mock('axios');

const axiosMock = axios as jest.Mocked<typeof axios>;

test('should fetch users', async () => {
  const usersMock = [{name: 'taro'}];
  axiosMock.get.mockResolvedValue({ data: { users: usersMock } });
});
```

## 関数モックの型指定
次にデータをフェッチする関数を引数として渡す場合の実装を考えてみます。

```typescript
export type Fetch<T = any> = (url: string) => Promise<{ data: T }>;

export const all = (fetch: Fetch) => {
  return fetch("/users").then((res) => res.data);
};
```

関数のモックは `jest.fn()` を使い生成できます。

次のテストコードでは、 `mockImplementation()` を利用してモック関数を実装していますが、実装関数の引数と戻り値が `any` となるので、モック関数に不適切な実装を渡しても型エラーが発生しません。

そのため、型チェックは通過しますがテスト実行時に `fetch(...).then is not a function` というエラーが発生してしまいます。  

このエラーも型安全にテストコードが書けていれば、未然に回避することができます。

```typescript
import * as users from "./users";

describe("users", () => {
  it("fetch all", async () => {
    const usersMock = [{ name: "Bob" }];
    const response = { data: { users: usersMock } };

    // Promise<{data: any}> を返すべき所を誤って、User[] を返している
    // 型エラーにはならない
    const fetchMock = jest.fn().mockImplementation(() => usersMock);

    const result = await users.all(fetchMock);
    expect(result).toEqual(usersMock);
  });
});
```

`jest.fn()` の関数を型安全に実装するには大きく2つの方法があります。

1つは関数実装を`jest.fn()` の引数として直接渡す方法です。

引数として渡した場合に型推論により、モック関数の型が決まるので正しく実装されていない場合に `users.all(fetchMock)` の引数の型チェックで失敗します。

```typescript
const fetchMock = jest.fn(() => usersMock);
// Argument of type 'Mock<{ name: string; }[], []>' is not assignable to parameter of type 'Fetch<any>'.
const result = await users.all(fetchMock);
```

型が正しい関数実装を渡せば、型チェックが通過します。  

```typescript
const fetchMock = jest.fn(async (_url: string) => response);
const result = await users.all(fetchMock);
```

`mockImplementation()` で型安全に関数を実装したい場合は `jest.fn<T, Y>()` のジェネリクスで関数の引数と戻り値の型を指定できます。

```typescript
const fetchMock = jest.fn<ReturnType<Fetch>, Parameters<Fetch>>();

// error Argument of type '() => { name: string; }[]' is not assignable to parameter of type '(url: string) => Promise<{ data: any; }>'.
fetchMock.mockImplementation(() => usersMock);

// 型が正しい実装
fetchMock.mockImplementation(async (_url: string) => response);
users.all(fetchMock);
```

他には `jest.MockedFunction<T>` で変数に型注釈を書く方法があります。  
こちらの方が、ジェネリクスの指定をシンプルに書くことができます。

```typescript
const fetchMock: jest.MockedFunction<Fetch> = jest.fn();

// error Argument of type '() => { name: string; }[]' is not assignable to parameter of type '(url: string) => Promise<{ data: any; }>'.
fetchMock.mockImplementation(() => usersMock);

// 型が正しい実装
fetchMock.mockImplementation(async (_url: string) => response);
const result = await users.all(fetchMock);
```

`jest.MockedFunction<T>` で変数に型注釈を書くやり方は、`beforeEach()` で毎回モックの実装を初期化する場合には特に有効です。

```typescript
let fetchMock: jest.MockedFunction<Fetch>;

beforeEach(() => {
  fetchMock.mockImplementation(async (_url: string) => response);
});

it('fetch all users', () => {
  const result = await users.all(fetchMock);
})
```

## スパイモックの型指定
フロントエンドの実装をしていると、次のような Storage API をラップした `Storage` クラスを書くことがあります。

```typescript
export class Storage {
  get(key: string) {
    return localStorage.getItem(key);
  }
}
```

このクラスをテストしたい場合には `localStorage.getItem` をモックしてテストを書く必要があり、このようなモジュールの一部の関数だけをモックしたい場合には `jest.spyOn()` を利用してテストを書くことができます。

`jest.spyOn()` を普通に書く場合には、型推論によって型が決定されるため、そのままでも型安全に書くことができます。

```typescript
import { Storage } from "./storage";

describe("Storage", () => {
  it("get data", () => {
    const storage = new Storage();
    const spyGet = jest.spyOn(window.localStorage, "getItem");
    // error TS2345: Argument of type '42' is not assignable to parameter of type 'string | null'
    spyGet.mockReturnValue(42);
  });
});
```

`jest.spyOn()` でモックをする場合は、戻り値の型をジェネリクスで指定するような関数をモックする時に型に関する問題が発生します。

改めてユーザー情報の一覧を取得するモジュールを例に考えてみます。

```typescript
import axios from "axios";

export const all = () => {
  return axios.get("/users").then((res) => res.data);
};
```

今回は axios をモジュールモックせずに `axios.get` だけをモックしてテストを書いてみます。

`jest.spyOn<T, M>()` でジェネリクスを指定する場合には、モジュールの型とモックする関数名を文字列で指定します。

次のテストコードではジェネリクスで型を指定していますが、`spyAxiosGet.mockResolvedValue(usersMock)` で型エラーが発生しません。

```typescript
import axios from "axios";
import * as users from "./users";

describe("users", () => {
  it("update user", async () => {
    const usersMock = [{ name: "taro" }];
    const response: AxiosResponse = {
      data: { users: usersMock },
      status: 200,
      statusText: "OK",
      headers: {},
      config: {},
    };

    // spyAxiosGet: SpayInstance<Promise<unknown>>, ...>
    const spyAxiosGet = jest.spyOn<typeof axios, "get">(
      axios,
      "get"
    );
    // Promise<AxiosResponse>} を返すべき所を誤って User[] を返している
    // 型エラーになって欲しいがエラーにならない
    spyAxiosGet.mockResolvedValue(usersMock);
  });
});
```

`jest.spyOn()` と `axios.get()`の型定義をそれぞれ見てみると、`jest.spyOn()` の `SpyInstance<ReturnType<Required<T>[M]>, ...>` の部分で関数の型を取得していますが、関数のジェネリクスを指定していないため、`axios.get()` の戻り値は `Promise<unknown>` となってしまいます。

その結果 `spyAxiosGet` の変数が `SpayInstance<Promise<unknown>>, ...>` という型注釈となります。

上のテストコードでは `spyAxiosGet` の戻り値の型が `Promise<unknown>` となるため型エラーとならないのです。

```typescript
// jest/index.d.ts
function spyOn<T extends {}, M extends FunctionPropertyNames<Required<T>>>(
    object: T,
    method: M
): Required<T>[M] extends (...args: any[]) => any
    ? SpyInstance<ReturnType<Required<T>[M]>, ArgsType<Required<T>[M]>>
    : never;

// axios/index.d.ts
get<T = any, R = AxiosResponse<T>, D = any>(url: string, config?: AxiosRequestConfig<D>): Promise<R>;
```

この問題は型アサーションで `spyAxiosGet` の型を上書きすることで解消できます。

ここで `jest.fn()` と同様に型注釈で書こうとすると、戻り値の型が `Promise<unknown>` と`Promise<Partial<AxiosResponse<users.User[]>>>` で不一致が発生するので上手くいきません。

```typescript
const spyAxiosGet = jest.spyOn(axios, "get") as jest.SpyInstance<
  Promise<Partial<AxiosResponse>>
>;

// error Argument of type '{ name: string; }[]' is not assignable to parameter ...
spyAxiosGet.mockResolvedValue(usersMock);

// 型エラーは解消される
spyAxiosGet.mockResolvedValue(response);
```

## さいごに
自分のググり力が低いせいかTypeScriptをちゃんと書き始めた頃(2,3年前？)は、ここら辺の情報を検索しても全く見つけることが出来ませんでした。

ライブラリの型定義ファイルをちゃんと読むようにしたら、この型定義を使えば良いのか！このジェネリクスを指定すれば良いのか！と型の指定方法が分かるようになってきました。  

TypeScriptを書き始めて他のライブラリで似たような問題に直面している方がいたら、一歩踏み出してライブラリの型定義ファイルをしっかり読む事から始めてみると色々と型について理解できてくるのでオススメです。


この記事はタイムリープTypeScript 〜TypeScript始めたてのあの頃に知っておきたかったこと〜の5日目の記事です。自分がTypeScriptを書き始めた頃に苦労したのが、Jestでテストを書くときのモックの型をどう書けば良いか分からないことでした。

TypeScript+Jestでテストを書くときに型安全にモックする方法を教えてほしかった


## 問題
自分は普段 Emacs キーバインドを利用しているのですが、Alfred の検索結果でカーソル移動をするために Ctrl + N をタイプするとカーソル移動せずにパッケージが選択される問題に悩まされていました。

<img src="/images/posts/alfred-ctrl-n/alfred-ctrl-n-bad.gif" alt="ctrl+nでパッケージ選択される" width="840" height="572" />

## 解決策
Alfredの設定で Features > Actions > Show Actions で ctrl のチェックボックスを外せば問題は解消しました。

<img src="/images/posts/alfred-ctrl-n/alfred-settings.jpeg" alt="Alfredの設定画面" width="2280" height="826" />


Alfred で Ctrl + N でパッケージ選択できない問題を解消

Alfred で Ctrl + N でカーソル移動ができない問題を解消


TypeScript Playground はURLを共有するだけでコードの共有が簡単にできるようになっています。  
外部にコードが保存されるという訳でもないので、どういう仕組みで共有が実現されているか気になったので、調べてみました。

## 仕組み
仕組みとしては以下の流れでURLを通してコード共有がされていました。

1. エディターに記述してあるコードを文字列圧縮ライブラリで圧縮
2. URLに圧縮した文字列を挿入
3. URLを開くときに圧縮された文字列を展開してエディターにコードとして表示する

## コードの文字列圧縮
コードの圧縮処理は[ここのコード](https://github.com/microsoft/TypeScript-website/blob/1e7ea49f60953aa446b591c6aff347a7c566e3cb/packages/sandbox/src/compilerOptions.ts#L85) で処理がされており、[lz-string](https://pieroxy.net/blog/pages/lz-string/index.html) という文字列圧縮ライブラリが使われていました。

```typescript
  const hash = `code/${sandbox.lzstring.compressToEncodedURIComponent(sandbox.getText())}`
```



TypeScript Playground はURLを共有するだけでコードの共有が簡単にできるようになっている。その仕組みを調べてみました。

TypeScript Playground のコード共有の仕組み


[@money166](https://twitter.com/money166)  
[@tatsuo48](https://github.com/tatsuo48)  
と一緒に今年も YO!HEYHEYHEY! として [ISUCON11](https://isucon.net/archives/55706291.html)に参加してきました。

今年も非常に楽しく参加できました。  
運営の皆さま、ありがとうございました！

## 結果
予選の結果は参考スコアで 47258 で全参加チーム598チーム中80位でした。  
[ISUCON11 オンライン予選 全てのチームのスコア（参考値） : ISUCON公式Blog](https://isucon.net/archives/56021246.html)

17:00以降の固定ダッシュボードで25位まで上昇していたので、これは！？と思ったのですが、壁は厚かったです。

<img src="/images/posts/isucon11/dashboard-last-score.jpg" alt="ダッシュボードでの最終スコア" width="1798" height="330" />

5年間毎年参加して、ずっと初期実装のスコアから大きく点数を上げられなかったので、6年目の今年は非常に大きな進歩があって嬉しかったです！

## テーマ
今年のアプリケーションのテーマは自分が持っている椅子の状態を監視するWebサービスでした。  
登録している椅子が定期的にサーバーに自身の状態を送信して、ユーザーはその状態をWebサービスで確認することで椅子の状態を管理できます。

いわゆる IoT です。

サービスの説明からも予想できる通り、今年は常に大量のデーターがサーバーに送信されDBに書き込まれ続けるので、DBのCPU負荷が常に高い状態でした。（ベンチ回したら最初からCPU負荷が150%とか出ていました）  
このDB負荷をどう処理するかが問題のキーとなっている印象でした。

## 振り返り
### 良かった点
- 今年はZoomで繋いでオンラインで作業をしており、画面共有などでチームでの作業がやりやすかった
- ベンチ回して効果が無い場合は前の状態に戻す徹底できたので、アプリケーションが動かなくなる問題が発生しなかった
- 基本は2人以上のペアプロを意識して進めたので、それによって気付ける事が多かった
	- ボトルネックの原因とか
- しっかりマニュアルを読み込んでスコア計算の仕様を意識して対応方針が決められた
- Miroでタスク管理して誰が何をやっているか把握しながら進められた

### 反省点
- Go言語をあまり勉強しておらずアプリケーションの修正に時間がかかった
- 勉強不足で New Relic での DB の監視を導入できなかった
- 全体的にスコア上がってから次の一手が思いつかず頭打ちになった

## チームでやったこと
- インフラ環境の初期構築をしてサーバーを立ち上げ
- 当日マニュアルやアプリケーションマニュアルを熟読
- アプリケーションを実際に動かして機能一覧を把握
- 競技用サーバーへのデプロイ環境の整備
- アプリケーションに New Relic のエージェントを追加
- DBのスキーマ情報を整理
- New Relic のダッシュボードでHTTPリクエストを確認してボトルネックを調査して対応方針を検討
- **==== ↓ ここからボトルネック対応 ====**
- サーバー構成を サーバー1:DB, サーバー2: アプリケーション に変更: 1000 => 8000
- isu テーブルで画像カラムをクエリしない修正を追加: スコア変わらず
- 椅子の状態のデータ送信をサーバー3台に分散: スコア変わらず
- 椅子の状態のDBへの書き込みをバルクインサートに変更: 上手く実装できず
- サーバー構成を サーバー1: DB, サーバー2: アプリケーション, サーバー3: 椅子状態のデータ受信 に変更: スコア変わらず
- 対応方針を再検討
- isu_condition の jia_isu_uuid にインデックスを追加: 8000 => 25000
- isu_condition の timestamp にインデックスを追加: 25000 => 28000
- データを捨てる割合を 90% => 75% に変更: 28000 => 33000
- 画像をクライアントにキャッシュさせる: 対応が上手くできなかった
- Nginx や アプリケーション のデバッグログを停止: 33000 => 35000 （影響あった気がする）
- /api/trend のリクエストもサーバー3に流すように変更: 35000 => 47000

### アプリケーションを実際に動かして機能一覧を把握
今回は例年と比べてアプリケーション規模が小さい？印象だったので、全体の把握がスムーズにできた。  
オープニングでの事前のサービス紹介で概要が掴めたのも大きかった。

### New Relic の Go エージェントの追加
次のドキュメントを参考に echo のミドルウェアとしてエージェントを追加した
- [Go向けNew Relicのインストール \| New Relic Documentation](https://docs.newrelic.com/jp/docs/agents/go-agent/installation/install-new-relic-go/)
- [Goエージェントの互換性と要件 \| New Relic Documentation](https://docs.newrelic.com/jp/docs/agents/go-agent/get-started/go-agent-compatibility-requirements/)

### HTTPリクエストを確認してボトルネックを調査して対応方針を検討
リクエストの大半は `POST /api/condition/:jia_isu_uuid` が占めていた。  
これは椅子の状態を受け取ってDBに書き込むAPIエンドポイントなので、当初の想定通り。

`GET /api/trend` が最大で60sec、平均しても20secのレスポンス時間となっていた。

上記2つのAPIエンドポイントに絞って、実装の詳細を確認しながらボトルネックの調査と対応方針を決めた。

### サーバー構成を サーバー1:DB, サーバー2: アプリケーション に変更: 1000 => 8000
DBのCPU負荷が150~180%とかなり高かったので、サーバー1をDB専用にして、リクエストをサーバー２で捌くように変更した。

7000点ほどスコアが上昇

### isu テーブルで画像カラムをクエリしない
isu_conditions テーブルには画像がバイナリで含まれていた。  
/api/trend では `SELECT * FROM isu` と未使用にも関わらず画像カラムも取得していたので、これで読み込みに時間がかかってレスポンス時間に影響していると予測して、必要なカラムだけをクエリするようにしたが、大きな変化は無かった。

```go
- "SELECT * FROM `isu` WHERE `character` = ?",
+ "SELECT `id`, `jia_isu_uuid` FROM `isu` WHERE `character` = ?",
```

### 椅子の状態のデータ送信をサーバー3台に分散
椅子状態のデータ送信が大量にリクエストされているので、これにより他のリクエストが待機状態で捌かれていないのでは？と思い3台にリクエストを分散してみた。  
あまり効果は無かった。

```go
- postIsuConditionTargetBaseURL string // JIAへのactivate時に登録する，ISUがconditionを送る先のURL
+ postIsuConditionTargetBaseURLs []string // JIAへのactivate時に登録する，ISUがconditionを送る先のURL

=======

- postIsuConditionTargetBaseURL = os.Getenv("POST_ISUCONDITION_TARGET_BASE_URL")
- if postIsuConditionTargetBaseURL == "" {
-	e.Logger.Fatalf("missing: POST_ISUCONDITION_TARGET_BASE_URL")
	return
}

+ postIsuConditionTargetBaseURLs = strings.Split(os.Getenv("POST_ISUCONDITION_TARGET_BASE_URLS"), ",")
+ if postIsuConditionTargetBaseURLs == nil {
+	e.Logger.Fatalf("missing: POST_ISUCONDITION_TARGET_BASE_URLS")
		return
}
```

### サーバー構成を変更
引き続き椅子状態のHTTPリクエストにより /api/trend などの他のリクエストが待ち状態になっていると推測して、POST /api/condition/:jia_isu_uuid へのリクエストだけを全て別サーバーで処理するように変更した。

スコアへの影響は無かったが、CPU負荷は分散された。

- サーバー1: DB
- サーバー2: アプリケーション
- サーバー3: 椅子状態のデータ受信とDBへの書き込み

### 対応方針を再検討
最初に目星をつけた対応を色々と試したが結果が出なかったので、改めて対応方針を検討した。

ベンチマークをログを見ていると「タイムアウトが多く発生しているため、サービスの評判が下がりこれ以上ユーザーは増えません」という怪しげなログを発見。  
ベンチマーク実行後の `user` テーブルを見てみると、ユーザー数が13人しか登録されていなかった。

改めて当日マニュアルのスコア計算の仕様を読み直すと  
> スコアはユーザーがISUのコンディションやスコアを確認すると加点されます。

との事なので、

新規ユーザーは最初にTOPページにアクセスする  
=> TOPページのトレンド情報がリクエストされる  
=> リクエストがタイムアウトしてユーザーが離脱  
=> ユーザー登録されずにユーザーが増えない  
=> スコアが伸びない  

タイムアウトが大量に発生  
=> ユーザーが加点となるリクエストができない  
=> スコアが増えない  

という2つのシナリオを仮定して、スコアを伸ばすためにはユーザーを増やす必要がありそうと判断

そのためには、ログにも出ているタイムアウトを改善する必要があり、タイムアウトとなっているリクエストは明らかに `/api/trend` だったので、このエンドポイントを改善する方針でボトルネック調査を継続

### isu_condition の jia_isu_uuid にインデックスを追加: スコア改善: 8000 => 25000
改めて `/api/trend` のボトルネックを考えていたら `isu_condition` への書き込みが常に発生しているので、テーブルロックが発生して `isu_condition` の読み込みが待ち状態になっている影響で時間がかかっているのでは？と推測

実際に調べてみたら
> InnoDBは行ロックだが、ユニーク制約 or インデックスが張られていないカラムで検索した場合はテーブルロックになってしまう。  

[InnoDBで行ロック/テーブルロックになる条件を調べた \#mysqlcasual Advent Calendar 2013 \- あおうさ＠日記](https://bluerabbit.hatenablog.com/entry/2013/12/07/075759)

という情報を発見  

`/api/trend` は以下のクエリでデータを読み込んでおり、テーブルロックによるりデータの読み込みが待ち状態になっている可能性がありそうだったので、検索カラムにインデックスを追加した。

```sql
SELECT * FROM `isu_condition` WHERE `jia_isu_uuid` = ? ORDER BY timestamp DESC
```

```sql
+ CREATE INDEX jia_isucon_uuid_index ON isu_condition(jia_isu_uuid);
```

この修正 `/api/trend` のレスポンス時間が改善されて、スコアが大幅に上昇した。

### isu_condition の timestamp にインデックスを追加: 25000 => 28000
同様の理由で `isu_condition` の `timestamp` にもインデックを追加して、スコアが上昇

```sql
+ CREATE INDEX jia_isucon_uuid_timestamp_index ON isu_condition(jia_isu_uuid, timestamp);
```

### データを捨てる割合を 90% => 75% に変更: 28000 => 33000
初期実装では受信した椅子の状態の90%を捨てる実装になっていた。

```go
// TODO: 一定割合リクエストを落としてしのぐようにしたが、本来は全量さばけるようにすべき
dropProbability := 0.9
if rand.Float64() <= dropProbability {
	c.Logger().Warnf("drop post isu condition request")
	return c.NoContent(http.StatusAccepted)
}
```

> ISU のコンディション確認（GET /api/condition/:jia_isu_uuid）で、ユーザが前回確認したコンディションより新しいコンディションを確認した際に加点

スコア計算では、ユーザーが新しい状態を確認した時に加点の対象となるため、椅子の状態を捨てていると加点の機会を大きく損なってしまうので、ここの割合を75%に減少させる調整を実施して、スコアが上昇した。

```go
- dropProbability := 0.9
+ dropProbability := 0.75
```

### 画像をクライアントにキャッシュさせる
ここまでの改善で新たに椅子の画像を取得する `GET /api/isu/:jia_isu_uuid/icon` が新たなボトルネックのエンドポイントとして浮上してきた。

ここは明らかにDBにバイナリで画像を保存している事による影響だと考えて、クライアント側に画像をキャッシュさせる対応を試みたが、上手く対応できなかった。

### ログの停止: 33000 => 35000
競技も終盤になっていたので、Nignx や アプリケーションのデバッグログ出力を停止した。  
ちゃんと覚えてないが、スコアが僅かに改善した気がする。

### トレンドのリクエストもサーバー3に流すように変更: 35000 => 47000
全体のCPU負荷を見ていて、サーバー2: アプリケーション のCPU負荷が高く、 サーバー3: 椅子の状態受信 のCPU負荷が低かったので、負荷を分散するために思い切って `/api/trend` のリクエストをサーバー3へリダイレクトする対応を追加

これが見事に成功してCPU負荷が分散されて、スコアが大幅に上昇した。

### 競技終了
17:00で更新が停止された状態でのダッシュボード上での最終スコア  

<img src="/images/posts/isucon11/dashboard-last-score.jpg" alt="ダッシュボードでの最終スコア" width="1798" height="330" />


ISUCON11予選に参加して自己ベストを更新しました

神奈川の田舎で働いてるフロントエンドエンジニアのブログ