Goプロダクトにおけるテスト改善の軌跡

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Goプロダクトにおけるテスト改善の軌跡自己紹介  名前  清川航一 (𝕏 @kiyoshiro944)  おしごと  ・おもにフロントエンド(React/TypeScript 6年ほど) 👈のちの伏線  ・バックエンドもぼちぼち書く(Go歴 3年ほど)   ・分析クエリ書いたりも   所属    　　　　　　　　　　　　　　　　　　　　　　ポイントクラブチーム   　　　　　　　　　　　　　　　　　　　　　　新卒3年目         2

Slide 3

Slide 3 text

Goプロダクトにおけるテスト改善の軌跡お話すること  3 • 新卒でチームにジョインして、生まれてはじめてGoのプロダクトに触れた自分が、3年の間にテストでどのような課題を発見して、解決し、学びを得たか  • テスト：おもにユニットテスト 

Slide 4

Slide 4 text

Goプロダクトにおけるテスト改善の軌跡もくじ  • 課題と改善  • ゴールデンテスト導入  • モックの引数検証  • 過剰なテーブル駆動をやめる  • まとめ  • 今後やりたいこと  4

Slide 5

Slide 5 text

Goプロダクトにおけるテスト改善の軌跡もくじ  • 課題と改善  • ゴールデンテスト導入  • モックの引数検証  • 過剰なテーブル駆動をやめる  • まとめ  • 今後やりたいこと  5

Slide 6

Slide 6 text

Goプロダクトにおけるテスト改善の軌跡課題：出力値(actual)のコピペがつらい    •   改善１. ゴールデンテスト導入 - 課題  🤔「どんなエラー文が返ってくるかわからない」 💪「一旦落ちる前提でテスト実行してみて、 actualの値をコピってくるか」 ※今回の例ではそもそも完全一致でアサーションしているのが問題ではあります。実際はもっと事情が複雑でしたが割愛。そしてある日、仕様変更によりテストが 20〜30箇所落ちた  😇「これ全部出力値のコピペで修正するのか…」   👉 6

Slide 7

Slide 7 text

Goプロダクトにおけるテスト改善の軌跡自分🤔「フロントエンドだったらスナップショットテスト使うかもな」   スナップショットテスト（Go界隈ではゴールデンテスト）  改善１. ゴールデンテスト導入 - 改善  7 テスト対象  入力  出力  テスト１回目      { “a”: 1, “b”: 2 } ファイルに保存  テスト対象      入力  出力  テスト２回目以降      ゴールデンファイル  一致するか比較 

Slide 8

Slide 8 text

Goプロダクトにおけるテスト改善の軌跡改善１. ゴールデンテスト導入 - ライブラリの選定  8 cupaloy  goldie  自前でヘルパー関数つくる   ⭐300ちょっと  ⭐200ちょっと  ー  最終コミット3ヶ月前  その前のコミットは１年前   最終コミット4ヶ月前  その前のコミットは２年前   ー  ・どちらも開発が活発とは言えない状態だった 😢  ・機能・APIに大差はなかった   現実的な工数で作れそうではあるが大変  ・ゴールデンファイルがなければ作成。あれば比較する処理を実装  ・ゴールデンファイルを書き出すディレクトリ名、ファイル名を決定  ※選定を行った2022/12当時のデータ。他にもライブラリはたくさんあったが当時は3つのみ比較した   ※納期が迫っており、選定にそこまで工数をかけられなかった 😢 

Slide 9

Slide 9 text

Goプロダクトにおけるテスト改善の軌跡 • 良かった点   👍ゴールデンテストの導入により、出力値のコピペをしなくてよくなった  👍ライブラリ更新などで出力値が変わったときもゴールデンファイルを  コマンド一発で更新できる  • 注意点  • 更新が簡単な分、ゴールデンファイルは思考停止で更新されがち。  コードレビューで、差分が妥当かも確認する必要あり  • ゴールデンファイルが大きくなりすぎると、この差分の確認が大変なので、入力値を調整する必要あり  　󰢃出力が1000件のスライス  　󰢏出力が5件のスライス  改善１. ゴールデンテスト導入 - 導入してみて  9

Slide 10

Slide 10 text

