リーダブルコード輪読会 第14章
===

# ディスカッションをより豊かにするためのグランドルール

- 参加者は毎回任意
- 途中参加・聞くだけでもOK！

- ページ数と同時に、節のタイトルやキーワードを記入してもらえると探す手間を省けて嬉しいです

- ファシリテーターや話している人は集中しがちなので、話していない人に議論内容をメモ:pencil:してもらえると嬉しいです

- 気になる質問や同感するものには :+1: を末尾につけてください。

- 社外秘情報は書かないこと!!!
- オープン設定で誰でも見れてしまうので

# タイムテーブル

| 時間 | 所要時間 | 内容 |備考 |
| -------- | -------- | -------- | -------- |
| 15:00 | 5-10分? | (書いてなければ)感想記入&書かれた感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | |
| 15:10? | 40-45分 | 本の節ごとにディスカッション | |
|15:55? | 5分 | 次回読む範囲決めてクローズ | |

## 下に感想などを書いていって下さい。どんな些細なことでもOKです。

---

# 序章、14.1 テストを読みやすくて保守しやすいものにする

## 感想・気づき
- > 他のプログラマが安心してテストの追加や変更ができるように、テストコードを読みやすくする。
- この説明だと開発のためのテストであって、品質保証のためのテストではなさそう
- > テストコードが大きくて恐ろしいものだとしたら、以下のようなことが起きる。
- こういう心理もあって、どこまでテスト書くの？という議論が尽きない気がする
- カバレッジを満たすためのテストは、保守が辛くなりがちでこういう心理が働きやすい気がする
- 書いてはいるが…モックまみれになってメンテ性が非常に悪いテストがたくさんある
- ロジックが保護されている安心感はあるが、プロダクトコードを変更したときにテスト修正が重荷になっているorz

### 実践してる人
#### 書籍通りのやり方をしているか。または、何か違う点はあるか。

### 実践してない人
#### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。

