プロジェクトへテストコードを導入する(計画編)

## 今回話すこと
- [導入の経緯](https://qiita.com/iyore_eng/items/fdf57b817589383db661#導入の経緯)
- [Webアプリケーションにおけるテストとは](https://qiita.com/iyore_eng/items/fdf57b817589383db661#webアプリケーションにおけるテストとは)
- [何のためにテストをするか](https://qiita.com/iyore_eng/items/fdf57b817589383db661#何のためにテストをするか)
- [どういったものをテストするか？](ttps://qiita.com/iyore_eng/items/fdf57b817589383db661#どういったものをテストするか)
- [デメリットについて考える](https://qiita.com/iyore_eng/items/fdf57b817589383db661#デメリットについて考える)
- [使用する技術](https://qiita.com/iyore_eng/items/fdf57b817589383db661#使用する技術)
- [運用ルール](https://qiita.com/iyore_eng/items/fdf57b817589383db661#運用ルール)
- [テスト項目例](https://qiita.com/iyore_eng/items/fdf57b817589383db661#テスト項目例)
- [サンプルコード](https://qiita.com/iyore_eng/items/fdf57b817589383db661#サンプルコード)
- [参考文献](https://qiita.com/iyore_eng/items/fdf57b817589383db661#参考文献)

---
## 導入の経緯
現在私たちのプロジェクトにはテストコード導入されていない。
もちろん目視によるテストは行っており品質は担保しているが、
テストのコード化という点においては手が付けられていない。
理由としては、今は運用フェーズにあるがリソース的にも潤沢というわけではなく、
アプリケーションの新規機能開発、バグの改修で精いっぱいでテストまで手を出せない状況にある。
しかし改修のたびに、目視での確認や毎回の必須項目に対して手動でテストを行うのは**非効率的** ~~(楽をしたい)~~
そこで運用も安定してきたこのタイミングでテストコードを導入していきたい。

---
## 雑談
エンジニアとして初めての会社だったので最初はテストコードが無いことに驚いたが
調べると案外テストを導入している会社は多いわけではなく、
実際、実務ついてみると確かに「それどころではない:relaxed:」という状況ではあった。

---
## Webアプリケーションにおけるテストとは
開発や改修時、リリースなどの際にコードの変更により
以下のような問題が発生しないか確認するための作業のこと

- システムにバグが埋め込まれていないか
- 修正により新たな問題が顕在化していないか
- 仕様通りに作れているか

![仕様書.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286952/f3c7bc55-3bb1-4504-0764-89997c793f39.png)

---
## 何のためにテストをするか
- 新しく入ってきた人でも一定の確認ができ、ある程度の品質が保たれる事
- 毎回同じ確認が必要な項目を自動化する、**確認漏れ**を防ぐ
- テストコードがある事で自分のコードを他人がメンテする際に**意図が汲み取りやすい**
- gemやrubyなどのアップデートの際のチェックに使える
- テストが引っかかった場合、**原因となる箇所が明確**である
- **保守の容易性**が上がれば品質も上がるし他を対応する時間もできる

...etc

---
## デメリットについて考える

- アプリコードとは別にテストコードを書く工数が必要
- テストするためのデータを作成しないといけない
- 全ての場合にテスト自動化できる訳ではない、手動の確認も合わせて活用する
- 要件の変更などがあった場合にテストの修正が必要になる

＊以上のことを踏まえると何でもかんでもテストできる訳ではないので
　できるだけコスパの良いものにフォーカスしてテストを書いていきたい

---
## テスト自動化のためのコストはいつ回収できるのか？
![テスト自動化の損益分岐点.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286952/c8213863-20dd-00ca-bccb-1cb62f2a4aa6.png)

＊確かに10～15分くらいかかるテストを4回行う時間で簡単なテストは書けそう
（図はネットの参考文献を真似て作っただけなのであくまでもイメージです。）

---
## どういったものをテストするか？
- 計算結果など値がぶれるとマズい箇所
- 変更による影響範囲が大きい箇所
- お金が関わっていてバグがあると致命的な箇所

![お金.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286952/c18d8c24-a6c7-ab67-2419-544540faa8e8.png)

---
## 使用する技術
- フレームワーク：RSpec
→RSpecの Rは「Ruby」、Specは「テストコード」の事。
　テストコードを記述し、テストを自動化するためのフレームワーク。

- UIテストライブラリ：Capybara
→UIテストを行うためのライブラリ、テスト上でブラウザを開きテストコード通りに実行できる。

- テストデータ作成：FactoryBot
→テストデータを自動生成するためのgem

![RSpec.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286952/490558be-f0be-0b34-5bcb-d15b99617f55.png)

---
## ルールを決めておく
実際に導入しだすとそれぞれ実装に個性が出てきてしまうので
ガチガチにはしないがある程度ルールは定めておく

---
## 運用ルール
- except行は極力１行くらいでシンプルに書く（テストが複雑化すると期待する結果が出ているのか信用しずらい）
- テスト一つに対して「〜〜のテスト、期待する結果は〜〜」という感じに明確にコメントを書く
- テストはそれぞれ独立させる、関連させることはしない
- itの中のexpectは必ず1つだけにする(複数あると失敗した場合にどこでこけたのか分からない)

...etc(ルールは話し合いにより適宜追加可能とする)

---
## テスト項目（例）
- データファイル取り込み
    - ファイルアップロード
    - ファイル名チェック
    - モデルの作成

- 計算
    - モデルの作成
    - 期待する計算値になるか
    - 特別な処理を行う分岐

- エクセル出力
    - モデルの作成

- 計算用データ登録
    - 登録、削除、修正
    - ファイル取り込みの登録

- UI系
    - フラッシュの表示
    - エラーメッセージ
    - 一覧表示画面

＊テスト項目に対してどのような結果を求めるかなどは別途精査。

---
## サンプルコード
RSpecってこんな感じで書くよというイメージ

```sample.rb
RSpec.describe '四則演算' do
  it '1 + 1 は 2 になること' do
    expect(1 + 1).to eq 2
  end
end
```

---
## 続き
[環境構築編はこちら](https://qiita.com/rerere_eng/items/1a98bd705ecbaa931261 "")

---
## 参考文献
・https://qiita.com/jnchito/items/2a5d3e15761fd413657a#%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB
・https://qiita.com/tatsurou313/items/c923338d2e3c07dfd9ee#%E3%83%86%E3%82%B9%E3%83%88%E3%81%99%E3%82%8B%E5%AF%BE%E8%B1%A1
・https://techracho.bpsinc.jp/hachi8833/2016_12_08/30624