Goプロダクトにおけるテスト改善の軌跡 • 課題  テスト出力値のコピペが辛い  • 解決法  フロントエンドで使われるスナップショットテストから着想を得て、cupaloyというライブラリを採用しゴールデンテストを導入  • 学び  フロントエンドのテストの知識がGoプロダクトのテストでも活かせる  改善１. ゴールデンテスト導入 - まとめ  10

Slide 11

Slide 11 text

Goプロダクトにおけるテスト改善の軌跡もくじ  • 課題と改善  • ゴールデンテスト導入  • モックの引数検証  • 過剰なテーブル駆動をやめる  • まとめ  11

Slide 12

Slide 12 text

Goプロダクトにおけるテスト改善の軌跡課題：テストカバレッジは高いのに  本番反映前にステージング環境で  動作確認するとバグがみつかる  改善２. モックの引数検証 - 課題  12

Slide 13

Slide 13 text

Goプロダクトにおけるテスト改善の軌跡 13 • 外部の人にも伝わるように仕様をシンプルにしたもの(※実サービスの仕様とは異なります)   • ゲームクリア時に新規ユーザーには100pt, それ以外には1pt付与する実装   • 正常系テストでエラーを返さないことだけ検証    課題：検証がゆるい   何ポイント付与したか検証できておらず、バグを検知できない  ※Repositoryなら集約の単位で保存しろなどツッコミもあると思いますが、本筋と関係ないので一旦スルーを 🙏 

Slide 14

Slide 14 text

Goプロダクトにおけるテスト改善の軌跡改善２. モックの引数検証  モックについて  検証する際に重要なことは次の2つのことです  • 想定する呼び出しが行われていること   • 想定しない呼び出しは行われていないこと  『単体テストの考え方/使い方』 p.321より   14

Slide 15

Slide 15 text

Goプロダクトにおけるテスト改善の軌跡 15 Q. 引数の検証できないって、どんなモック使ってたの？？   A. 当時は手書き 

Slide 16

Slide 16 text

Goプロダクトにおけるテスト改善の軌跡 A. 実装が👆でもテストが✅になってしまう😇  ポイント付与メソッドを呼んでいないため、assert.Equa point)が呼ばれない  🤔手書きのモックでもいけるのでは？  16 Q. このアサーションだと問題があります。   さて何でしょう？ 

Slide 17

Slide 17 text

Goプロダクトにおけるテスト改善の軌跡 17 😩モックを手書き+呼ばれた回数を管理はめんどい   😩メソッドをリネームしたときに修正するの大変   　　👉モックを自動生成するライブラリを導入しよう  

Slide 18

Slide 18 text

Goプロダクトにおけるテスト改善の軌跡モック自動生成ライブラリの選定  1⃣ moq  2⃣ gomock or mockery  18

Slide 19

Slide 19 text

Goプロダクトにおけるテスト改善の軌跡 moqは生成されるコードが非常にシンプルで、標準パッケージしか使っていない  👍ドキュメントを読まずとも使い方がわかる  👋万が一moqのメンテが終わったとしても、 moqはプロダクトから消しつつ、生成していたコードは使い続けるという選択もできる    (gomockやmockeryの生成コードは自身のライブラリを importしている)  1⃣ moq vs 2⃣ gomock or mockery 19

Slide 20

Slide 20 text

Goプロダクトにおけるテスト改善の軌跡生成されたモックの使い方 - 1⃣ moq  20 👈呼び出し回数の検証。前述の通り大事   👍手書きしていたモックと使い方が一緒。移行が楽 

Slide 21

Slide 21 text

Goプロダクトにおけるテスト改善の軌跡生成されたモックの使い方 - 2⃣gomock or mockery  21 ※使い方がほぼ一緒のためgomockのみ記載   👍引数の検証、呼び出し回数の検証がシンプルに書ける   (Issueメソッドの呼び出し回数がきっかり1回であることも検証できている)   gomockとmockeryの細かい違いは“Comparison of golang mocking libraries”のGistを見ると良い   https://gist.github.com/maratori/8772fe158ff705ca543a0620863977c2    

Slide 22

Slide 22 text

Goプロダクトにおけるテスト改善の軌跡 1⃣ moq  2⃣ gomock or mockery  👉手書きしていたモックからの移行の楽さと生成されるコードのシンプルさから、自分たちのプロダクトではmoqを採用  モック自動生成ライブラリの選定  22

