【新人プログラマ応援】他の人の目に触れるテストデータを「hoge」とか「あああ」にしない

はじめに

さてみなさん、ここにとあるwebアプリケーションがあります。
以下のスクショを見て、このアプリケーションの用途や使い方を想像してみてください。

わかりにくい場合は、もう一つのスクショを参考にしてもらってもOKです。

いかがでしょう？
画面上には「Projects」とか「Tasks」といった文言が見えるので、おそらくプロジェクトを管理するためのwebアプリケーションなんかな〜？（知らんけど）、みたいな感想を抱いたのではないでしょうか？

では、次のスクショだったらどうでしょうか？

こちらのスクショでは、実際のユースケースに近いリアルなテストデータを使ってみました。
「hoge」や「ああああ」のようなテストデータに比べると、アプリケーションの使い方がずいぶんイメージしやすくなったのではないでしょうか？

「hoge」や「あああ」よりも、リアルなテストデータを！

ローカル環境でデータの保存や表示の動作確認をする場合、ちょっとでも時間を短縮したくて、以下のような適当なテストデータを使いたくなる気持ちはよくわかります。

• hoge, fuga, piyo
• foo, bar, baz
• テストテスト
• ああああああ
• aaaaaaa
• cxdvsdf89dfskj2q30 （キーボード適当連打系）

しかし、こういった適当なテストデータを他の人に見せるデモンストレーションで使うのはやめましょう。
こうした適当なテストデータを使うと、他の人が見たときにアプリケーションの用途や使い方がイメージしにくくなります。

また、それだけでなく、そのアプリケーションの見栄えや印象も悪くなってしまいます。
もしあなたが先ほどのプロジェクト管理アプリケーションを作ってほしいと依頼したプロダクトオーナーだった場合、開発者AさんとBさんの、どちらの画面を見せてもらうと嬉しいでしょうか？

🤪 開発者Aさん「できました。見てください！」

😃 開発者Bさん「できました。見てください！」

おそらく、ほとんどの人が「Bさんの見せてくれた画面の方が嬉しいな」という印象を抱くのではないでしょうか？

ただし、ユーモアやおふざけには要注意

リアルなテストデータを用意する場合、人によってはちょっとしたユーモアを含めたくなることがあるかもしれません。

ユーモアやおふざけは、開発プロジェクトを楽しむアクセントになることもありますが、その一方で思いがけない事故の原因にもなりえるので要注意です。
というのも、そういうふざけたデータに限って、奇跡的な確率で外部に公開されたりしてしまうからです。

出典 [新卒向け研修資料] テスト文字列に「うんこ」と入れるな（2024年版）

ですので、「最悪、外部に公開されても大きな問題にならないようなテストデータ」を入力するようにしましょう。

ChatGPTにデータを作ってもらうのも一手

自分で考えるのが面倒な場合はChatGPTのような生成AIに作ってもらうのも良いと思います。

入力プロンプトの例

プロジェクト管理するwebアプリケーションを開発しているので、
シンプルなテストデータをプレーンテキストで用意してほしい。
項目は以下の通り。

- プロジェクト名
- プロジェクトの説明文
- プロジェクトに付随するタスク
- プロジェクトに関連するメモ

ChatGPTが生成したテストデータ

プロジェクト名: 新規ウェブサイト構築
プロジェクトの説明文: クライアント向けの新しいウェブサイトをデザインし、開発するプロジェクト。
プロジェクトに付随するタスク:
  - ワイヤーフレームの作成
  - カラースキームとフォントの選定
  - ホームページのコーディング
  - テストとフィードバック収集
  - サーバーへのデプロイ
プロジェクトに関連するメモ:
  - 締め切り: 2025年2月15日
  - クライアントからの要望: モバイルフレンドリーであること
  - 週次の進捗報告会議を設定

実際に入力してみるとこんな感じになりました。
なかなか良さそうですね！

おふざけデータもChatGPTにおまかせ！？

ちなみに、先ほどお見せした「デスマーチ 〜死の行進プロジェクト〜」のスクショで使った説明文もChatGPTに作ってもらったものですw

長文のテストデータはlorem ipsumを使う

ダミーテキストとして長文が必要になる場合は、lorem ipsumを使いましょう。

lorem ipsum（ロレム・イプサム、略してリプサム lipsum ともいう）とは、出版、ウェブデザイン、グラフィックデザインなどの諸分野において使用されている典型的なダミーテキスト（英語版）。書籍やウェブページや広告などのデザインのプロトタイプを制作したり顧客にプレゼンテーションしたりする際に、まだ正式な文章の出来上がっていないテキスト部分の書体（フォント）、タイポグラフィ、レイアウトなどといった視覚的なデザインを調整したりわかりやすく見せるために用いられる。

lorem ipsum - Wikipedia

以下がそのlorem ipsumのダミーテキストです。

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

欧文ではなく、日本語の長文が必要な場合、「lorem ipsum 日本語」のようなキーワードで検索すると各種ジェネレータが見つかります。

以下は すぐ使えるダミーテキスト - 日本語 Lorem ipsum を使って生成したダミーテキストです。