## 疑問
- そもそもテストコードに期待することは？
- 開発しやすさと品質保証の視点があるとは思うが...
- 開発しやすさ
- :memo: 自分が想定した通りに動くのを補償
- :memo: 入力パラメータの組み合わせを補償、エビデンスになってほしい
- パラメタライズドテストが参考になる
- 参考: [JUnitでパラメータ化テストをすばやく作成する方法 | Parasoft](https://parasoft.techmatrix.jp/how-to-expedite-the-creation-of-junit-parameterized-tests)
- :memo: 環境の違いを気にせずロジックの正しさを検証する
- 非同期とかはそもそもUTでやらない方がいいのでは？

# 14.2 このテストのどこがダメなの?

## 感想・気づき
- 何がテスト対象なのか分かりづらい
- テストの目的が全くわからない
- 毎回urlを書く？

### 実践してる人
#### 書籍通りのやり方をしているか。または、何か違う点はあるか。

### 実践してない人
#### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。

## 疑問

# 14.3 テストを読みやすくする

## 感想・気づき
- > 一般的な設計原則として、「大切ではない詳細はユーザから隠し、大切な詳細は目立つようにする」べきだ。
- クラス設計も同じで、そのためにinterafaceがある:+1:

### 実践してる人
#### 書籍通りのやり方をしているか。または、何か違う点はあるか。

### 実践してない人
#### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。

## 疑問
- この章のヘルパー関数はどこに書くべきか。テストコード？プロダクトコード？
- テストコード派 :+1:
- ヘルパー関数の中でassertするのはどうなの？
- 違和感ある
- わかりづらくなりそう
- これの何が問題？
- 入力データの生成に失敗したことを示すのは必要
- 別のテストケースにしたほうが良さそう

# 14.4 エラーメッセージを読みやすくする

## 感想・気づき
- 何が原因で失敗したか分かりやすくするのはほんと重要:+1:
- Javascriptだけど、[power-assert](https://github.com/power-assert-js/power-assert)のようなライブラリもある
- [5分でわかるpower-assert](https://azu.github.io/slide/sakurajs/power-assert.html#/)
- JUnitなどのテスティングフレームワークを使っているなら、あまり意識しなくて良いと思う

### 実践してる人
#### 書籍通りのやり方をしているか。または、何か違う点はあるか。

### 実践してない人
#### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。

## 疑問

# 14.5 テストの適切な入力値を選択する

## 感想・気づき
- > 入力値を単純化する
- テストコードを読んで仕様を把握したい。入力値が複雑だと何か意味があるのかと邪推してしまうので、単純化は意識したい
- 境界値だけでなく、同値分析と言う考え方もある
- 境界値だけだとそれ以外のケースが漏れてしまいがちなので、テストの視点として持っておくと便利
- [『はじめて学ぶソフトウェアのテスト技法』を読み解く - 「同値クラステスト」(Swiftのサンプルコード付き) - Qiita](https://qiita.com/ktanaka117/items/64bff197b094f9bdb0a7)
- 「適切」を判断するのが難しいと思う
- まずは境界値、同値
- 組み合わせ
- テスターさんの考え方を落とし込んでみる
- [ソフトウェアテスト技法ドリル](https://www.juse-p.co.jp/products/view/372)
- [ソフトウェアテスト技法練習帳 ～知識を経験に変える40問～：書籍案内｜技術評論社](https://gihyo.jp/book/2020/978-4-297-11061-1)
- 同値について詳しく説明しているのでテスターさんオススメらしい

### 実践してる人
#### 書籍通りのやり方をしているか。または、何か違う点はあるか。

### 実践してない人
#### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。

## 疑問

# 14.6 テストの機能に名前をつける

## 感想・気づき
-

### 実践してる人
#### 書籍通りのやり方をしているか。または、何か違う点はあるか。
- テストメソッドは日本語で表記で書く:+1:
- テストコードは何やってるのか軽く把握したいという需要があると思うので、日本語の方が言語変換コストなくて好み
- 日本語で書いてると明らかにテストコードとわかるのも利点の1つ
- JUnitとかだとバージョンによってはDisplayNameが、JUnitParamsではTestCaseNameみたいなのを指定できるものもあるので活用すればいいかも
- ↑集合研修でちらっとやりました

### 実践してない人
#### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。

## 疑問

# 14.7 このテストのどこがダメだったのか?

## 感想・気づき
- サンプルコードを見てあれこれ意見はあったが、具体的な8個を言語化はできなかったので、読み直してよかったと感じた

### 実践してる人
#### 書籍通りのやり方をしているか。または、何か違う点はあるか。

### 実践してない人
#### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。

## 疑問

# 14.8 テストに優しい開発

## 感想・気づき
- テストコードを書くまでいかなくても、どんなケースで使われるか考えるだけでも設計の視点は大きく変わる印象
- テストコードがあると、プロダクトコードを最初に使う人が自分になるのであらかじめリファクタしやすくなる
- 流用を重視すると、テストを踏まえた設計まで検討できないなぁ…
- 疎でステートレスなものならテスト書きやすい
- 現実はそう言うものばかりじゃないけど…

### 実践してる人
#### 書籍通りのやり方をしているか。または、何か違う点はあるか。
- 新規実装のクラスはテストコード書く(書ける)ように意識した設計にする
- テストコード自体は、想定した挙動のテストぐらいに留めることが多い
- テストコードで使い方を見てもらい、実装で抜け漏れがないか見てもらう２段階のレビューをやってもらえる効果があると感じる

### 実践してない人
#### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。
- 既存クラスの改修は理想通りにはいかない
- 依存関係が強い既存コードはどうやってテストを導入すればいいのか手がかりも見つからない場合もある
- できる範囲でテスト可能なところを切り出し、その部分だけテストで保護するのが定石
- [『レガシーコード改善ガイド』再入門〜 技術的負債とダンスを(5) | by Eiji Ienaga | 時を超えたプログラミングの道](https://twop.agile.esm.co.jp/working-effectively-with-legacy-code-ebeaefafb900)

## 疑問

# 14.9 やりすぎ

## 感想・気づき
- > テストをしやすくするために、本物のコードにゴミを入れてはいけない。
- 理想はその通りだが、依存が強すぎるコードは本物のコードにモック定義を入れたりすることもある
- 上のようにすれば違和感があるコードなので、リファクタしようという意識付になるので
- > 現実的には、カバレッジが 100% になることはない。もしも 100% になって いるのだとしたら、バグを見逃しているか、機能を実装していないか、仕様 が変更されたことに気づいていないかのどれかだ。
- テストでガチガチに固められたプロジェクトでもこうなのだろうか？
- > テストがプロダクト開発の邪魔になる
- カバレッジ100%を満たすようなコードの場合、ホワイトボックステストになってしまう
- 実装を隅々までテストしたいのか、対象のメソッドの機能をテストしたいのか、どっちを目的にしたいのか良くわからん状態に思える
- 変更に対して柔軟にしたいなら、機能ベースでテストを書きたい

### 実践してる人
#### 書籍通りのやり方をしているか。または、何か違う点はあるか。

### 実践してない人
#### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。

## 疑問

# 14.10 まとめ

## 感想・気づき
-

## 疑問