Slide 23

Slide 23 text

Goプロダクトにおけるテスト改善の軌跡 • 課題  返り値がerrorのみのメソッドでモックの引数が検証できておらず検証がゆるかった。またモックの手書きは変更が大変だった。  • 解決法  モック自動生成ライブラリmoqを導入  • 学び  カバレッジは「高いから安心」ではない  取得以外の処理(Saveとか)のモックで以下の2つを検証するのが大事  • 想定通りの引数で呼ばれたか  • 想定通りの回数呼ばれたか  改善２. モックの引数検証 - まとめ  23

Slide 24

Slide 24 text

Goプロダクトにおけるテスト改善の軌跡もくじ  • 課題と改善  • ゴールデンテスト導入  • モックの引数検証  • 過剰なテーブル駆動をやめる  • まとめ  24

Slide 25

Slide 25 text

Goプロダクトにおけるテスト改善の軌跡改善３. 過剰なテーブル駆動をやめる - 注意  • この章は今までよりも長いです  • とくに「課題→改善方法→まとめ」のうち「課題」のパートが長いです  • Go Conference 2024でも似た発表があったので、気になるかたはそちらもチェックを！  • 『Table-driven testing に縛られないGoのテストパターン』 (https://gocon.jp/2024/sessions/19/)  25

Slide 26

Slide 26 text

Goプロダクトにおけるテスト改善の軌跡改善３. 過剰なテーブル駆動をやめる - 課題感  • 課題：テストケースが読みにくい  ＆  追加しにくい🤔  26

Slide 27

Slide 27 text

Goプロダクトにおけるテスト改善の軌跡実際に書かれていたテストのイメージ  27 まずはテスト対象の実装をチェック 

Slide 28

Slide 28 text

Goプロダクトにおけるテスト改善の軌跡実際に書かれていたテストのイメージ  28 👈 1⃣モックする必要あり  まずはテスト対象の実装をチェック 

Slide 29

Slide 29 text

Goプロダクトにおけるテスト改善の軌跡実際に書かれていたテストのイメージ  29 👈 2⃣条件分岐を網羅的にテストしたい  まずはテスト対象の実装をチェック 

Slide 30

Slide 30 text

Goプロダクトにおけるテスト改善の軌跡実際に書かれていたテストのイメージ  30 👈 3⃣異常系もテストしたい  まずはテスト対象の実装をチェック 

Slide 31

Slide 31 text

Goプロダクトにおけるテスト改善の軌跡 31 次に、テストをチェック 

Slide 32

Slide 32 text

Goプロダクトにおけるテスト改善の軌跡 32 1⃣モック 

Slide 33

Slide 33 text

Goプロダクトにおけるテスト改善の軌跡 33 2⃣条件分岐を網羅的にチェック  🤔条件分岐のチェック、  コード量多いな…(伏線) 

Slide 34

Slide 34 text

Goプロダクトにおけるテスト改善の軌跡 34 3⃣異常系のテスト 

Slide 35

Slide 35 text

Goプロダクトにおけるテスト改善の軌跡改善３. 過剰なテーブル駆動をやめる - 課題感  35 • プロジェクトのテストコードはこのように1メソッドにつき1テーブルで書かれていた  • 自分🤔「なんか読みづらい&書きづらい」   👉言語化 

Slide 36

Slide 36 text

Goプロダクトにおけるテスト改善の軌跡読みづらいポイント１: 上から下の順に読めない  36 例えば  🤔「このwantErrってなんだ？」  と疑問を持ったとして…   

Slide 37

Slide 37 text

Goプロダクトにおけるテスト改善の軌跡読みづらいポイント１: 上から下の順に読めない  37   下までスクロールして、for文の中を見るとようやく理解できる   

Slide 38

Slide 38 text

Goプロダクトにおけるテスト改善の軌跡読みづらいポイント１: 上から下の順に読めない  38 フィールドの意味が理解できたので、ようやくテストケースを読み始められる 

Slide 39

Slide 39 text

Goプロダクトにおけるテスト改善の軌跡読みづらいポイント１: 上から下の順に読めない  39 👀視線  🤞スクロールする  指の負担大 

Slide 40

Slide 40 text

Goプロダクトにおけるテスト改善の軌跡 🤨いや、フィールド名をわかりやすくすれば、for文の中は読み飛ばせるでしょ？？  40

Slide 41

Slide 41 text

Goプロダクトにおけるテスト改善の軌跡読みづらいポイント２: しれっと書いてある共通処理  41 👈❗❗ ❗ (※ログインユーザーのIDに1をセットしている）     全テストケースに共通して発動する処理がfor文の中に書かれていることがあるので、読み飛ばせない   ※たまにこの共通処理がテストのwant値に影響することがある。油断ならない。 

Slide 42

Slide 42 text

Goプロダクトにおけるテスト改善の軌跡読みづらいポイント３: もはや間違い探し  42 🤔「あれ、この2つのテストケース、モックの部分ほぼ一緒では？？なんでwantが違うんだ？？」  👆ここ 👆ここ

Slide 43

Slide 43 text

Goプロダクトにおけるテスト改善の軌跡 1メソッドのテストにつき1テーブルにしているせいで  読みづらいポイント   　１．上から下の順に読めない  　２．しれっと書いてある共通処理  　３．もはや間違い探し  改善３. 過剰なテーブル駆動をやめる - 課題感  43

Slide 44

Slide 44 text

Goプロダクトにおけるテスト改善の軌跡 💪今からテスト書くぞ〜  書きづらいポイント１: まずはテーブルを考える必要あり  44

Slide 45

Slide 45 text

Goプロダクトにおけるテスト改善の軌跡 💪今からテスト書くぞ〜。書くべきテストは3パターンか  書きづらいポイント１: まずはテーブルを考える必要あり  45 😩まずはこの３パターンを書くためのテーブルを考える必要がある  (具体的なテストを書く前に抽象化が必要)  

Slide 46

Slide 46 text

Goプロダクトにおけるテスト改善の軌跡 ※エラーを完全一致で検証してる  🤔実装が追加されて、エラーを部分一致で検証するテストケースも追加したくなったな…   書きづらいポイント２: 毛色の違うアサーションを足しづらい  46       😇こうして、一部のケースでしか使わないフィールドが増え、テストがif文だらけになっていく  

Slide 47

Slide 47 text

Goプロダクトにおけるテスト改善の軌跡 1メソッドのテストにつき1テーブルにしているせいで  読みづらいポイント   　１．上から下の順に読めない  　２．しれっとfor文の中に書いてある共通処理  　３．もはや間違い探し  書きづらいポイント   　１．まずはテーブルを考える必要あり  　２．毛色の違うアサーションを足しづらい  改善３. 過剰なテーブル駆動をやめる - 課題感  47

Slide 48

Slide 48 text

Goプロダクトにおけるテスト改善の軌跡 • 課題の説明おしまい  • さて、この課題をどう解決していくか…  ここからは改善方法のお話  改善３. 過剰なテーブル駆動をやめる - 課題感  48

Slide 49

Slide 49 text

Goプロダクトにおけるテスト改善の軌跡 • 困ったときは原点に立ち返ってGo Wikiのテーブル駆動の説明を読もう  改善３. 過剰なテーブル駆動をやめる - 改善方法の模索  良いテストを書くことは簡単ではありませんが、多くの状況ではテーブル駆動テストでカバーできます。(...中略...)  テストを書くときにコピペしてる場合は、テーブル駆動テストにリファクタリングするか、コピーしたコードをヘルパー関数に切り出すかを検討してください  (https://go.dev/wiki/TableDrivenTests より)  49

Slide 50

Slide 50 text

Goプロダクトにおけるテスト改善の軌跡気づき  • 実は「すべてのテストをテーブル駆動で書け」とまでは言われていない  • 「1メソッドにつき1テーブルにまとめろ」とも言われていない  改善３. 過剰なテーブル駆動をやめる  良いテストを書くことは簡単ではありませんが、多くの状況ではテーブル駆動テストでカバーできます。(...中略...)  テストを書くときにコピペしてる場合は、テーブル駆動テストにリファクタリングするか、コピーしたコードをヘルパー関数に切り出すかを検討してください  (https://go.dev/wiki/TableDrivenTests より)  50

Slide 51

Slide 51 text

Goプロダクトにおけるテスト改善の軌跡 • フロントエンドでもテーブル駆動のような書き方はあるが、同じような検証を複数の入力値で行うときにしか使わない。                    • 『単体テストの考え方/使い方』ではテーブル駆動に近いものとして「パラメータ化テスト」が紹介されている(p. 83)。ここでも「同じようなテストケースを 1つのグループにまとめる」と書かれている  他の界隈も見てみると…  51 (Jest公式ドキュメントより引用) 

Slide 52

Slide 52 text

Goプロダクトにおけるテスト改善の軌跡あらためて自分たちのテストを見てみると…  52 (...中略...)  1⃣正常系：登録日に応じて想定通りのポイントが返ること   2⃣異常系：想定通りのエラーが返ること 😭2パターンが無理やり1つのテーブルに押し込まれている 

Slide 53

Slide 53 text

Goプロダクトにおけるテスト改善の軌跡 53 同じパターンだけをテーブル駆動テストするように修正 

Slide 54

Slide 54 text

Goプロダクトにおけるテスト改善の軌跡 👍検証内容はそのまま、全体の行数が2/3に減少  ※後でコードは拡大するので詳細は見なくてOK   54

Slide 55

Slide 55 text

Goプロダクトにおけるテスト改善の軌跡 55 ポイント：検証したい項目ごとにt.Run を書く 

Slide 56

Slide 56 text

Goプロダクトにおけるテスト改善の軌跡 56 👍t.Runがテーブルの説明になっているので理解しやすい  👍テーブルが小さいので  ・新しいケースを追加しやすい  ・既存のケースも修正しやすい 

Slide 57

Slide 57 text

Goプロダクトにおけるテスト改善の軌跡 57 🤔とはいえ、重複コードができてしまう  (サンプルコードでは2行だけだが、実コードだともっと多くなることも) 

Slide 58

Slide 58 text

Goプロダクトにおけるテスト改善の軌跡 • 重複をどうするか…  • もう一回Go Wikiを読むと…  改善３. 過剰なテーブル駆動をやめる  良いテストを書くことは簡単ではありませんが、多くの状況ではテーブル駆動テストでカバーできます。(...中略...)   テストを書くときにコピペしてる場合は、テーブル駆動テストにリファクタリングするか、コピーしたコードをヘルパー関数に切り出すかを検討してください  (https://go.dev/wiki/TableDrivenTests より)  58

Slide 59

Slide 59 text

Goプロダクトにおけるテスト改善の軌跡 😤ヘルパー関数に切り出して解決  (スコープを小さくするためにTest関数の中に宣言するのが個人的なおすすめ)  59

Slide 60

Slide 60 text

Goプロダクトにおけるテスト改善の軌跡テスト対象の実行部分がまだ重複しているが、これは必要経費として割り切る     ※フロントエンドでも『単体テストの考え方/使い方』のサンプルコードでも、この重複はよく見かける。  60

Slide 61

Slide 61 text

Goプロダクトにおけるテスト改善の軌跡 • テストケースを追加するときのルール  １．まずはテーブル駆動なしで検証したい項目ごとにt.Runを書く  ２．同じパターンのみテーブル駆動でまとめる  ３．テストコードの重複を抑えたい場合はヘルパー関数に切り出す    👉今までは、1テストメソッドにつきテーブルは１個だったのが、基本的には0個になった(テストによっては2個以上になることもある)  改善３. 過剰なテーブル駆動をやめる - 現状の方針  61

Slide 62

Slide 62 text

Goプロダクトにおけるテスト改善の軌跡 1メソッドのテストにつき1テーブルにしているせいで   読みづらいポイント   　１．上から下の順に読めない   　２．しれっとfor文の中に書いてある共通処理   　３．同じようなテストコードが連続して、もはや間違い探し   書きづらいポイント   　１．まずはテーブルを考える必要あり   　２．毛色の違うアサーションを足しづらい   改善３. 過剰なテーブル駆動をやめる - 課題感(再掲)  62

Slide 63

Slide 63 text

Goプロダクトにおけるテスト改善の軌跡 1メソッドのテストにつき1テーブルにしているせいで   読みづらいポイント   　１．上から下の順に読めない   　２．しれっとfor文の中に書いてある共通処理   　３．同じようなテストコードが連続して、もはや間違い探し　 👈※ルール1だけだとより悪化する場合がある   書きづらいポイント   　１．まずはテーブルを考える必要あり   　２．毛色の違うアサーションを足しづらい   改善３. 過剰なテーブル駆動をやめる - 課題感(再掲)  63 ルール１．まずはテーブル駆動なしで検証したい項目ごとにt.Runを書く

Slide 64

Slide 64 text

Goプロダクトにおけるテスト改善の軌跡 1メソッドのテストにつき1テーブルにしているせいで   読みづらいポイント   　１．上から下の順に読めない   　２．しれっとfor文の中に書いてある共通処理 👈※want値に影響を与える共通処理はfor文の中に書かないように  　３．同じようなテストコードが連続して、もはや間違い探し   書きづらいポイント   　１．まずはテーブルを考える必要あり   　２．毛色の違うアサーションを足しづらい   改善３. 過剰なテーブル駆動をやめる - 課題感(再掲)  64 ルール２．同じパターンのみテーブル駆動でまとめる  ルール３．テストコードの重複を抑えたい場合はヘルパー関数に切り出す

Slide 65

Slide 65 text

Goプロダクトにおけるテスト改善の軌跡 • 課題  同一ではないパターンを1テーブルに無理やり押し込んでおり、読みづらい・書きづらい問題が起きていた。  • 改善方法  基本的にはテーブル駆動を使わずにテストを書き、同一パターンだけ小さなテーブル駆動に切り出す。  • 学び  まずは有名な手法に従うのが大切。ただし、盲目的に受け入れるのではなく、一度先入観をなくしてより良い方法を模索するのも大切。  改善３. 過剰なテーブル駆動をやめる - まとめ  65

Slide 66

Slide 66 text

Goプロダクトにおけるテスト改善の軌跡全体のまとめ  66   課題  改善方法   1  テスト出力値のコピペが辛かった。   cupaloyというライブラリを採用しゴールデンテストを導入した。  2  モックの引数が検証できておらずバグを見逃す&手書きしたモックの変更が大変だった。   モック自動生成ライブラリmoqを導入した。     3  同一ではないパターンを1テーブルに無理やり押し込んでおり、読みづらい・書きづらい問題が起きていた。   基本的にはテーブル駆動を使わずにテストを書き、同一パターンだけ小さなテーブル駆動に切り出す。  

Slide 67

Slide 67 text

Goプロダクトにおけるテスト改善の軌跡 • 「カバレッジ高いけど検証が甘い」を炙り出せる仕組みがほしい  • Mutationテストの導入：わざと実装をバグらせて、テストが「ちゃんと落ちる」ことを確認。これにより、バグを検出できないテストが炙り出せる  • zimmski/go-mutesting など  今後やりたいこと  67

Slide 68

Slide 68 text

Goプロダクトにおけるテスト改善の軌跡 • 自分にとって人生はじめてのGoプロダクトだったので、最初は目にするコードすべてが正解に見えた。それでも課題を見つけられるようになったのは、  • フロントエンドなど他の界隈の知識と比較したから  • 言語に関係ない汎用的な知識をつけたから   (『単体テストの考え方/使い方』めっちゃおすすめです！！！)   • 今回のようになにか改善を加えるときは、メンバーに少しずつ試してもらってフィードバックをもらうのが大事  • 複数人が良さを実感したものをチームに広げていく  • 評判が良くなかったらもとのやり方に切り戻す  あとがき  68

Slide 69

Slide 69 text

ご清聴ありがとうございました  69

Slide 70

Slide 70 text

Goプロダクトにおけるテスト改善の軌跡 • まだイケてないテストが残ってるので改善  • 月末にのみ落ちるのでプルリクの段階では気がつけずマージされてしまう  👉テストケースでは固定値を使うようにチームでマインドを共有していく  今後やりたいこと１  70

Slide 71

Slide 71 text

Goプロダクトにおけるテスト改善の軌跡改善３. 過剰なテーブル駆動をやめる  • 自分たちも含め1メソッドにつき1つのテーブル駆動で書いているプロダクトは DMMの中でも結構見かける。なぜ🤔  • Go Wikiではヘルパー関数は解説がほぼない一方でテーブル駆動は1ページまるまる使って丁寧に解説されている  • 「テーブル駆動」という覚えやすい名前もあいまって認知しやすく使われやすくなった  『ハンマーを持つ人にはすべてが釘に見える』  その他、認知科学分野で、名前がついていると認知しやすくなる現象などを引用  71