Next.js on 怠惰技術ブログ

テスト前提で設計したWebアプリのハンズオン - 読書管理アプリその5

Thu, 05 Mar 2026 01:30:00 +0900

はじめに

Part4 でカスタム例外クラスと残りのエンドポイントを実装し、APIが完成した。

Part5では src/app/page.tsx に簡易UIを実装する。バックエンドのロジックやテストには一切触れない。フロントエンドからAPIを叩いて動くものを作るだけだ。

実装方針

page.tsx をClient Componentにする。

Server Componentでfetchする方法もあるが、ボタン操作のたびにstateを更新して再描画する必要がある。今回のUIは「ボタンを押す → APIを叩く → 一覧を再取得して画面を更新する」という流れが中心なので、 useState + useEffect で管理するClient Componentのほうがシンプルだ。

"use client";

ファイル先頭にこの1行を追加する。

実装するUI

本の追加フォーム（id / title / isbn）
本棚（Unread / Reading / Completed のグループ表示）
各本へのアクションボタン
- Unread → 「読み始める」ボタン
- Reading → 評価入力（1〜5）＋「読了にする」ボタン
- 全ステータス → 削除ボタン

型定義

APIレスポンスの型を定義する。

type BookStatus = "Unread" | "Reading" | "Completed";

type Book = {
  id: string;
  title: string;
  isbn: string;
  status: BookStatus;
  rating: number | null;
};

バックエンドの ReadingStatus は as const で定義した文字列リテラルなので、そのまま使える。

データ取得

async function fetchBooks() {
  try {
    const res = await fetch("/api/books");
    if (!res.ok) throw new Error("取得失敗");
    const data: Book[] = await res.json();
    setBooks(data);
  } catch (e) {
    setError(e instanceof Error ? e.message : "不明なエラー");
  } finally {
    setLoading(false);
  }
}

useEffect(() => {
  fetchBooks();
}, []);

fetchBooks は追加・ステータス変更・削除の後にも呼ぶ。サーバーの状態を正として再取得するシンプルな方針だ。楽観的更新（Optimistic Update）は今回やらない。

テスト前提で設計したWebアプリのハンズオン - 読書管理アプリその4

Thu, 05 Mar 2026 00:50:00 +0900

はじめに

Part1 でValueObject・Policy・Entityを作り、Part2 でServiceをDI＋Mockテストで固めた。 Part3 でPrismaを繋ぎ、GET /api/books と POST /api/books を動かした。

Part4では残りのエンドポイントを実装する。やることは3つ。

カスタム例外クラスの導入
PATCH /api/books/:id/start と PATCH /api/books/:id/complete の実装
DELETE /api/books/:id の実装

そして「エラー種別ごとにHTTPステータスを整理する」という設計判断を掘り下げる。

また、Part3でPrisma v7特有のセットアップをしたが、v6以前と何が変わったのかをここで整理しておく。

0. Prisma v7で何が変わったか

Part3でPrismaをセットアップしたとき、v6以前と比べていくつか「見慣れない書き方」が必要だった。 v7は破壊的変更が多く、ネット上のv6時代の記事を参考にすると詰まる箇所がある。ここで整理しておく。

参考: Upgrade to Prisma ORM 7 | Prisma Documentation

generator の変更

// ❌ v6以前
generator client {
  provider = "prisma-client-js"
}

// ✅ v7
generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}

v7では prisma-client-js が廃止され prisma-client に変わった。 Rustベースのエンジンを廃止しTypeScriptネイティブになったことに伴う変更だ。また output が必須になり、node_modules への自動生成はなくなった。

テスト前提で設計したWebアプリのハンズオン - 読書管理アプリその3

Wed, 04 Mar 2026 17:50:00 +0900

はじめに

Part1 でValueObject・Policy・Entityを作り、Part2 でServiceをDI＋Mockテストで固めた。累計13テスト、全パスの状態だ。

Part3ではいよいよDBを繋ぐ。やることは3つ。

Prismaセットアップ＋スキーマ定義
PrismaBookRepository 実装（ドメインオブジェクトへの変換）
Route HandlerでDIを組み立てる

そして最後に「テストを書かない層を意図的に決める」という話をする。

1. Prismaセットアップ

npm install prisma @prisma/client
npx prisma init --datasource-provider sqlite

prisma/schema.prisma に Bookモデルを定義する。

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "sqlite"
  url      = env("DATABASE_URL")
}

model Book {
  id     String  @id
  title  String
  isbn   String
  status String
  rating Int?
}

User と Review はまだDBに持たない。Book の CRUD が動けば Part3 のゴール。

なぜ `status` を String で持つのか

Prismaは SQLiteで enum をネイティブサポートしていない。そのため status String で持ち、取り出し時に as ReadingStatus でキャストする。

テスト前提で設計したWebアプリのハンズオン - 読書管理アプリその2

Wed, 04 Mar 2026 02:00:00 +0900

前回のおさらい

その1では ValueObject・Policy・Entity を作った。ポイントは「フレームワークを一切使わないので、テストがただの関数呼び出しになる」という体験だった。

今回はいよいよ Service 層に入る。ここが設計の核心だ。 複数のクラスをまたぐフローを、DI（依存性の注入）を使って DB から切り離す。

今回追加したもの

src/
  domain/
    entity/
      User.ts              # 追加
      Review.ts            # 追加
    valueobject/
      UserName.ts          # 追加
      ReviewComment.ts     # 追加
  repository/
    BookRepository.ts      # 追加（Interface）
  service/
    BookShelfService.ts    # 追加