私は以後もしその混同式という事のうちを打ち壊さでん。どうか今日に相違院はいよいよそんな賞翫んたでもにしていただきませには教育伴っならなかって、こうにも推しでありませまい。順序がなるますものはもっともその間をむしろですたでし。

もちろん、ChatGPTに「日本語版lorem ipsumを作って」とお願いするのもアリです。

吾輩は牛である、名前はまだない。青い空を見上げながら、ふとした瞬間に思い浮かぶ言葉がある。例えば、春風の吹く日々、そして夕暮れの静寂。人々はいつも何かを追い求め、旅路の途中で出会いと別れを繰り返す。

こうした長文はいずれも意味のない文章なのでこれ自体はリアルなテストデータとは言えません。
ですが、長文のテストデータは視覚的なデザインの確認に使われることが多いため、意味が通じなくてもそれっぽく見えれば十分であるケースがほとんどです（「あああ...」や「テストテスト...」を表示するよりはまし、という感じです）。

自動テストのテストデータも考え方は同じ

ここまでは他の人に見せるデモンストレーションを想定した内容を書いてきましたが、同じことは自動テストのテストデータにも言えます。

あなたが既存の開発プロジェクトに途中参加したプログラマだった場合、開発者Aさんの書いた既存のテストコードと、開発者Bさんの書いた既存のテストコードでは、どちらが嬉しいでしょうか？

🤪 開発者Aさん「自動テスト、書いておきました！」

click_link "New Project"
fill_in "Name", with: "テストプロジェクト"
fill_in "Description", with: "テストテスト"
click_button "Create Project"

expect(page).to have_content "Project was successfully created"
expect(page).to have_content "テストプロジェクト"
expect(page).to have_content "テストテスト"

😃 開発者Bさん「自動テスト、書いておきました！」

click_link "New Project"
fill_in "Name", with: "Rails 8アップグレード"
fill_in "Description", with: "Rails 7から8へ移行するプロジェクトです。"
click_button "Create Project"

expect(page).to have_content "Project was successfully created"
expect(page).to have_content "Rails 8アップグレード"
expect(page).to have_content "Rails 7から8へ移行するプロジェクトです。"

まあ、これぐらいのコード量であればAさんの書いたテストコードでもまだ理解できるかもしれませんが、これが「ほとんど予備知識のない事業ドメインで利用される、巨大で複雑なアプリケーション」になってくると、「テストテスト」のようなテストデータばかりでは、その機能のユースケースをイメージするのが非常に困難になります。

「他の人の目に触れるテストデータ」という意味では、デモンストレーションで使うテストデータも、自動テストで使うテストデータも役割は同じです。
どちらも「hoge」や「あああ」みたいなテストデータは避け、できるだけリアルなテストデータを用意しましょう。

補足："aaa..."でもOKなケースもある

文字数チェックのような特殊な用途であれば、"aaa..."みたいなデータでもOKです。

# 1000文字を超えるDescriptionはエラー
invalid_text = "a" * 1001
fill_in "Description", with: invalid_text
click_button "Create Project"
expect(page).to have_content "Descriptionは1000文字以下で入力してください。"

プルリクに載せるスクショも考え方は同じ

この考え方はプルリクに載せるスクショも同様です。
もしあなたがレビュアーだったら、どっちのプルリクの内容をイメージしやすいでしょうか？

🤪 開発者Aさん「レビューお願いします！」

😃 開発者Bさん「レビューお願いします！」

プログラムを実装した本人は「ここにプロジェクトの内容が表示されるんです」とわかっていても、それを初めて見るレビュアーはすぐにわかるとは限りません。
レビュアーの視点に立って、わかりやすいスクショを貼り付けましょう。

まとめ

本記事では以下のような話を書きました。

• 他の人の目に触れるテストデータは「hoge」とか「あああ」ではなく、できるだけリアルなテストデータを使う
• リアルなテストデータはアプリケーションの用途や目的を理解しやすくしてくれる
• 「他の人の目に触れるテストデータ」は、デモンストレーションで使うデータだけでなく、自動テストのテストコードやプルリクのスクショも含まれる
• ただし、へたなユーモアやおふざけ精神を発揮すると、思いがけない事故を招くので要注意
• いい感じテストデータを編み出すのが面倒な場合はChatGPTに考えてもらおう

繰り返しになりますが、あなたはこんなテストデータを他の人に見せていませんか？

• hoge, fuga, piyo
• foo, bar, baz
• テストテスト
• ああああああ
• aaaaaaa
• cxdvsdf89dfskj2q30

時間がなくてついつい「hoge」とか「あああ」みたいなテストデータを使いたくなる気持ちはわかりますが、人に見せる機会のあるテストデータは、それなりにちゃんとしたものを用意しましょうね！

あわせて読みたい

テストデータで使うメールのドメインも @foo.com や @hoge.com みたいなデタラメなドメインを使うのはやめましょう。
それ、デタラメじゃなくてむしろ実在するドメインですよ！

参考：本記事で使用したサンプルアプリについて

本記事で使用したプロジェクト管理アプリケーションは、電子書籍「Everyday Rails - RSpecによるRailsテスト入門」で使用しているサンプルアプリケーションです。

RSpecを使った自動テストをしっかり学びたい方は、ぜひ「Everyday Rails - RSpecによるRailsテスト入門」をチェックしてみてください！