841-biborokuWebフロントエンドの備忘録

無理のないテストをAstro + Vitestで始める

ユニットテストAstro

Astroでサイトを作っていると、少しずつ日付変換やデータ判定といった関数やコンポーネントが増えていきます。

そこで、Astro公式でも紹介されている「Vitest」を導入してみました。

個人の開発ではそこまで凝ったコンポーネントを作っていないので、試しに純粋なロジック関数だけ書いてみました。

Vitestの導入・設定

設定ファイルはgetViteConfigを使えば、Astroの設定をそのまま引き継いでくれるので、ほぼ記述いらずです。

  1. パッケージのインストール
    npm i -D vitest
  2. package.jsonのscriptに"test": "vitest"を追加
  3. configファイルを作成

vitest.config.ts

// vitest.config.ts
import { getViteConfig } from "astro/config";

export default getViteConfig({});

ロジック関数を準備

簡単な日本時間への変換処理関数を準備しました。

utils/date.ts

import dayjs from "dayjs";
import utc from "dayjs/plugin/utc";
import timezone from "dayjs/plugin/timezone";

// set up plugins
dayjs.extend(utc);
dayjs.extend(timezone);

/**
 * Format an ISO timestamp into Japan Standard Time date string (date only).
 *
 * Uses numeric-only format suitable for international audiences (YYYY-MM-DD).
 *
 * @param iso the ISO date/time string (UTC assumed)
 * @returns formatted string like "2026-02-28"
 */
export function formatJp(iso?: string) {
  if (!iso) return "";
  return dayjs
    .utc(iso)
    .tz("Asia/Tokyo")
    .format("YYYY-MM-DD");
}

これに対するテストファイルdate.test.tsを同階層に置きます。

utils/date.test.ts

// src/lib/date-utils.test.ts
import { describe, it, expect } from 'vitest';
import { formatJp } from './date';

describe('formatJp', () => {
  it('引数がない（undefined）場合は空文字を返すこと', () => {
    expect(formatJp()).toBe("");
  });

  it('ISO文字列を渡すと、JST（日本時間）の YYYY-MM-DD 形式に変換されること', () => {
    // UTCで 3月11日の夜
    const iso = "2026-03-11T22:00:00Z";
    // 日本時間では 3月12日の朝 7:00 になるはず
    expect(formatJp(iso)).toBe("2026-03-12");
  });

  it('不正な文字列が渡された時の挙動（dayjsの仕様に依存）', () => {
    // 現場の判断によりますが、壊れないことを確認しておくのもあり
    expect(formatJp("invalid-date")).toBe("Invalid Date");
  });
});

テストを実行する

npm run testを実行すると結果が表示されます。

うっかりミスを減らす

試しに、作成した関数から日本時間への変換処理を削除してしまったと想定して実行してみました。

この状態でファイルを保存するとVitestが再実行され、ターミナルに失敗したテストを表示してくれます。

まとめ

AIのおかげでテストを書くハードルはぐっと下がりました。

ですが実際に運用してみると「書くこと自体」よりも、「どこまで書くべきか」という判断の方が重要になってくるなと感じました。

  • 何をテストし、何を捨てるか？
  • メンテナンスコストにどれだけ時間を割けるか？

まずは小さなロジックから試し、自分の開発スタイルに合った「テストの境界線」を見つけていくのが良さそうです。

シェア

Category