User と Review を追加する

まず Entity の準備。今回は単純なので ValueObject から作る。

UserName

export class UserName {
  constructor(public readonly value: string) {
    if (!value || value.trim().length === 0) {
      throw new Error("UserNameは空にできない");
    }
    if (value.length > 50) {
      throw new Error("UserNameは50文字以内");
    }
  }
}

trim() してから空チェックしているのがポイント。スペースだけのユーザー名を弾く。

ReviewComment

export class ReviewComment {
  constructor(public readonly value: string) {
    if (!value || value.trim().length === 0) {
      throw new Error("ReviewCommentは空にできない");
    }
    if (value.length > 1000) {
      throw new Error("ReviewCommentは1000文字以内");
    }
  }
}

User Entity

import { UserName } from "../valueobject/UserName";

export class User {
  constructor(
    public readonly id: string,
    public readonly name: UserName,
  ) {}
}

User 自体はシンプルだ。ロジックがない。ビジネスルールが増えれば changeXxx() メソッドが生える設計だが、今は id と name を持つだけでいい。

テスト前提で設計したWebアプリのハンズオン - 読書管理アプリその1

Wed, 04 Mar 2026 01:00:00 +0900

なぜこの記事を書いたか

動くものをまず作って、そこにテストを後付けしようとした。しかし、できなかった。

具体的にはこういう壁にぶつかった。

ModelなどのDB接続の切り替えがうまくいかない
Controllerをテストしようにもいろいろおかしくなる

悩んだ結果、気づいたことがある。そもそもそんなものは単体テストじゃない。 ロジックをControllerやModelに全部書いていたのが悪かった。

「じゃあ最初からそう書けばいいじゃないか」という話だが、それが難しい。雑魚プログラマにいきなりクリーンな設計はできない。

なので発想を逆にした。テスト前提でコードを書く。 テストが書けない場所にはロジックを書かない。それを体で覚えるために、今回のハンズオンを始めた。

方針

生成AIに実装ヒントと次のステップを教えてもらいながら、コードは自分で書く。

正直、コード自体はAIに書かせてもいいと思っている。ただ、設計の考え方は頭に入れる必要があるので、写経しながら理解を深めている。

テストする場所の原則はシンプルだ。

フレームワークで用意された便利クラスはテストしない
DBやAPIなど外界と接する場所はテストしない
自分で書いた純粋なTS部分だけをテストする

作るもの

読書レビューサイト。Todoアプリはビジネスロジックがほぼ存在しないのでテストの練習に向いていない。読書レビューサイトなら本の状態遷移（積読→読中→読了）などのルールが自然に生まれるので、テストの旨味がある。

技術スタック

Next.js
SQLite + Prisma
vitest

ディレクトリ構成

src/
  domain/
    entity/
    valueobject/
    policy/
  service/
  repository/

この構成の考え方は以下の通り。

層	役割
entity	概念そのもの（Book, User）
valueobject	値の制約を持つクラス（ISBN, Rating）
policy	ビジネスルールを切り出したクラス
service	複数クラスをまたぐフロー
repository	DBとのアダプタ（副作用をここに閉じ込める）

repositoryはCI4でいうModelに近い立ち位置だ。 ただし決定的な違いがある。CI4のModelはActiveRecordパターンでクラス自身がDBを知っているため切り離せないが、repositoryはInterfaceと実装を分けることで差し替え可能にする。これがDI（依存性の注入）の肝で、テスト時にMockに差し替えられる。

vitestのセットアップ

npm install -D vitest @vitejs/plugin-react vite-tsconfig-paths
npm install -D @testing-library/react @testing-library/jest-dom

vitest.config.ts

import { defineConfig } from 'vitest/config'
import react from '@vitejs/plugin-react'
import tsconfigPaths from 'vite-tsconfig-paths'

export default defineConfig({
    plugins: [react(), tsconfigPaths()],
    test: {
        environment: 'jsdom',
        globals: true,
        setupFiles: ['./src/test/setup.ts'],
    },
})

package.jsonのscriptsに追加。

Next.js on 怠惰技術ブログ

テスト前提で設計したWebアプリのハンズオン - 読書管理アプリ その5

はじめに

実装方針

実装するUI

型定義

データ取得

テスト前提で設計したWebアプリのハンズオン - 読書管理アプリ その4

はじめに

0. Prisma v7で何が変わったか

generator の変更

テスト前提で設計したWebアプリのハンズオン - 読書管理アプリ その3

はじめに

1. Prismaセットアップ

なぜ status を String で持つのか

テスト前提で設計したWebアプリのハンズオン - 読書管理アプリ その2

前回のおさらい

今回追加したもの

User と Review を追加する

UserName

ReviewComment

User Entity

テスト前提で設計したWebアプリのハンズオン - 読書管理アプリ その1

なぜこの記事を書いたか

方針

作るもの

ディレクトリ構成

vitestのセットアップ

テスト前提で設計したWebアプリのハンズオン - 読書管理アプリその5

テスト前提で設計したWebアプリのハンズオン - 読書管理アプリその4

テスト前提で設計したWebアプリのハンズオン - 読書管理アプリその3

なぜ `status` を String で持つのか

テスト前提で設計したWebアプリのハンズオン - 読書管理アプリその2

テスト前提で設計したWebアプリのハンズオン - 読書管理アプリその1